简介
•Git Flow是一套使用Git进行源代码管理时的一套行为规范
•Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践
•Git Flow重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题
•Git Flow通过创建和管理分支，为每个分支设定具有特定的含义名称，并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离
Git Flow中的分支
•主分支
•master：随时可供在生产环境中部署的代码的分支
•develop：保存当前最新开发成果的分支
辅助分支
- feature：用于开发新功能时所使用的分支
- release：用于辅助版本发布的分支
- hotfix：用于修正生产代码中的缺陷的分支
feature分支
接到一个新的功能的开发任务后，从develop分支发起，并push成为远程分支
命名规范：例如开发一个项目信息的功能，则创建的分支名为：feature-project-info
每天下班前push代码到远程，进行备份，防止本地电脑故障导致代码丢失。一般feature分支由单人开发维护，可视为个人分支，所以push的代码不稳定也不会影响他人
每个人只需要维护好自己的功能分支，无需与他人进行频繁的合并，极大的降低了冲突概率，降低了代码互相覆盖的风险，从而实现多人多功能的并行开发
若不同的feature分支之间有依赖关系，则等目标feature分支开发完成以后，直接pull目标feature分支即可，若需要协同开发，则多人使用同一条feature分支即可
功能相关的代码开发完毕，并通过自测稳定以后，合并回develop分支，并可以删除feature分支，feature分支的生命周期到此结束
注意事项：所有merge操作，必须使用–no-ff参数禁止fast forward合并，防止丢失合并历史信息，例：git merge –no-ff feature-project-info
feature分支额外自定义规范
- 开发经理创建公共集成feature分支
- 开发人员创建自己的feature分支，并进行开发
- 开发完成并自测稳定以后，合并到公共集成feature分支上
- 再由开发经理统一合并到develop分支上
release分支
•release分支是为发布新版本提供支持的分支，从最新的develop分支发起（已合并所有此次要上线的feature） •命名规范：一般以发布日期为分支名，如7月15日计划上线，则分支名为：release-0715或release-7.15 •发布测试环境应拉取此分支的代码进行打包（结合jenkins自动化部署） •测试中发现的bug，也直接在此分支进行修复，与可能还在往前演进的develop分支隔离并行，控制发布的代码范围，防止多余的功能代码被意外的发布上线 •测试通过后，由开发经理合并到master（master分支受保护，合并需要权限），然后使用master的代码进行打包，发布生产环境，发布后，并打上版本号的tag •发布上线后，需要将master合并回develop，将release分支中修改的bug同步，防止bug重现
release分支额外自定义规范
•多版本上线时间相近，并且需要进行功能点隔离时
•创建多条release分支，不同的公共集成feature分支直接合并到对应的release分支上
•而不是全部合并到develop分支上，从而达到不同的发布版本功能范围隔离的效果
hotfix分支
- hotfix分支是版本上线后，在线上发现了bug，从master分支发起的紧急修复bug的分支
- 由于它的发布属性，可以把它看作是计划外的release分支，也就是紧急发布分支
- bug修复后，不但要合并到master，还要合并回develop，防止bug重现
Git Flow闭环全流程概览
- 接到一个功能开发任务，创建对应的feature分支
- 功能开发完成后，合并回develop
- 从最新的已包含所有功能的develop上发起release分支
- 从release分支打包发布测试环境，开始测试，修复bug
- 测试完毕，合并回develop，合并到master，发布上线， 打tag
- 线上发现bug，从master发起hotfix分支，修复后，合并回master与develop，在master上打上tag，方便回溯
- 开启下一个流程
