This article combines my own project experience and online information, plus some personal experience. This article is written out of love for git management tools.
git management model
Distributed but centralized, this is the best illustration of the git management model. The model diagram is shown below:
The origin in the above figure is a " central repository " , of course, this central repository is only considered as such ( because Git is distributed, technically there is no central repository ) .
Each developer pulls and pushes to origin , but in addition to the centralized push-pull relationship, each developer can also pull changes from other developers . For example, for a relatively large new feature, it is likely that 2 or more developers will be deployed before the code is committed to origin . There are several small teams in the picture above: Alice and Bob , Alice and David , Clair and David . Team members first pull the code to the captain, and then the captain pulls the code to the origin library.
main branch design
The central repository has two branches: master and develop .
The master branch on origin , which Git users should be familiar with, has a develop branch parallel to master
We take origin/master as the main branch, and the HEAD of the source code always represents the production-ready ( deployable at any time ) state. The code on origin/develop is prepared for the next code release. Daily builds are also based on this branch.
When the develop branch reaches a stable state and is ready to be released, all changes are merged into the master branch and marked with a version number. This way every merge with master will have a new deployment release. The following are the relevant commands:
$git checkout –b develop master
Do development work on the develop branch.
$git checkout master
$git merge –no-ff develop
Support branch design
Our development model uses some support branches placed next to the master and develop branches to facilitate parallel development between development teams. Unlike the main branch, these branches are time-bound because they will all be removed eventually.
The different branches we will use are: Feature branches , Release branches , Hotfix branches .
Each branch has its own role, and there are strict regulations, such as: which branch can only be opened from, and only merged into that branch.
Feature branches
The regulations are as follows:
Inherited branch : develop
Merge branch: develop
Naming convention: except master, develop, release-, hotfix-
Feature branches are used to develop new features ( both short term and long term ) . When starting to develop a new feature, it is likely that it is not known in which target version the feature will appear. Once development is complete it can be merged into develop , and of course discarded if development fails.
Create and complete a Feature branch
According to Feature branches , the creation command is as follows:
$ git checkout -b myfeature develop
When new features are complete, they can be merged into develop
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
The --no-ff ( note: no fast foward) tag causes each merge to create a new commit record. Even if this commit is only fast-foward , this avoids losing information
Release branch
The regulations are as follows:
Inherited branch : develop
Merge branch: develop and master
Naming convention: release-*
Release branches are prepared for new production releases , can have some minor bugs , and prepare some metadata ( version number, build date, etc. ) for the release . By putting all this work into the Release branch , the develop branch has a clearer idea of what features to develop in the next release.
The key factor in merging from the develop branch to the release branch is that the develop branch reaches the state required by the release branch. At least all features for this release should be merged. As for those features that will be available in the future, you can put them first. Then it's all about assigning a version number to the upcoming release.
Create a Release branch
Release branch is created by developing branch. For example, if 1.1.5 is the current production release , then there will be a larger release. The status of develop is ready for release. After discussion, it is decided to release version 1.2 , so we create a release branch and give this branch a new version number
$ git checkout -b release-1.2 develop
这个新分支可能会存在一定的时间，直到可以被合并到production branch。这段时间内，bug修补可以在这个分支上进行(而不是develop分支)。添加新特性(尤其比较大的)是不允许的。最后还是要被合并到develop，然后继续在develop分支上开发，直到下一个版本。
完成一个release branch
当release branch已经准备就绪，需要做几件事。首先，release分支被合并到master分支上(每一个提交到master上的commit都是一个新版本，切记)。然后master上的commit都要添加tag，方便将来查看和回滚。最后release上所做的修改必须合并到develop分支上，保证bug已被修补。
前两个步骤：
$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
为了把release上的改变保存到develop，我们需要合并到develop
$ git checkout develop
$ git merge --no-ff release-1.2
这个步骤可能会导致冲突，如果这样的话，解决冲突，然后再提交。
现在一切都完成了，可以把release branch干掉了。
$ git branch -d release-1.2
Hotfix branch
规定如下：
继承分支: master
合并分支：develop 和 master
命名规范：hotfix-*
Hotfix branch和Release branch有几分相似，都是为了新的production release而准备的。比如运行过程中发现了bug，就必须快速解决，这时就可以创建一个Hotfix branch，解决完后合并到master分支上。好处是开发人员可以继续工作，有专人来负责搞定这个bug。
创建Hotfix branch
Hotfix是从master分支上创建的。假如当前运行版本是1.2，然后发现有bug，但是develop还在开发中，不太稳定，这时就可以新开一个Hotfix branch，然后开始解决问题。
$ git checkout -b hotfix-1.2.1 master
解决问题，一次或几次commit
$ git commit -m "Fixed severe production problem"
完成Hotfix branch
当结束时，bugfix要被合并到master，同时也要合并到develop，保证下个版本发布时该bug已被修复。这跟release branch完成时一样。
首先更新master和tag release
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
接下来与develop合并
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
有一个例外，就是当存在一个release branch存在时，bugfix要被合并到release而不是develop，因为release最终会被合并到develop。
最后移除branch
$ git branch -d hotfix-1.2.1
总结
这个管理模型应该算是达到行业标准的一个模型了。在实际的开发过程中，如果不用太过于考虑项目成本及项目成员的能力水平时，这样的模型应当是首选。