Git分支管理策略

git branch的管理策略网上有不上文章，流传比较广泛的应该是阮一峰的Git分支管理策略，不过个人感觉这个策略过于简单，在实际的开发环节中，有很多情况不好处理。另一篇比较有名的文章则是：a-successful-git-branching-model 该文对于各分支的merge操作过于随意，会导致branch线十分繁琐，又过于复杂。这里总结一些个人在使用git管理代码仓库过程中的一点想法和思考，以及在实际开发过程采用的方法。

分支分类简介：

基于常见软件开发中场景，将所有分支归纳为三类：

• 正式发布分支：
  
  • release branch
  • release_hotfix_xxxx branch
• 开发分支：
  
  • develop (主) branch
  • develop_xxxx (feature) branch
• 内测发布分支：
  
  • prepare branch (主) branch

开发阶段简介：

1. 开发阶段：develop branch & develop_xxxx branch进行。
2. 预发阶段：持续的merge develop to prepare branch，进行内测。
3. 线上发布阶段：内测稳定“无问题”后，进入线上发布阶段，由发布owner merge prepare branch to release branch。注：线上发布阶段，prepare branch锁定不再更新。

正式发布分支：

release branch

release branch为正式发布分支，该branch HEAD保持同当前正式发布最新版本一致，每一个正式发布的版本都在release branch有唯一对应的tag。

1. 在进入线上发布之前不允许直接push修改到release branch，进入线上发布之后仅允许从develop分支上cherry-pick commit。
2. merge， cherry-pick操作只由本次发布owner操作，发布成功打tag。
3. 进入线上发布的release branch如果测试出现重大bug，建议重新进入预发阶段，如果出现等级较低的bug，尽量在develop修复，通过cherry-pick将该笔修复合入release branch。（如果develop上无法复现，必须在release分支上修复的，允许在release branch修复，修复后，将该修改cherry-pick回develop branch）
4. 线上发布阶段仅修bug，不加功能，如果需要加功能，重新进入开发阶段，或者预发阶段，本次线上发布操作中止。

release_hotfix_(version)_(xxxx) branch

hotfix branch为应对突发情况的发版，基于相应正式release branch基础，checkout一个hotfix branch进行相应修复后，基于该branch进行突发情况的紧急发布。

1. 该分支只能基于release branch checkout，命名采用release_hotfix_vX.X.X(_feature)
2. hotfix branch上新增的修复commit需同步cherry-pick到develop branch。
3. hotfix branch不允许merge回release branch（参见release branch条目1）

思考：为什么hotfix branch不好merge会release branch？

内测发布分支：

内测发布分支作为内部提测使用的分支，隔离开发和内测发布分支，目的：不影响内部提测和开发人员的持续提交。

prepare branch

1. prepare对应develop的内测分支。
2. 任何情况下不允许直接push修改到prepare branch。
3. prepare branch的更新只能通过develop branch merge更新。
4. 内测发布分支的merge由内测发布owner操作。

思考：内测发布分支是否必要？

开发分支：

develop branch

develop branch为开发过程中的主干分支，是开发人员操作最多的分支。

1. 小功能，小bug，独立模块的提交可以直接提交到develop branch。每笔的提交必须保证可build，可执行。同时需尽量保持模块功能独立，完整，版本单一，不破坏app功能的完整统一，无大问题。
2. develop分支上提交的功能commit必须是本开发版需要发布的功能，后续版本的功能开发需求，采用单独拉出develop_feature branch进行开发。
3. 提交冲突，需采用rebase合并，不允许采用merge（git pull默认方式）。

rebase和merge的区别:
略

develop_xxxx branch

大feature的模块开发，会破坏develop分支功能完整性，非本期开发需求的开发工作，需拉出单独的develop branch进行。

1. branch命名采用develop_xxxx方式，xxxx代表开发feature。
2. develop_xxxx branch只能基于develop branch checkout。
3. develop_xxxx branch开发完成后通过git merge –no-ff(非fast-forward)合并回develop branch。
4. develop_xxxx branch原则上不允许反向merge develop branch(develop to develop_xxxx)。

–no-ff和fast-forward的区别：

图片来自网络。

为什么不允许反向merge develop branch？

清晰，美观，好追溯

Git commits历史是如何做到如此清爽的？

feature branch一定要merge develop分支才能内测吗？

1. feature branch的测试关注于单一模块功能。
2. 只有当发现重大bug在develop分支修复，同时该bug影响到了feature分支的测试，可考虑合并develop分支。
3. 当develop分支有基础库的大修改，而当前feature分支严重依赖该库，如果不进行合并，后续仍然有很多代码需要兼容该基础库，导致后续大部分代码的编写无生产意义时，可考虑合并develop分支。

如果develop_feature branch一定要merge develop分支才能测试，怎么办？

1. 如果该feature由一个人单独开发，建议采用git rebase方式合并。（单独开发的功能合并分支尽量采用rebase，为保证减少合并冲突的难度，建议在开发过程中，以天为单位持续rebase develop branch）
2. 如果该feature由多人开发，只能采用git merge进行合并。（尽量在一次merge完成，不要持续多次merge develop branch）