参考资料
简介
规范的分支管理策略可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。
常驻分支
整个版本库中应该有两个一直演进的常驻分支，分别是 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参数，因为提交信息完全可以说明辅助分支的历史，在去掉这些空的合并节点后，会使提交历史更加简洁清晰。
2020.02.10 更新：关于 iOS 项目分支管理的想法
当前工作中，iOS 应用发布新版本的方式与 web 开发不同，需要通过 Xcode 手动归档，然后向 App store 提交，待审核通过后，才算是发版成功。在这种情况下，无法利用钩子自动发布 master 分支上的代码，那么其存在的意义就不大了，考虑仅维护 develop 一个常驻分支。develop 分支保持着程序的最新可用状态，当一部分开发工作完成后，develop 分支上的某次提交会作为对外发布的版本。当然，需要人为控制的一点是，必须注意并入的提交的顺序，不能让下一版本的提交在本次版本的提交之前并入，否则就会把下一版本的内容提前发布出去了。
当确定了要发版的提交后，假设发版的相关提交、可能出现的紧急修复的提交、下一版本的需求提交是按先后顺序操作的，那么仅需要 develop 分支就够了，在对应的提交打版本标签即可。但现实中，很多时候情况并不是这样的，发版的操作可能有一定的延后性，而需要紧急修复的 bug 的出现，更是具有不确定性。在确定了要发版的提交后，后续的工作会继续进行，下一版本的需求提交就会开始并入 develop 分支中，正是因为这样，所以发版的提交或紧急修复的提交就不能直接并入 develop 分支了，这会导致将下一版本的部分提交提前发布出去。
当发版时，我们需要在发版提交上新建 release 辅助分支，之后发版的相关提交在该分支上操作，发布新版本后将 release 分支上新的提交并入到 develop 分支上，之后即可删除 release 分支，而版本标签就应该打在 release 分支的最后一次提交上。iOS 开发因为审核的问题，在将 release 分支的最新提交打包到 App store 审核时，发版工作并没有完成，还不能将 release 分支并入 develop 分支。假如审核未通过，需要修改代码，则在 release 分支上继续进行提交，因为这还是对同一个版本的发布，直到审核通过后，将 release 分支的提交并入 develop 分支。如果并入 release 分支时，develop 分支上没有下一版本的提交，那么快进式合并则会使 release 分支的提交像需求提交一样直接在开发分支的直线上，但为了与不能快进合并的情况以及可能的紧急修复的情况统一，并且可以更醒目地标出发布的版本，合并时使用--no-ff参数，强制创建新的提交。
对于紧急修复的操作，如果主分支上没有下一版本的提交，那么紧急修复完全可以当做下一个版本来操作（因为 iOS 改动一定要提交新版本）。而如果已经有了下一版本的提交，则应该在当前版本对应的提交（release 分支上的最后一次提交）上新建 hotfix 辅助分支，然后在该分支上提交修复 bug 、修改发版信息、可能的对审核未通过的修改。待针对紧急修复的新版本上架后，将 hotfix 分支并入 develop 分支中，之后即可删除 hotfix 分支，版本标签应该打在 hotfix 分支的最后一次提交上。
