聊聊Git Flow的使用姿势

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

在大型软件工程项目的开发过程中，经常会碰到许多关于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分支的进度。