在大型软件工程项目的开发过程中，经常会碰到许多关于git的问题，尤其在多人协作时的分支管理和合并、测试和开发的代码管理混乱等等。这些问题往往导致极其混乱的commit记录，甚至丢失代码。Git Flow应运而生，提供了一种标准化的分支管理流程。

这篇博客就简要总结下Git Flow的使用姿势，也记录一点自己折腾Git、Git Flow所碰到的种种问题和解决方案。

Git Flow解决了什么问题

• 不同角色可以并行开发，尽量保持了角色间的隔离
• 生产环境的稳定代码源
• 符合DevOps开发流程

Git Flow中的分支们

Feature Branches

• 用于多人协作时的不同功能的开发，可以有多个
• 基于develop分支，直接合并回develop分支
• 合并完成后可以删除

Develop Branch

• 只有一个，作为开发的基准分支
• 包含所有要发布到release的代码
• 合并各个Feature分支和Release分支所产生的bug fix
• 对应测试环境的CI/CD
• 大规模开发时常为只读分支，只接受Feature / Release Branch 来的PR

Release Branch

• 对应预发环境CI/CD (实践中有时候也叫做UAT(User Acceptance Test)环境)
• 合并develop分支，完成测试，修复bug
• 包含所有要发布到master/main分支的代码

Hotfix Branch

• 功能上线后的紧急bug fix分支
• 修复完成后提PR到master/develop分支

Master Branch

• 主分支，只读。只接受从其他分支来的PR
• 推送时需要打git tag，做版本追踪

工作流程

1. git init初始化项目，checkout第一个develop分支。
2. 多个开发人员checkout，形成多个feature分支。
3. 功能开发完毕后，merge回develop分支。
4. 当前阶段全部功能开发完毕后，从develop分支checkout出release-x.x.x分支，开始Release。
5. 完成测试、发版配置和次要bug修复后，创建tag并merge到develop和master分支。
6. 从master分支发布生产代码
   1. 若发现bug，则基于master分支checkout出hotfix分支，进行bug修复。
   2. hotfix完成测试后，merge回master/develop分支，并打上tag。

注意事项

• 严禁在几大公共分支（master, release, develop）上使用git rebase合并代码。必须使用git merge，且建议使用--no-ff，确保可以清楚地跟踪每一次merge的改动。
• 私有分支上，例如自己的feature分支可以使用git rebase来同步develop分支的进度。