1 Basics: Git branch types

Branches are divided into two categories in git official documents, and branch management policies introduced later are expanded based on this category.

1.1 Long-term Branch

Periodically merge certain subject branches into other long-term branches at different stages throughout the project development cycle. These long-term branches fall into roughly three types:

(1) The code on the branch reaches a steady state, probably already released or about to be released. Such as the master branch.

(2) There are also parallel branches called Develop or next, which are used for subsequent development or stability testing. When these branches reach a stable state, they can be merged into the Master branch.

(3) There are also some proposed branches, which may contain some immature content, and when they have a certain degree of stability, they will be merged into more stable branches.

The more stable the branch, the further back the pointer in the code commit history:

1.2 Topic Branches

A topic branch is a short-term branch used to implement a single feature or work related to it. May be created, used, merged, or deleted frequently. This facilitates quick and complete context switching, disperses work across different pipelines, each branch of the pipeline is related only to its target feature, and makes it easier to see what changes you’ve made during code reviews.

2 git-flow model

Git-flow model is a classic model proposed by Vincent Driessen in 2010. He divided branches into different types, each with a clear responsibility.

2.1 The main branches of The branch

There are two resident branches: Master and Develop.

The latest code in the Master branch is always in a stable state ready to be released to production.

The latest code in the Develop branch always reflects the latest changes in preparation for the next release. Some people also call this branch Integration Branch, and this is where any nighttime automated build is built.

When the code in the Develop branch reaches a stable state and is ready for release, it needs to be merged into the Master and tagged to mark the release number. Therefore, each time a change is merged into the Master branch, a new version is released.

2.2 Supporting Branches

Supported branches have a short lifetime and will eventually be removed. It is used to help team members develop in parallel, simplify feature tracking, prepare for product release, and assist in quickly solving practical problems in production.

Three types of supported branches are commonly used:

  • Feature branches
  • Release branches
  • Hotfix branches

Each of these branches serves a specific purpose and is governed by strict rules. These branches are not technically different, just classified according to how we use them.

2.3 Feature branches (topic branches)
  • Branch source: Develop
  • Merge into branch: Develop
  • Branch naming convention: any name except master, develop, release-*, or hotfix-*.

The feature branch is usually used to develop new features and is eventually merged back into the Develop branch or abandoned.

Functional branches typically exist only in the developer’s local repository, not in Origin.

$git checkout -b myfeature develop

The feature branch needs to be merged back into the Develop branch:

$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
Copy the code

–no-ff creates a commit for the merge to record the branch information for the merge; If this parameter is not used, there will be no merge commit when merging branches.

2.4 Release branches
  • Branch source: Develop
  • Merge into branches: Develop and Master
  • Branch naming convention: release-*

The release branch prepares for a new release by doing final checks, minor bug fixes, and preparing metadata (version numbers, build dates, etc.) for the release.

When the Develop branch is close to reaching the desired state for a new release, a new release branch can be created from it, at which point all the features of the new release have been merged into Develop. Other features in future releases will have to wait until the release branch is created before they can be incorporated into the Develop branch.

When you create the release branch, you determine the version number to be released. For example, the current release is 1.1.5, and if the next release is a larger release, the release branch can be named Release-1.2.

$git checkout -b release-1.2 develop $./bump-version.sh $git commit-a -m Bump Version Number to 1.2
Copy the code

When the release branch was created, we upgraded the version number. In this case, bump-version.sh is a fictitious shell script that changes some files in the working copy to reflect the new version. (Of course, you can change it manually.) Then, commit the updated version number.

The new branch will remain in place until the final release, during which time only bug fixes are allowed and major new features are not allowed. When the release branch is in such a state that it can be published, the master branch is merged. Then tag the commit on the master branch to record the version number, which can be rolled back and forth or traced back. Finally, the changes on the Release branch are merged back into the Develop branch. Conflicts may occur when merging back to the Develop branch because the develop branch may have merged some new feature, which needs to be resolved and committed.

$git checkout master $git merge --no-ff release-1.2 $git tag-a$git checkout develop $git merge --no-ff release -- 1.2Copy the code

You can also use the -s or -u flag to encrypt the tag signature.

Finally, you can delete the release branch.

$ git branch -dRelease 1.2Copy the code
2.5 Hotfix branches
  • Branch source: master
  • Merge into branches: Develop and Master
  • Branch naming convention: hotfix-*

When a production version has a serious bug that must be fixed immediately, you can create a hotFix branch from the current master branch to fix the bug.

For example, if there is a serious bug in a production environment with version 1.2 that needs fixing, you can create a hotfix-1.2.1 branch.

$git checkout -b hotfix-1.2.1 master $./bump-version.sh 1.2.1 $git commit-a -m Bump Version Number to 1.2.1
Copy the code

Git commit -A -m combines the git add and Git commit steps.

Fix bugs and submit:

$ git commit -m "Fixed severe production problem"
Copy the code

After fixing, these bugfixes need to be merged into master, and they also need to be merged back into Develop.

$git checkout master $git merge --no-ff hotfix-1.2.1 $git tag-a1.2.1 $git checkout develop $git merge --no-ff hotfib-1.2.1Copy the code

If there is also a release branch, then the Hotfix branch does not need to be merged back into the Develop branch, but into the release branch because the release branch will eventually turn back into the Develop branch. However, if the bug affects development on the Develop branch, you can merge it into the Develop branch.

Finally, remove the Hotfix branch.

$ git branch -dHotfix - 1.2.1Copy the code
2.6 evaluation

Since gitflow-Model is more suitable for multi-release scenarios, web applications today rarely require multiple releases, and more often require continuous delivery of one release, a simpler model, such as GitHub Flow, is recommended.

Advantages: The rights and responsibilities of each branch are clear, clear and controllable, which is the enlightenment model for many branch management strategies.

Disadvantages:

  1. Merge conflicts: There may be many long-running branches: master, develop, release, hotfix, and several parallel feature branches. There could be conflict between the two. Frequent manual conflict resolution not only increases the workload, but also increases the risk of error.
  2. Function separation: When functions are developed in parallel, the combined functions cannot be tested before merging branches, and there may be interaction after merging.
  3. No continuous delivery: Git-Flow prefers scheduled releases, and a feature can go through many steps before it is released to a formal environment, making continuous delivery difficult.
  4. No continuous integration: Continuous integration encourages more frequent code integration and interaction, resolving conflicts early, while git-Flow’s branching strategy isolates code and delays code integration as much as possible.

3 GitHub flow

GitHub Flow is a lightweight, branch-based workflow. Is the workflow that Github uses. It only keeps a master branch. When developing new functions, it creates a feature branch based on the master, and initiates pull-request after the development is completed. Discussion and review within the group, and timely feedback, during which developers can continue to submit code. After passing the review, it is merged back into the Master branch and deployed.

3.1 evaluation

Advantages:

  1. The branch is simple. There are only master branches and feature branches, which reduces the complexity of branch management.
  2. Compliant continuous integration: early feedback, early solution of problems, short integration cycle.

Cons: No other code can be committed until the master branch is released, otherwise the master branch will be inconsistent with the version just released.

4 Gitlab flow

Git Flow and Github Flow and their advantages are absorbed and recommended by Gitlab, which can be seen in this article by Teacher Ruan Yifeng, and will not be repeated here.

5 Trunk Based Development Trunk Development

There is one branch as the main branch, the master branch, to which developers either submit code directly or leave the Feature branch local. In principle, the repository has only one master branch. Development team members can commit code to the trunk multiple times a day, allowing the team’s work to be consolidated within 24 hours and keeping the code versions ready for release. Avoiding multiple branches over time facilitates continuous integration and continuous delivery.

The release branch is created and tagged directly from the main branch, and is deleted when the release is complete. In other words, the publish branch is a snapshot of the main branch at a point in time.

Backbone development requires a workable release every time, which brings some problems. Here are some solutions:

  1. How to avoid releasing unfinished features: Use Feature Toggle — Add a feature switch to your code to control whether a new feature is turned on or off.
  2. How to fix online bugs: Tag the release, if there is a problem with the release, if there is no new commit for the master branch, fix it on the master branch and merge it into the release branch. If the master branch already has a new commit:
  • Create a release branch from the tag
  • Fix bugs on master
  • Cherry pick the bug fix submission to the Release branch
  • Tag and publish in the Release branch

6 AoneFlow

AoneFlow is a code branch management strategy used by Ali. “It basically takes into account the characteristics of TrunkBased’s ‘easy continuous integration’ and GitFlow’s ‘easy to manage requirements’, while avoiding the red tape of GitFlow”.

AoneFlow uses only three branch types: trunk branch, feature branch, and release branch. A complete process is as follows:

  1. Create a feature branch (prefixed feature/) from the trunk and develop code on that branch. There may be multiple feature branches developed in parallel.

  1. Create a release branch (prefixed with release/) from the trunk and merge all the feature branches to be published into the release branch. There can be multiple release branches, each corresponding to a different environment, such as release/test branch for deployment test environment, release/ PROd branch for online formal environment, and so on. It is also possible for one publishing branch to correspond to multiple environments. The feature composition of the release branch is dynamic. For example, if a function or feature is not released as scheduled for some reason, you can delete the release branch and rebuild a release branch with the same name from the trunk, merging only the feature branches that need to be released. The release branches are loosely coupled, allowing different feature combinations to be published to different environments.

  1. The release branch is published online, merged back into the main branch, labeled, and finally deleted from the feature branch associated with the release branch.

References

  1. Profiles from Git Branch Development Workflows
  2. Git Workflow
  3. Branch models and trunk development
  4. Version branch management standard – Trunk Based Development Trunk Development model
  5. Git Branch – Branch development workflow
  6. A successful Git branching model
  7. Understanding the GitHub flow
  8. At Ali, how do we manage our code branches?
  9. Google code management
  10. cn.trunkbaseddevelopment.com/