合适的分支管理策略,便团队代码更加有序地演进,尽可能降低多分支带来的复杂度,避免由于分支混乱引发的各种“车祸”

Github-Flow

1

1.拉出一个新分支

2.在新分支上进行修改,commit和push

3.发起Pull Request ,申请将你提交的分支合并到原来的分支

4.Code Review过程中,依然可以继续推送新的代码到你的开发分支上,新的提交在推送后会出现在未完成合并的 Pull Request 页面中

5.合并和发布。Review 通过后,代码管理员将该分支合并到原来的主分支上

Gitlab 叫法从 Pull Request 变成了 Merge Request

优点

  1. 简单。只有主分支和开发分支。Git-Flow 要引入一堆辅助分支
  2. 推动 Code Review 。Pull Request 使 Code Review 成为了日常开发的必经流程
  3. 确保可编译。Pull Request 触发持续集成测试,通过测试的才允许并入主分支。杜绝代码编译不过的情况

不足

  • 解决冲突困难

一旦冲突,Merge Request 没法被直接合并

再从目标分支拉出一个分支→合并这个分支→解决完冲突→推上远程仓库再次发起 Merge Request

过程一下子复杂了起来

1

  • Code Review 容易流于形式

如果没有充分的讨论代码的细节,仍然无法保证代码的质量

在线 Code Review 并不如面对面讨论高效

双方没有 keep moving 的意识,大量 Merge Request 被积压,不断包含新的 commit 进来,使 Merge Request 更加难以合并

  • 持续集成测试无法保证子模块可编译

持续集成可以作为 Merge Request 的准入条件,但仅仅只是主工程的“福利”

使 Merge Request 的持续集成功能显得鸡肋了


综上所述,Github-Flow 更适用于只以 master 分支为主分支,更注重迅速发布的简单项目

适合 Github 上的集市型开源项目,不适用于大教堂型的企业级项目

Github 的 Scott Chancon 大神所说:

For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use. For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.

Git-Flow

1

比github-flow 有更多分支

  • master:可以提供给用户使用的正式版本
  • develop:用来生成代码的隔夜版本(nightly)
  • feature:用于开发某个功能
  • hotfix:用于修复线上代码的 bug
  • release:用于正式发布版本前的测试分支

分支管理策略完整而实用,通用开发流程标准

问题

  • 多产品线

master 维护基础板,shanghai(上海) 、beijing(北京) 等分支产出真正产品分支

每条产品线各自一套 Git-Flow 分支体系,用前缀区分产品线。例如 上海 develop 分支就叫 shanghai-dev

子模块既可能和主工程一样多个产品分支,也可能是一个通用模块

通用模块,只需要维护一套 Git-Flow 分支体系。例如 common 子模块 只有标准的 master、dev 等分支

多产品分支的主工程和子模块,改动了某个分支的代码,就要非常慎重的考虑这部分改动是否通用,是否需要并入其他产品线的分支。Git-Flow 并没有探讨多个产品线并存情况下的代码合并方案

通用的子模块,拉 release 分支时存在锁的问题

比如,上海 产品线即将发版,common 子模块拉出 release 分支,其他产品线依然可以继续为 common 子模块的 develop 分支提交 feature

但还没等 上海 产品线完成发版,北京 产品线也准备发版了,release 已被 上海 拉出来,而这个 release 分支却没有 北京 产品线要发版需要的 feature 。这就阻碍了 北京 产品线的发版

妥协与期望

  • 产品线取消 develop 分支。每条产品线取消 develop 分支,并放开产品线的主分支的提交权限

大幅减少合并冲突,避免发版受阻,稳定性领先可通过 feature 分支保证

代码足够完善,产品线的开发成本会越来越低,稳定性也会越来越强

  • cherry-pick 同步多条产品线的代码改动

通用的改动,可以用 cherry-pick 同步到其他分支上

cherry-pick commitId master,shanghai,beijing
  • 通用的子模块发版时,始终拉出产品 release 分支

上海 产品线发版,common 模块拉出 上海-release

拉出分支后,与 上海 分支有关的临时改动可以在 上海-release 中进行;同时 common 模块依然可以给其他产品线提交新 feature 。此时 北京 产品线发版,可以拉出 北京-release 分支

之后,如果 上海 产品线修改了一个通用的 bug,同样可以 cherry-pick 到其他分支


用分支实现产品线的差异化,使一个仓库出现多个主分支,复杂度超出通用的分支管理流程所能解决的范畴 > 产品架构问题

子模块的不稳定导致开发过程中不断需要跨产品线同步代码,给产品线的开发造成负担