3. 代码管理-Git-进阶

文章目录

前言
[一、Git 工作流到底在解决什么问题](#一、Git 工作流到底在解决什么问题)
二、中心化工作流：所有人往同一条主干上推
三、功能分支工作流：一个需求，一条命
四、GitFlow：重流程的版本发布模型
[五、Forking 工作流：开源世界的标准答案](#五、Forking 工作流：开源世界的标准答案)
[六、GitHub Flow：持续交付时代的轻量答案](#六、GitHub Flow：持续交付时代的轻量答案)
七、五种方式横向对比：一张表选对你的团队
八、选完工作流，还得落地三个细节
写在最后

前言

几个同事共用一张桌子写同一份文档：有人各写各的、最后拼在一起；有人坚持轮流写，谁也不许插队；还有人干脆每人抄一份，交给主编挑。Git 的团队协作方式，说穿了就是这几种"共写姿势"的选择。

同样是 Git，有的团队一天合并十几次代码、上午写的下午就上线；有的团队合一次分支要解决半天冲突，还得拉个会决定"谁的分支先合"。问题往往不在 Git 本身，而在于一开始就选错了协作方式。 同一套工具，为什么协作体验能差这么多？分支到底该开几条、能活多久？流程重一点，究竟是规范还是负担？

接下来就让我们逐个看一看：Git 最常见的五种团队协作方式，各自解决什么问题、又适合什么样的团队。

一、Git 工作流到底在解决什么问题

所谓"Git 工作流"，就是一套约定------谁在什么地方提交代码、分支怎么开、代码怎么合、谁能把关。它不改变 Git 的命令，只改变团队使用这些命令的秩序。

所有工作流，本质上都是在平衡三对矛盾：

矛盾	一端的诉求	另一端的诉求
并行 vs 稳定	每个人都能同时开发不同需求	主干代码随时可用、不出乱子
节奏 vs 寿命	发布要快，一天能发多次	分支要稳，改动充分验证再合
管控 vs 效率	坏代码不许进主干，权限要收紧	流程别太重，别让开发者走审批马拉松

没有最好的工作流，只有和团队规模、交付模式最匹配的那一个。 理解了这三对矛盾，下面的五种方式就不再是需要死记的规则，而是五组不同的取舍答案。

二、中心化工作流：所有人往同一条主干上推

最古老也最简单的模式。一个中央仓库，只有一条长期分支------早期叫 master，现在出于包容性用语的考虑，越来越多团队改用 main（GitHub 自 2020 年 10 月起对新仓库默认使用 main）。每个人 clone 一份到本地，直接在本地 main 上提交，然后往中央仓库推。

冲突怎么处理？靠"推不上去就重来"：

bash 复制代码

git clone git@example.com:team/project.git

# 本地改完直接提交
git commit -am "fix: 修正订单金额计算"

# 推向中央仓库
git push origin main
# 如果被拒绝，说明有人比你先推了，先同步再推
git pull --rebase origin main
git push origin main

pull --rebase 会把你的提交"垫"在别人最新提交之后，保持一条直线，而不是产生一个多余的合并节点。

它的优点是心智负担几乎为零 ，不用理解分支模型，命令也就那几条。代价是所有人挤在一条线上：谁推了一个跑不起来的版本，全组立刻被卡住；而且没有评审环节，代码质量完全靠自觉。

Warning

中心化工作流的适用上限，就是团队人数和提交频率的上限。1~3 人的小团队、个人项目、内部小工具用它绰绰有余；人一多、提交一频繁，冲突会明显增多。

三、功能分支工作流：一个需求，一条命

从"中心化"往前一步：主干上不再直接提交，每个需求都开一条独立分支，开发完再合并回主干。

这一步带来了两个关键机制：

1. 代码评审关卡（Pull Request / Merge Request） ：分支合并回主干前，必须先发起一个 PR，由同事审阅、讨论、通过后才能合。评审发生在合并之前，而不是代码进了主干再补救。
1. 分支要短命 ：这条最容易被忽视，也最要命。分支活得越久，离主干越远，合并时的冲突面就越大。 一条活了两周的分支，合并时往往要花半天处理冲突，甚至改到面目全非。

bash 复制代码

# 从主干拉出功能分支
git checkout -b feature/user-login main

# 开发并提交（可以提交很多次）
git commit -m "feat: 实现登录接口"
git commit -m "test: 补充登录的单元测试"

# 推到远端，到平台上发起 PR
git push -u origin feature/user-login

功能分支工作流的核心价值，是把"隔离"和"评审"同时做到位：每个人在独立环境里开发，互不干扰；合进主干前有人把关，主干质量有了守门人。

Tip

它适合大多数中小规模的后端业务团队------既要有评审，又不想背太重的发布流程。国内很多公司的"分支 + 合并请求 + 定期发版"就是它的变体。

四、GitFlow：重流程的版本发布模型

如果说功能分支工作流是"够用就好"，那 GitFlow 就是"仪式感拉满"。它由 Vincent Driessen 在 2010 年 1 月提出，用五类分工明确的分支，把"开发---发布---救火"三条线彻底拆开。

五类分支各司其职：

分支	从哪来	到哪去	职责
`main` （master）	初始	---	只存放已发布的、随时可打包的版本
`develop`	main	---	日常集成的"开发主干"
`feature/*`	develop	develop	单个功能，合回后即删除
`release/*`	develop	main + develop	冻结功能、只修 bug、做验收，发布前的缓冲区
`hotfix/*`	main	main + develop	线上紧急修复，修完同时合回主干和开发线

它解决的是一个很具体的问题：当一个产品需要同时维护多个已发布版本时，怎么让"新功能开发""下个版本发布"和"线上紧急修复"互不干扰。 比如一款桌面软件要同时维护 2.0、2.1 两个版本，main 上的 2.1 要紧急修 bug，同时 develop 上的 2.2 新功能又在开发------GitFlow 的分支结构天然支持这种并行。

Note

这里有个常被误读的事实值得说清楚：2020 年 3 月 5 日，Driessen 在他的原文顶部加了一段 "Note of Reflection"，表示如果团队做的是持续交付，建议改用更简单的工作流（他明确提到 GitHub Flow），不要把 git-flow 硬套到所有团队上；但如果做的是需要长期维护多个已发布版本的软件，git-flow 依然合适。他反对的从来不是 GitFlow 本身，而是把它当成万能模板。
Tip

适合： 需要同时维护多个已发布版本的产品------桌面客户端、SDK、需要打包交付的软件。

不适合： Web 应用、一天想发多次的团队。release 分支和 develop 这两道中间环节，会明显拖慢交付节奏。

五、Forking 工作流：开源世界的标准答案

前面三种都建立在一个前提上：大家共用同一个远程仓库。Forking 工作流把这个前提也掀了------开发者之间没有共享仓库。

每个人先把原仓库 fork 一份到自己的账号名下（相当于在服务端复制出一个你完全掌控的副本），改完推到自己那份 fork，再向原仓库发起 PR，由原仓库的维护者决定要不要合。

bash 复制代码

# 1. 在平台上 fork 原仓库，得到一个属于自己账号的副本
# 2. clone 自己的 fork
git clone git@github.com:me/project.git

# 3. 关联原仓库，方便同步最新代码
git remote add upstream git@github.com:org/project.git

# 4. 开分支开发，推到自己的 fork
git checkout -b fix/readme-typo
git commit -m "docs: 修正 README 拼写"
git push -u origin fix/readme-typo

# 5. 到平台上向原仓库发起 PR

它有三个鲜明特点：

权限天然隔离：贡献者没有原仓库的写权限，改得再离谱也污染不了主干；
评审权集中：代码能不能进正仓库，完全由维护者把握；
主动权分层：贡献者只提议，维护者才拍板。

Tip

适合： 开源项目、外部贡献者众多、需要对写入权限严格管控的场景。你在 GitHub 上给任何开源项目提 PR，走的都是这套流程。

六、GitHub Flow：持续交付时代的轻量答案

GitHub Flow 由 Scott Chacon 和 GitHub 团队在 2011 年提出，它的核心原则只有一句话：main 永远处于可部署状态。

分支类型被砍到只剩两种：main 和短命的功能分支。整个流程六步：

bash 复制代码

git checkout -b feature/cart-discount main
git commit -m "feat: 支持购物车满减"
git push -u origin feature/cart-discount
# 到平台开 PR → CI 全绿 → 评审通过 → 合并 main → 自动部署上线

它和功能分支工作流最大的区别，是把"合并"和"发布"绑在了一起 ：合进 main 就意味着（或很快意味着）要上生产，而不是攒到某个 release 再统一发。正因为如此，它对主干质量、自动化测试和 CI/CD 的要求，比前面几种都高。 没有一套靠谱的自动化，main 随时可部署就是一句空话。

还有一个和它血缘很近的实践叫主干开发（Trunk Based Development） ：所有人直接往主干合，长期存在的只有主干一条线，没写完的功能用"特性开关"（feature flag）在代码里藏起来，而不是靠长分支隔离。它和 GitHub Flow 是近亲，区别在于分支寿命被进一步压缩到几乎为零。对能持续交付的团队来说，GitHub Flow 和主干开发是当前最主流的选择。

七、五种方式横向对比：一张表选对你的团队

把五种工作流放在一起，差异一目了然：

维度	中心化	功能分支	GitFlow	Forking	GitHub Flow
远程仓库	单一共享	单一共享	单一共享	每人一份 fork	单一共享
分支类型	仅 main	main + feature	main/develop/feature/release/hotfix	各 fork 内自管	main + feature
代码评审	无	PR（推荐）	PR	PR，维护者把关	PR（强制）
发布模式	随时推	攒批合并	走 release 分支发版	由维护者决定	合并即发布
主干要求	低	中	中	由维护者把控	极高，随时可部署
适合团队	1~3 人	中小团队	多版本产品	开源项目	持续交付团队
典型场景	个人项目、小工具	内部业务系统	客户端/SDK/维护旧版本	GitHub 开源项目	Web/SaaS

如果还是拿不准，可以顺着这张决策图往下走：

Tip

选型不是非黑即白，同一家公司完全可以混用：核心的公共库、需要长期维护版本的组件走 GitFlow 保稳定，业务服务走 GitHub Flow 拼速度。工作流服务于交付目标，而不是反过来。

八、选完工作流，还得落地三个细节

工作流定了只是开始，下面三件事决定它能不能真正跑起来。

1. 提交信息规范（Conventional Commits）

统一前缀，让 commit 历史自己会说话：

前缀	含义	举例
`feat`	新增功能	`feat: 支持微信登录`
`fix`	修复缺陷	`fix: 修复金额为负的问题`
`docs`	文档变更	`docs: 补充接口说明`
`refactor`	重构（不改行为）	`refactor: 提取订单校验逻辑`
`test`	测试相关	`test: 补充退款用例`
`chore`	构建/工具等杂项	`chore: 升级依赖版本`

规整的提交信息不只是好看------它能自动生成变更日志、自动判断该升主版本、小版本还是补丁版本（feat 升 minor、fix 升 patch、破坏性变更升 major），也让出问题时回溯改动省事一大截。

2. 分支保护与代码评审

把主干保护起来：禁止直接 push 主干、必须走 PR、必须有人审核通过、CI 必须全绿才能合并。同时记住一条实践经验------评审要快、PR 要小。一个几百行的 PR 没人愿意认真看，反而更容易漏掉 bug；小步提交、快速评审，才是评审真正有效的前提。

3. 合并策略三选一

分支合回主干时，用哪种方式合，会永久影响历史长什么样：

策略	合并结果	主干历史	适用场景
Merge commit	保留分支上所有提交 + 一个合并节点	完整，但节点多、偏杂乱	想保留完整上下文，GitFlow 的 release 合并
Squash merge	分支上所有提交压缩成一个	线性、干净	功能分支、GitHub Flow 最常用
Rebase merge	分支提交逐个"垫"到主干最新提交之后	线性，且保留每个原子提交	提交质量高、追求线性历史

主干历史越干净，日后定位问题越省事 ------无论是用 git log 翻改动，还是用 git bisect 二分查找"到底是哪次提交引入了 bug"，线性、清晰的提交历史都能让排查效率成倍提升。

写在最后

Git 的团队协作方式没有绝对的标准答案，它本质上是团队规模和交付节奏的函数：人少、发得慢，就轻装上阵；人多、发得快，就得上短分支、强 CI、自动部署。常见的演进路径大致是：

1~3 人：中心化工作流起步，人一多立刻切功能分支；
中小团队：功能分支 + 提交规范 + 强制评审；
追求持续交付：GitHub Flow 或主干开发；
需要同时维护多个版本：GitFlow 依然是正解。

每种方式都只是当前阶段的最优解，团队长大了就该换。最后不妨问自己一句：你们团队现在用的这套协作方式，是主动选出来的，还是"默认就这么干"、从没人认真评估过？很多协作痛苦的根源，可能只是从来没有人认真选过一次。

本文的引用仅限自我学习如有侵权，请联系作者删除。

参考知识

为什么有的团队天天解决冲突，有的却敢一天上线十次？------Git 五种团队协作方式到底该怎么选？