git branch的管理策略网上有不上文章，流传比较广泛的应该是阮一峰的Git分支管理策略，不过个人感觉这个策略过于简单，在实际的开发环节中，有很多情况不好处理，这里总结一些个人在使用git管理代码仓库过程中的一点想法和思考，以及在实际开发过程采用的方法。
分支分类简介：
基于常见软件开发中场景，将所有分支归纳为三类：
- 正式发布分支：
- release branch
- release_hotfix_xxxx branch
- 开发分支：
- develop (主) branch
- develop_xxxx (feature) branch
- 内测发布分支：
- prepare branch (主) branch
开发阶段简介：
- 开发阶段：develop branch & develop_xxxx branch进行。
- 预发阶段：持续的merge develop to prepare branch，进行内测。
- 线上发布阶段：内测稳定“无问题”后，进入线上发布阶段，由发布owner merge prepare branch to release branch。注：线上发布阶段，prepare branch锁定不再更新。
正式发布分支：
release branch
release branch为正式发布分支，该branch HEAD保持同当前正式发布最新版本一致，每一个正式发布的版本都在release branch有唯一对应的tag。
- 在进入线上发布之前不允许直接push修改到release branch，进入线上发布之后仅允许从develop分支上cherry-pick commit。
- merge， cherry-pick操作只由本次发布owner操作，发布成功打tag。
- 进入线上发布的release branch如果测试出现重大bug，建议重新进入预发阶段，如果出现等级较低的bug，尽量在develop修复，通过cherry-pick将该笔修复合入release branch。（如果develop上无法复现，必须在release分支上修复的，允许在release branch修复，修复后，将该修改cherry-pick回develop branch）
- 线上发布阶段仅修bug，不加功能，如果需要加功能，重新进入开发阶段，或者预发阶段，本次线上发布操作中止。
release_hotfix_(version)_(xxxx) branch
hotfix branch为应对突发情况的发版，基于相应正式release branch基础，checkout一个hotfix branch进行相应修复后，基于该branch进行突发情况的紧急发布。
- 该分支只能基于release branch checkout，命名采用release_hotfix_vX.X.X(_feature)
- hotfix branch上新增的修复commit需同步cherry-pick到develop branch。
- hotfix branch不允许merge回release branch（参见release branch条目1）
思考：为什么hotfix branch不好merge会release branch？
内测发布分支：
内测发布分支作为内部提测使用的分支，隔离开发和内测发布分支，目的：不影响内部提测和开发人员的持续提交。
prepare branch
- prepare对应develop的内测分支。
- 任何情况下不允许直接push修改到prepare branch。
- prepare branch的更新只能通过develop branch merge更新。
- 内测发布分支的merge由内测发布owner操作。
思考：内测发布分支是否必要？
开发分支：
develop branch
develop branch为开发过程中的主干分支，是开发人员操作最多的分支。
- 小功能，小bug，独立模块的提交可以直接提交到develop branch。每笔的提交必须保证可build，可执行。同时需尽量保持模块功能独立，完整，版本单一，不破坏app功能的完整统一，无大问题。
- develop分支上提交的功能commit必须是本开发版需要发布的功能，后续版本的功能开发需求，采用单独拉出develop_feature branch进行开发。
- 提交冲突，需采用rebase合并，不允许采用merge（git pull默认方式）。
rebase和merge的区别:
略
develop_xxxx branch
大feature的模块开发，会破坏develop分支功能完整性，非本期开发需求的开发工作，需拉出单独的develop branch进行。
- branch命名采用develop_xxxx方式，xxxx代表开发feature。
- develop_xxxx branch只能基于develop branch checkout。
- develop_xxxx branch开发完成后通过git merge --no-ff(非fast-forward)合并回develop branch。
- develop_xxxx branch原则上不允许反向merge develop branch(develop to develop_xxxx)。
--no-ff和fast-forward的区别：
这里写图片描述
图片来自网络。
为什么不允许反向merge develop branch？
清晰，美观，好追溯
feature branch一定要merge develop分支才能内测吗？
- feature branch的测试关注于单一模块功能。
- 只有当发现重大bug在develop分支修复，同时该bug影响到了feature分支的测试，可考虑合并develop分支。
- 当develop分支有基础库的大修改，而当前feature分支严重依赖该库，如果不进行合并，后续仍然有很多代码需要兼容该基础库，导致后续大部分代码的编写无生产意义时，可考虑合并develop分支。
如果develop_feature branch一定要merge develop分支才能测试，怎么办？
- 如果该feature由一个人单独开发，建议采用git rebase方式合并。（单独开发的功能合并分支尽量采用rebase，为保证减少合并冲突的难度，建议在开发过程中，以天为单位持续rebase develop branch）
- 如果该feature由多人开发，只能采用git merge进行合并。（尽量在一次merge完成，不要持续多次merge develop branch）
