TOC

Git 分支管理策略（工作流）

作者：
日期：
标签： Git 项目管理

Git Logo

Git Flow

荷兰程序员 Vincent Driessen 2010 年提出。

Git Flow
PDF 下载

  • master 主干
  • develop 开发分支
  • feature/xxx 功能开发分支（临时）
    基于 develop 创建，开发完成之后：合并到 develop 分支，删除
  • release/xxx 预发布分支（临时）
    基于 develop 创建，测试通过之后：合并到 master 分支，打 tag，合并到 develop 分支，删除
  • hotfix/xxx 问题修复分支（临时）
    基于 master 创建，问题修复之后：合并到 master 分支，打 tag，合并到 develop 分支，删除

特点：基于版本交付

PS: 作者于 10 年后，也就是 2020 年，更新了一次，表示：对于互联网应用的开发应该考虑更加简单的工作流，比如 GitHub Flow。但不管怎样，应该结合自身的实际情况，不能盲目照搬。

GitHub Flow

GitHub Flow

  1. 从 master 拉分支，提交，推送
  2. pull request
  3. 评审，测试
  4. merge 到 master

特点：基本不涉及项目的分支管理，主要是对多人协作方式提出建议：Pull Request。适合多人参与的开源项目，由项目管理员负责维护主干。

中间可以借助自动化工具来静态分析、部署、测试，提升开发速度。但这些工具不是 GitHub Flow 专有，或者说不是它的特色。

这套逻辑看似非常简单，但要硬套到企业项目开发流程中可能会非常复杂，水土不服。
PS: 虽然 git 新增了一个 request-pull 子命令，但可能很鸡肋，不可能脱离 Web 来参与讨论、评审代码。

GitLab Flow

GitLab Flow

分不同环境：

  • master 开发分支，管理方式就是 GitHub Flow，不过就是 Pull Request 改名为了 Merge Request
  • pre-production 预发布分支，只能从 master 合并
  • production 发布分支，只能从 pre-production 合并

如果需要发布：

  1. 从 master 拉分支，比如：20-04-stable，创建语义化版本号。
  2. 如果后期有严重 BUG，可以从 master cherry-pick 过来。

特点：比 GitHub Flow 更进一步，对项目的发布和部署提出了建议，并支持多个环境。

主要是其中有一点特别好的就是: Upstream First, 上游优先。所有环境以及维护分支的提交必须来自 master 分支。

我的思考

当然，还是那句老话：适合自己的就是最好的。
项目分支管理流程要和项目自身的特点，以及团队成员的技术水平相匹配。

Git Flow 的整套流程挺完备的，符合一般开发的习惯，只是对其作出规范而已。
GitHub Flow 也好，GitLab Flow 也好，都可以看做是 Git Flow 的补充。

GitHub Flow 和 GitLab Flow 都假定 master 分支是可发布的，而 Git Flow 从 master 拆分出了一个 develop 作为缓冲，我认为这个设计比较合理。

Git Flow 有几个需要注意的问题：

  1. 合并的时候保留之前的合并记录，谨慎快进 (--no-ff)
  2. hotfix, release 分支推送到 master 发布之后，切记还要同步推送到 develop 分支
  3. 必须坚持 master, develop 上不随意推送（还是得靠 Pull Request 机制）
  4. 如果有不属于当前发布周期需要的开发，不要合并到 develop
  5. 临时分支必须快用快销，不要长时间保留，且合并之后理解删除

我设想中的开发流程

1，基本参照 Git Flow (借助工具)

上游优先原则：master 分支作为所有可发布环境的上游

2，自动化测试：

  • develop, release, master: 只要有变更就触发一次自动化测试
  • 此外, master 应该保持一定频率的定时自动化测试

3，老版本需要维护就在 tag 上拉分支。

现实场景中，可能要为 abc 环境上的某个老版本 v1.0.0 修复 BUG、加功能，或对已有功能进行一些调整。

git branch maintain/abc v1.0.0 # 一旦分叉，就需要长期保留该分支
# maintain/abc/develop
# maintain/abc/feature/xxx
# maintain/abc/hotfix/xxx
# maintain/abc/release/xxx
# 视情况，可以简化处理，不用上面这些分支

PS: 最后需要重新发布的时候可以对版本号加上附加的标识 v1.0.0.1.abc

5，如果是 OEM，针对客户有关的信息、资源应该留给打包系统来统一处理

此外：

  1. 项目应有明确的 roadmap
  2. 代码评审
  3. 数据库设计统一管理
  4. 项目文档，需求库，用例库
  5. 版本号基本上遵循语义化版本规范
  6. 提交记录遵循 git commit message 规范 (借助工具)
  7. CI/CD + 自动化测试

参考资料与拓展阅读

发布于码厩技术博客的所有文章，除注明转载外，均为作者原创，欢迎转载，但必须注明出处。
尊重他人劳动，共创开源社区！转载请注明以下信息：
转载来源： 码厩技术博客 []
原文标题：Git 分支管理策略（工作流）
原文地址：
知识共享许可协议
如果你有魔法，你可以看到一个评论框～