Git 工作流的演变：从集中到分布再到？

在执行 git push 之前，先确认目标分支和当前提交范围。

Git 本身变化不大，变化更快的是团队围绕它建立的协作方式。很多人现在说“用 Git”，实际指的不只是版本控制，还包括代码评审、分支策略、自动测试、权限管理和发布节奏。工具还是那个工具，工作流已经换了几轮。

第一阶段：集中式管理，规则清楚但动作偏重

Git 之前，很多团队使用集中式版本控制。代码仓库只有一个中心，开发者先检出副本，修改后再提交回去。这个模式的优点很直接：主线清楚，权限边界明确，提交时机也容易统一管理。

问题也很直接。分支成本高，合并负担重，很多人会减少分支操作，最后把本该拆开的改动堆在一起。协作人数一多，冲突往往不只是技术问题，更是节奏问题：有人等提交，有人等锁释放，整体效率很容易下降。

这个阶段的核心目标不是“协作自由”，而是“不要混乱”。对于规模不大的团队，这种模式并不差，只是弹性有限。

第二阶段：分布式协作，Git 把本地能力做满了

Git 出现后，最明显的变化是：每个人手里都是完整仓库。本地提交、本地分支、本地回滚都很轻量。很多操作不需要先连接中心服务器，也不需要每一步都经过他人批准。

这带来了两个结果。

第一，试错成本变低。你可以先在本地开分支，把想法做完，再决定要不要公开。第二，协作开始异步化。不必所有人同时在线、同时操作同一条主线，也能持续推进工作。

这也是 Git 广泛流行的重要原因。它不只是命令更强，而是默认鼓励“先局部完成，再合并进来”。

但问题也从这里开始。Git 让分支变便宜，很多团队于是开了很多分支；分支一多，命名、同步、清理、回滚都会变成额外负担。工具给了自由，自由不自动等于高效。

第三阶段：平台接管流程，Git 退到内核位置

现在很多人感受到的“Git 工作流”，其实已经不是纯 Git，而是 Git 加平台。常见平台会把 Pull Request 或 Merge Request、评审、CI、保护分支等能力整合在一起。CI 可以理解为“每次提交后自动执行检查和测试”。

这一步很关键，因为协作的焦点从“怎么提交代码”变成了“什么时候允许进入主线”。

以前，工作流主要靠约定；现在，越来越多规则直接写进平台里：

没过测试，不能合并
没有人评审，不能合并
主分支禁止直接推送
提交信息不符合格式，直接拦下

这样做的好处是稳定。尤其在多人协作时，口头规则容易失效，机器规则通常更一致。很多团队关心“最新测试”和“到底跑了什么”，本质上都指向同一个问题：流程有没有把检查前置，而不是靠人事后补救。

但平台化也有代价。一个常见错觉是：流程越完整，质量越高。这一点并未在本文中验证。流程只能保证“检查过”，不能保证“设计正确”。如果每次改一个文案都要走完整审批和流水线，团队很容易把时间花在等待上。

现在的拐点：从分支驱动，走向主线驱动

这两年更明显的变化，不是 Git 命令变了，而是很多团队重新收缩分支策略。以前流行长期存在的功能分支，现在越来越多人转向短分支，甚至直接强调 trunk-based development，也就是“围绕主线持续小步合并”。

也就是说，不要把一个功能长期放在分支里，而是尽量拆小、尽快进入主线。

原因并不复杂：

分支活得越久，偏离主线越远，合并成本越高。
自动测试比以前更重要，能替代一部分“晚一点再合”的安全感。
发布方式变了。很多系统已经不是“攒一大包一起发”，而是更频繁、更小粒度地发。

这时，Git 的角色开始更像“底层协议”：真正决定协作体验的，往往是测试是否稳定、评审是否及时、回滚是否简单，而不是是否熟悉大量 rebase 命令。

再往后会到哪？

更可能出现的情况不是“再发明一个 Git”，而是 Git 继续留在底层，工作流被更强的自动化和上下文工具包裹。

已经能看到几个方向。

1. 提交不再只是代码变更，还会带着更多上下文

比如变更原因、影响范围、关联测试、风险提示。不是完全靠人额外写长文档，而是由平台和工具自动补齐一部分。这样评审看到的就不只是一组 diff，而是一组更完整的决策线索。

2. 评审会更像筛选异常，而不是逐行盯代码

如果格式检查、基础测试、简单静态检查都能自动完成，人真正需要看的，是边界、兼容性，以及是否引入了不必要的复杂度。评审会从“看所有东西”转向“看值得看的东西”。

3. 协作单位会继续变小

这不是为了追求某种“敏捷感”，而是因为小改动更容易验证、更容易回滚，也更适合机器参与检查。工作流最终会逼着人把问题拆小，这通常比再增加一层流程更有效。

普通使用者现在该关心什么

如果只是个人项目，或者两三个人协作，不必引入很重的流程。更实用的做法通常只有几条：

主分支尽量保持可用
分支生命周期尽量短
合并前至少有一轮自动检查
提交说明写清“改了什么、为什么改”
能回滚的改动，不要一次塞太多

这些规则不新，但它们比“采用哪种著名工作流”更影响日常体验。Git Flow、GitHub Flow、trunk-based 这些名字有参考价值，但不能替代具体约束。