Git experience (3): team branch management


This article is the third in the GIT series. I want to introduce the management of team branches. In our development work, in order to better manage the process and deliver products, we should make full use of the function of branch. Here I would like to introduce what I think is a relatively complete and general git branch management strategy. Before we start, we should first explain what kind of development process I think “general” is aimed at. Its characteristics are as follows:

  • There is a fixed iteration period, usually two weeks.
  • A product release is conducted after each iteration. No product will be released during the iteration cycle unless it is hotfix / urgent.
  • The product has only one major version. Most web-based products are like this. Products that do not meet this condition generally maintain multiple official versions for different customers, countries and other conditions at the same time.

Here is a table for the specific branch division:

Branch name explain
dev The main branch of development work. At the beginning of the iteration, each developer creates a feature branch of his own development task from this branch; At the end of the iteration cycle, the code of this branch is used for product release. (you may think there is a problem with releasing products from the dev branch. I’ll explain later)
master Branch of online product code. After the product is released, the code of the dev branch is merged into this branch. When an urgent problem occurs on the line and hotfix needs to be performed, create a hotfix branch from this branch.
f_xxx The development task branch that begins with “f_9;” is also called the feature branch. Create from the dev branch and merge to the dev branch after the development task is completed.
hotfix_xxx Hotfix branch starting with “hotfix_”. Create from the master branch; Fix online emergencies by publishing this branch. After the problem is fixed, merge the code of the current hotfix branch to the master and dev branches.

According to the description in the table, the GIT process in actual development will look like this:

Git experience (3): team branch management

So how is the test conducted according to this management method? First, with the development of the feature branch completed, the test engineer performs the corresponding function test on the dev branch; Hotfix testing should be performed on the hotfix branch, not on the merged dev branch; After the feature branch and hotfix branch are merged into the dev branch, the user experience and product process are tested in the dev branch.

Finally, after the product / emergency repair is released, don’t forget to tag the master branch.


There is a problem with this management method, that is, there is no pre release branch, or the development branch is not separated from the pre release branch, and only one dev branch is used. This is also the problem to be explained in the brackets of the above table. The use of separate release and dev branches has the following advantages:

  1. Separate the test for function from the test for operation process
  2. After the dev branch code is merged into the release branch, it can be used for subsequent development work earlier

Why didn’t I choose the separation of Dev and release? On the one hand, I have no strong demand for the above two advantages. On the other hand, it requires frequent code merging, which is too troublesome. Products with complex structure and teams with large investment in testing will choose dev / release separation because of advantage 1. If you want to know how dev / release separation works, you can refer to this introduction: git branch management best practice, I won’t copy here. In fact, this is a classic version control system working mode proposed by foreigners, which is large, strong and troublesome… The original text is here: a successful git branching model.


The branch management strategy proposed in this article is summarized according to my own practical experience and can meet the basic requirements. However, this is only a general template. How to formulate the GIT branch management of the team should be determined according to their own specific conditions. The product form and team staffing will affect the use of the version control system. Thank you for reading and welcome to put forward your views!

Link to the original text of this article: git experience (III): team branch management

Reference articles

  • Git code branch management specification
  • Git branch management best practices
  • A successful Git branching model