一种优雅的Git分支实践
概述
Git分支是git设计灵魂，该如何设计Git分支才能让开发做到一发入魂呢？这是我们项目立项之处就靠考虑好的，一般而言，分支设计需要满足下面几个点：
1>团队开发中避免开发功能相互干扰
2>各类分支：开发，测试，上线，bug，备份，标签等科学管理
下面就来介绍一种应对中小型项目git分支管理最佳实践。
Git flow
Git flow 流程的发明者Vincent Driessen，传送门：
A successful Git branching model » nvie.comIn this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.https://nvie.com/posts/a-successful-git-branching-model/
先摆结论，然后再解释
常用的分支
Master分支
主分支，项目初始点由这个分支发起，后续该分支作为项目版本标记分支，可以理解为备份分支，从这里可以追溯项目发布所有版本。可以从该分支拉起任意项目版本，并能平稳运行。注意：Master分支不允许程序员在此写代码。
Develop 分支
开发分支，初始时居于Master分支创建，团队所有开发代码集中合并的分支。另外，Develop分支维护项目最新代码。
Feature 分支
功能分支，基于Develop分支创建的新分支，用于新功能/新模块的开发。当开发完成之后，需要合并回到Develop分支。这分支是程序员独属分支，不存与团队源码库。
Release分支
当你需要一个发布一个新版本时，基于Develop分支创建一个Release分支。此时需要注意，属于该版本的所有Feature分支需要合并到Develop分支。Release分支创建成功后，对该版本进行测试，改bug，完成后，需要将代码合并到Master和Develop分支。合并到Master分支，会对Master打上标签，表示一个新的版本。合并到Develop分支，需要注意，其他非该版本的Feature分支再没有完成Release分支发布前，不允许合并会Develop分支。
Hotfix分支
当项目上线后，运行发现新的Bug时候，则需要基于Master创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release版本。
开发案例
步骤1：项目立项后，项目经理初始化好项目，创建Master分支，同时基于Master分支创建Develop分支
步骤2：项目要新增功能A，需要分2步实现：功能A1, 功能A2
程序员小明基于Develop分支创建小明Feature分支，完成功能A1， 功能A2 步骤，开发完成后，合并到Develop分支，此时功Develop分支拥有功能A。
步骤3：同时期，项目想尝试创新，尝试实现功能B
程序员小红基于Develop分支创建小红Feature分支，尝试实现功能B
步骤4：功能A需要紧急上线发布，此时功能B暂缓
1>完成功能A之后，合并到Develop中
2>功能A要上线，在Develop基础上创建Release分支，在该分支完成测试/调试/改bug
3>确认完成之后，将Release分支代码合并到Develop分支，合并到Master分支，标记Tag2
4>在Release合并回Develop分支之前，不允许新的Feature分支合并回Develop。
5>当合并到Master跟Develop分支后，可删可不删
步骤5：功能B开发完成，需要发布
逻辑跟步骤4一样，这里不展开说了。
步骤6：功能AB（Tag3版本）上线之后 ，出bug需要修复
1>当出现bug之后，基于Master分支创建Hotfit分支
2>在Hotfit分支完成bug修改，测试通过后，将代码合并到Master分支，打上标签Tag3.1
3>在Hotfit分支完成bug修改，测试通过后，将代码合并到Develop分支，保证Develop分支代码最新。
最后完整版
结语
上面就是Git flow模式的操作所有过程，优点是清晰可控，缺点就是操作复杂，需要维护2个长期的分支，Develop跟Master分支。这导致每次操作需要频繁切换分支。