参考资料
简介
规范的分支管理策略可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。
常驻分支
整个版本库中应该有两个一直演进的常驻分支，分别是 master 和 develop。
master
主分支上的代码提交都是处于可发布状态的，是所有提供给用户使用的正式版本。我们使用版本库初始化时默认创建的 master 分支。
develop
主分支只用来发布版本，日常的工作都应该提交到开发用的 develop 分支。该分支 HEAD 源码始终体现下个发布版的最新软件变更。当 develop 分支的源码到达了一个稳定待发布状态时，就可以合并到 master 分支中。
辅助分支
除了常驻分支外，开发流程中还需要各种辅助性分支，用来支持团队成员们并行开发，使功能易于追踪，协助生产发布环境准备，以及快速修复实时在线问题。与常驻分支不同，辅助分支的是生命期是有限的，当它们的提交被合并到常驻分支后，就会被移除。辅助分支包括：feature、fix、release 和 hotfix。
feature
feature 分支从 develop 分支分出，为了实现某个特定的功能，并最终合并到
develop 分支中。
fix
fix 分支从 develop 分支分出，为了修复测试过程中发现的某个 bug ，并最终合并到 develop 分支中。
release
在 develop 分支达到了发布的理想状态时，就分出一个 release 分支。release 分支是为新版本的发布做准备的，它允许我们在最后时刻做一些细小的修改，如一些 bug 的修改和准备发布元数据(版本号等)。在确定发布后，就将 release 分支合并到 master 分支和 develop 分支，并移除 release 分支。
hotfix
hotfix 分支与 release 分支相似，他们都为新的生产环境发布做准备，尽管这是未经计划的。当生产环境发现 bug 且必须马上修复时，从 master 分支分出 hotfix 分支，在修复提交后，将 hotfix 分支合并到 master 分支和 develop 分支，并移除 hotfix 分支。
工作流程
开发人员通过 issue 列表获取新功能开发任务，然后从 develop 分支分出 feature_[issue number] 分支，在新功能开发完成后，将 feature_[issue number] 分支合并到 develop 分支，并将其移除。
git checkout -b feature_[issue number] develop
git checkout develop
git merge --no-ff feature_[issue number]
git branch -d feature_[issue number]
在新功能被测试后，开发人员通过 issue 列表获取修复 bug 的任务，然后从 develop 分支分出 fix_[issue number] 分支，在修复工作完成后，将 fix_[issue number] 分支合并到 develop 分支，并将其移除。
git checkout -b fix_[issue number] develop
git checkout develop
git merge --no-ff fix_[issue number]
git branch -d fix_[issue number]
待新功能稳定将要发布时，从 develop 分支分出 release_[version number] 分支，version number 是将要发布的版本号，在确定 release_[version number] 分支上不会有其他改动后，就可以将其合并到 develop 分支和 master 分支，并移除。在 master 分支的新提交点上添加版本号 tag。
git checkout -b release_[version number] develop
git checkout master
git merge --no-ff release_[version number]
git tag -a v[version number]
git checkout develop
git merge --no-ff release_[version number]
git branch -d release_[version number]
如果生产环境发现 bug 且必须马上修复时，从 master 分支分出 hotfix_[version number] 分支，在修复提交后，将 hotfix_[version number] 分支合并到 master 分支和 develop 分支，并移除 hotfix_[version number] 分支。在 master 分支的新提交点上添加版本号 tag。
git checkout -b hotfix_[version number] master
git checkout master
git merge --no-ff hotfix_[version number]
git tag -a v[version number]
git checkout develop
git merge --no-ff hotfix_[version number]
git branch -d hotfix_[version number]
关于 merge 命令中的--no-ff参数，即使该操作可以快进式合并(fast-farward)，但仍然会采用正常合并，在分支上生成一个新的节点。这样就不会丢失辅助分支的历史信息，保证了版本演进的清晰。
团队协作开发
大部分的软件开发工作都不是由一个人独立完成的，而是需要一个团队协作完成。一般我们需要在服务器端搭建一个中心代码库，而团队中的成员都是通过本地代码库不断的和中心代码库之间实现拉取和推送代码的操作来协作完成任务的。
中心代码库可能只存在 master 和 develop 两条常驻分支。其他的辅助分支，开发人员可以在任务完成后，先并入本地的常驻分支，之后再推送到中心代码库来同步更新。向中心代码库提交代码时要注意的一点是，一定要将本地的提交 rebase 到服务器端最新的提交之后再推送代码，这样可以避免不必要的合并分支节点，使演进历史更清晰。
一般团队中都会通过代码审查来提高整个软件的代码健壮性。这时，完成任务的开发者不能自己将辅助分支合并入常驻分支，而要由审查人员在通过后将其并入。审查代码的开发者可以直接从完成任务的开发者的本地版本库拉取分支，也可以通过让完成任务的开发者将分支提交到中心代码库来获取，但要在并入常驻分支后，将中心代码库中的辅助分支删除。
为了使代码提交历史更加清晰，可进一步规范，将任务单元划分的尽量小，即每一个辅助分支最终在并入常驻分支时都只有一次提交。开发人员在完成任务前，可根据需要执行多次提交，但在合并入常驻分支时，要通过rebase -i命令将提交变为一次。同时要对提交信息的格式规范化，如：
[功能辅助分支名][模块名]:简短的描述信息[issue number]
在提交信息格式化后，每次将辅助分支合并入常驻分支时，不需要使用--no-ff参数，因为提交信息完全可以说明辅助分支的历史，在去掉这些空的合并节点后，会使提交历史更加简洁清晰。
网友评论