This article, the third in the Git series, introduces the management of team branches. In our development efforts, branches should be fully utilized in order to better manage the process and better deliver the product. Here I would like to introduce what I think is a fairly complete and general git branch management strategy. Before I begin, I want to clarify what I think the generic development process is for. It has the following characteristics:
- There is a fixed iteration cycle, usually two weeks.
- There is a product release at the end of each iteration. No product is released during the iteration cycle, except for hotfix/emergency issues.
- There is only one major version of the product. This is the case for most Web-based products, and products that do not meet this condition are typically maintaining multiple official versions simultaneously for different customers, countries, and so on.
Here is a table for the specific branch division:
| Branch name | instructions |
|---|---|
dev |
The main branch of development efforts. At the beginning of iteration, each developer creates a feature branch of his own development task from this branch; At the end of the iteration, the code from this branch is used for product release. (You might find it a bit of a problem to release from the Dev branch, which I’ll explain later.) |
master |
An online branch of product code. After the production release, the dev branch code is merged into this branch. Create a hotfix branch from this branch when an emergency problem occurs online and a hotfix is needed. |
f_xxx |
A development task branch that starts with “f_” is also called the feature branch. It is created from the dev branch and merged into the dev branch after the development task is completed. |
hotfix_xxx |
Hotfix branch that starts with “hotfix_”. Create from the master branch; Fix urgent problems online by publishing this branch. Once the problem is fixed, merge the current hotfix branch code into the Master and dev branches. |
According to the table, the actual Git flow in development would look like this:
So how does testing work with this management approach? First, with the completion of the development of the feature branch, the test engineer carries out corresponding functional tests on the Dev branch. Hotfix tests are performed on the Hotfix branch, not on the merged dev branch. After the feature branch and hotfix branch are merged into dev branch, user experience and product process are tested in dev branch.
Finally, don’t forget to tag the Master branch after the product/emergency fix is released.
defects
One problem with this management approach is that there is no pre-release branch, or development and pre-release branches are not separated and only one Dev branch is used. This is also explained in parentheses in the table above. Using the release and dev branches separately has the following advantages:
- Separate functional tests from operational process tests
- Code from the dev branch can be merged into the Release branch to be used earlier for subsequent development work
Why didn’t I separate Dev and release? On the one hand, I don’t have a strong need for either of these advantages, and on the other hand, it’s a hassle to merge code frequently. Complex products and teams that are heavily involved in testing will choose dev/release separation for advantage 1. If you want to see exactly how the dev/release split works, check out this guide: Git Branch Management Best Practices, which I won’t copy here. In fact, this is a classic version control system model proposed by foreigners, big and strong, and troublesome… A successful Git shoot model.
conclusion
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, and how you manage your team’s Git branch should be determined by your own situation. Product form and team configuration will affect the use of your version control system. Thanks for reading and feel free to comment!
Git experience (3) : Team branch management
Reference article
- Git code branch management specification
- Git branch management best practices
- A successful Git branching model