takeaway

For a team of four to five or more people, the cost of collaborative communication generally begins to have an impact on efficiency, and the impact increases exponentially as the number of people increases. Git collaboration clearly has this nature, so various Git workflows have sprung up in the industry to try to solve this problem. The more famous ones are Gitflow, GitHub Flow and GitLab Flow.

After a comprehensive investigation, the author proposed a scheme based on the idea of Gitflow and combined with THE PR/MR mode. In addition, each step node was scripted so that complex operations could be completed with a command. Now arrange written, hope to give everybody to make a reference.

This article will introduce the idea first, and the specific script will come later, or impatient readers can go straight to the script and come back to the theory. It is important to note, however, that the theory must be looked at, because handling conflicts and other situations will break the script, and while this is as clear as possible in the comments, it is still possible to make errors in handling exceptions if you do not fully understand the thinking behind them.

The body of the

Train of thought

The main idea of Gitflow is to use the flow rules of branches to make collaboration orderly and reduce chaos, and there is a supporting tool gitflow-AVH. One thing it doesn’t quite fit into the modern development process, however, is that it doesn’t have the concept of PR/MR (a feature of GitHub and GitLab, respectively), and instead uses direct branch merging. This is bad for Code Review, permission control, CI/CD control, etc. So the author’s idea of this scheme is the combination of Gitflow + PR/MR, take the advantages of both.

What branches are needed

Since we are using branch management, let’s start by looking at what branches we need in an essentially daily development scenario. Project iterations are usually: development => test => Debug => live, possibly interlaced with high quality requirements and hotfixes. The following conclusions can be drawn:

1. One (or more) branch is required to correspond exactly to the production environment to handle hotfix situations at any time, and master is recommended.
2. You need a branch to aggregate everything you develop on a daily basis and keep your code up to date so that all collaborators can synchronize their code. Develop is recommended.
3. When the Debug is in the online ready state, sometimes it is necessary to wait for the online window period. In this case, the branch used for online needs to be frozen. It’s possible that the next round of development has already started while you’re testing, and then you Debug. The Develop branch should not be held up so as not to block daily development for the next iteration. In this case, you need to have a branch dedicated to online use. Release is recommended.
4. Hotfix/XXX (temporary) is recommended because it is not suitable to run a temporary branch on the master.
5. In addition to the above four branches, the most critical is the daily development branch of each person. At this time, whether each person should use only one branch (in human unit) or multiple branches (in feature unit) needs to be discussed. At present, the common practice in the industry is to temporarily branch the feature as a unit, which is deleted when used up. There will be research below, and feature/ XXX (temporary) is recommended.
6. Finally, in the Debug stage after the test, it is recommended to use the Bugfix branch to distinguish it from the feature branch. Bugfix/XXX (temporary) is recommended.

The above branches are also designed with reference to Gitflow-AVH, and try to ensure the fit with existing tools. Having determined which branches we need from the point of view of requirements, the next step is to make flow rules between branches to ensure order.

Branch flow rule

A picture is worth a thousand words.

Branch name	The nature of the	instructions	Operation permissions
master	permanent	– Keep up with online contentStrong consistencyThat is, any change triggers online deployment; -Only accept PR for hotfix and release;	Merge: Supervisor and Supervisor
develop	permanent	– The branch that saves the latest development results; -Only accept PR of feature, can only be merged into release; – Rebase should synchronize changes to release and master in time;	Merge: All r&d staff, but requires more than 1 CR to Merge Other: TL
release/xxx	Temporary/permanent	-Test acceptance, gray branches, must ensure functional integrity and certain stability; – Only accept develop and BugFix PR; – Can only cut from Develop, can only merge to master; – If the master changes, rebase synchronizes the changes in time.	Merge: All r&d staff, but requires more than 1 CR to Merge Other: TL
feature/xxx	temporary	-Branch for function development before test, theoretically one function corresponds to one branch; – Can only be cut from Develop, can only be merged into Develop.	–
bugfix/xxx	temporary	– Branch to fix bugs after testing; – Can only be cut from release, can only be merged into release;	–
hotfix/xxx	temporary	– Emergency fix line bug branch – Can only cut from master, can only merge to master; – This branch canmanualDeploy to any environment for verification, remember to be known before deployment to prevent deployment conflicts.	–

In addition, the following rules should be followed:

1. All branch merge operations are in the form of PR and require Code Review before merging (via Github Settings).
2. Rebase is recommended for all merges to ensure that the flow logic of all branches is linear.
3. Develop synchronizes the Rebase Release whenever the Release branch changes;
4. Develop and Release synchronize rebase master whenever the master changes;

Note:If you merge git log, the time logic is linear. For example, if you merge a Hotfix and then synchronize it back to Develop, the hotfix will be raised at the top of the Git log, above all new feature submissions. If it is rebase, hotfix will be referenced below all new features. In theory, the latter is more process logical.

There are so many rules, it’s confusing to look at, as a programmer, “lazy” is a necessary quality, so next, we semi-automated it.

Semi-automatic script

One problem that has to be solved with scripting is how the PR/MR operation is done on the command line. GitHub provides the command-line tool GH, which can be installed to solve this problem. GitLab does not have a solution yet, but it should be possible to implement it through URL or other means. We will study it when we have time. So the script below is executed only if you use GitHub to manage the code and have GH installed.

Feature Start

• To start developing a feature, run the following command. Function is actually very simple, is to cut a new branch.

git checkout develop && git pull -r && git checkout -b feature/xxx
Copy the code

Feature Submit

• This command only needs to be executed once after feature development is completed.
• For subsequent modifications, you only need to push the feature branch to the remote, and do not need to execute this command.
• If a conflict occurs during execution, run all commands again.

git checkout develop && git pull -r && \
git checkout feature/xxx && git pull -r && git rebase develop && \
git push --set-upstream origin feature/xxx --force-with-lease && \
gh pr create --fill --base develop
Copy the code

Feature Finish

• When Code Review is complete and PR is in the mergable state, you can execute the following commands;
• This command can only be executed by those with Develop merge permissions, although develop merge permissions are generally open to everyone.

gh pr merge feature/xxx -rd
Copy the code

Bugfix Start/Submit

Run the same command as Feature to make the following changes:

• Replace feature/ XXX with bugfix/ XXX
• Develop instead of release

Bugfix Finish

• Remember to sync Develop after the merge. To execute sync, you need to have develop’s push permission;
• If a conflict occurs, push develop after executing the Develop Rebase Release.
• CI/CD can be triggered to automatically deploy the test environment

gh pr merge feature/xxx -rd && \
The following command requires develop's push permission
git checkout release && git pull -r && \
git checkout develop && git pull -r && \
git rebase release && git push --force-with-lease
Copy the code

Hotfix Start/Submit

Run the same command as Feature to make the following changes:

• Feature/XXX is replaced with hotfix/ XXX
• Master develop

Hotfix Finish

• After the merge, synchronize release and Develop. Note that the student executing the synchronization command needs to have push permission for both branches;
• If a conflict occurs, you need to take a close look at the information to determine whether it occurred during the Release or Develop merge, push the branch after the conflict, and then execute the unexecuted command. Typically, you only need to handle the conflict once at most.
• CI/CD triggers the automatic deployment online environment

gh pr merge hotfix/xxx -rd && \
The following commands require release, develop push permissions
git checkout master && git pull -r && \
git checkout release && git pull -r && git rebase master && git push --force-with-lease && \
git checkout develop && git pull -r && git rebase release && git push --force-with-lease
Copy the code

UAT Submit

git checkout develop && git pull -r && gh pr create --fill --base release
Copy the code

UAT Finish

• The command is the same as Bugfix Finish, just change the first command.

The develop branch is not set to -rd.

gh pr merge develop -r && \
Other commands and permissions are the same as Bugfix Finish
Copy the code

Deploy Submit

• Theoretically, the on-line must be confirmed by the product, test and technical director

git checkout release && git pull -r && gh pr create --fill --base master
Copy the code

Deploy Finish

• The command is the same as Hotfix Finish, just change the first command.

Note: the parameter is not -rd. Do not delete the release branch by mistake. It is recommended to set branch protection.

gh pr merge release -r && \
Other commands, permissions as Hotfix Finish
Copy the code

conclusion

With the script above, every time you go to a node where Git needs to collaborate, find the corresponding command to modify it, and execute it from the command line. There is no need to worry about cutting branches or forgetting to synchronize before submitting PR, causing conflicts.

In fact, the script in this article is a simplified version. The complete version has been added with automatic CHANGELOG generation, automatic PR message filling, automatic version upgrade, automatic version tag and other functions. It has even been packaged into a script file that mimics and optimizes the gitFlow-AVH interaction, greatly simplifying operations.

I didn’t put it up because I didn’t want to add to the complexity of the document here, so you can focus on understanding the idea. The full script will be written in a separate article. In addition, in the process of studying this topic, I have also accumulated some shell instructions related to Git operation, and I will write another article, please look forward to it.

“Remember, you’re looking for the best answer, not the best answer you can get.” – Dalio