聊聊Git Flow的使用姿势

发布于 2022-07-14  3 次阅读


在大型软件工程项目的开发过程中,经常会碰到许多关于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. 功能开发完毕后,mergedevelop分支。
  4. 当前阶段全部功能开发完毕后,从develop分支checkoutrelease-x.x.x分支,开始Release。
  5. 完成测试、发版配置和次要bug修复后,创建tag并mergedevelopmaster分支。
  6. 从master分支发布生产代码
    1. 若发现bug,则基于master分支checkouthotfix分支,进行bug修复。
    2. hotfix完成测试后,mergemaster/develop分支,并打上tag。

注意事项

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