sequence
Now go to the Internet to search GIT keyword, the result is often GIT command complete. Commands do, but submitting code often fails when it should. This article will combine my experience, put forward some GIT branch management methods, hope to help you.
If the project has no environment (formal, grayscale, test, development) or fewer than three developers, click on the upper right corner for Windows users and click on the upper left corner for Mac users.
The preparatory work
create
We initialize it as a normal project, creating branches:
PRO, Production Environment, official server
UAT, User Acceptance Test Environment, Gray scale
FAT, Feature Acceptance Test Environment
DEV, Development environment, Development
Branching, as the name implies, no longer expands.
Branch protection
Take GitLab as an example to create branch protection rules:
Settings -> Repository -> Protected Branches select PRO (Master) Branches, specify Allowed to merge as TL (technical leader), Allowed to push as No one, or TL.
So why not allow push PRO branches?
In a multiplayer development project, merge and push are the easiest operations to override someone else’s code. The PRO branch only allows you to store code running online. If you merge push, anyone can merge code into this branch, which can be dangerous! After all, the biggest bug in the system is people.
Merging the merge, push permissions also has an important role to play in keeping the TL fully aware of work progress and view code.
Development branch name
This is the agreement I have practiced in practice, for your reference:
Own branch naming rules: developer name _ project name _ module name
Example: zhaomm_project_name_user_module
Branch management
Ideal development process
In UTA -> PRO step, the developer initiates a merge request on GitLab and merges TL from UAT to PRO. After the release, the developer can delete his own development branch.
Of course, the ideal is beautiful, the reality is skinny. Let’s take a look at the following special cases:
Multifunctional parallel development
Some of the code will not be released to the official server next time.
FAT cannot be incorporated directly into UAT because the FAT environment is shared between the published and pre-developed branches.
After the test passes, the branch to be released is merged directly into the UAT and finally into PRO.
The branch developed in advance needs to merge PRO code after it goes live.
With container technology making it easier to deploy environments and code, companies can create virtual environments for each branch if they can. Note, however, that every time you go live, you need to merge the PRO code into the next development branch.
Official server bug fixes are back online
Sometimes, code that is already live needs to be changed urgently.
Generally, this situation is urgent. After the code is written, it is directly merged into FAT and handed over to the test.
After passing the test, merge the bug fix branch directly into UAT to avoid FAT code being merged into PRO.
Once online, merge the PRO code into the normal development branch.
The last
Having said that, the essence of this is to solve the problem of what code to ship and what code not to ship.
I hope this article can enlighten you. thank you