Practical branch management strategy

First hang a picture of the branch management strategy (can't see the big picture)

Branch introduction

There are a total of 6 remote branches, namely master branch, release branch, feature branch, dev branch, SIT branch, and UAT branch.

• master branch: The master branch contains all the development features, the most comprehensive branch, and the branch lifetime is permanent.
• release branch: the production version branch, which contains all the production features, and the branch lifetime is permanent.
• Feature branch: Iterative feature branch. At the beginning of the iteration, the iterative plan determines the feature point of this development. Each feature point is refined into a feature branch. Each commit on the branch is to implement a specific sub-function of the feature. Every commit will trigger a CI, and the branch lifetime is permanent.
• dev branch: The development and test branch is mainly used for CodeReview when the feature branch is migrated to the dev branch. After the code review, CD will be performed on this branch. The branch life span is the current entire iteration, and the function point merges into the master or release. Revoke.
• SIT branch: integration test branch, the company where conditions permit, has its own dedicated test team, which will pull the code from it for SIT testing, or pull the media package from the product library after the dev branch CD just now, test, and the branch survives The period is permanent.
• UAT branch: user acceptance test branch. After SIT is passed, the code merges into the UAT branch. The test team pulls the code from this branch for compilation, or obtains the media package from the product library, and conducts a preview before production in the UAT environment. The branch survival period is permanent.

Branch relationship

1. Why set up two duplicate branches, master and release?

• The master branch stores all the code and contains all the function points, while the release branch stores all the function points put into production. The relationship between the two is: release is a subset of master, release has some, master has, master has, and release does not necessarily have .
• So why does this happen? After some function points are developed, they may not be put into production. They will wait until a certain time to separate this part of the code from the master and put it into a patch and put it into release for production.

2. Are feature and dev duplicated?

• No repetition, the feature branch exists to sort out the function points. If several function points are developed in a branch, the commit will appear messy, but they are independent of a branch. These commits are continuously submitted on the branch, whether it is a return. It is easy to find out, patch or merge.
• From a functional point of view, the development of a single feature has a small scope of influence, which reduces the risk of conflicts with other feature codes when the code is submitted, and each submission will only trigger the CI of this branch, which leads to less CI queuing and higher efficiency.
• The existence of the dev branch is tailor-made for CodeReview. Even the code that has passed CI and access control has the potential to be optimized, and tool detection cannot replace the old architecture with profound skills.

3. Since the dev branch has generated the target medium, it is fine to put it into production and test directly, why do I need SIT and UAT branches?

• Different test scales:

  • The dev test in this group is a joint test of all functions developed in the group to see if this part of the code affects the functions developed by others, and the scope is small.
  • SIT is an integration test. At this time, it involves joint debugging of all components with a moderate scope.
  • UAT is the most critical test, imitating the production environment to test, in terms of test flow and test frequency, it is the highest, and is also the closest to production, with a larger range.

• Code conflict:

  • Code conflicts during feature branch merging are resolved when merging dev.
  • If problems are found in dev, SIT, and UAT, go back to the feature points for repair in time, and submit them level by level. The earlier bugs and conflicts are found, the lower the cost.

If you have other questions, please leave a message. If the project team is not developing microservices, or the amount of code is small, there is no need to establish so many branches. Remember this sentence: pull the branch for a while, sell the branch to the crematorium.