5.1 四种工作流对比勘查

5.1 四种工作流对比勘查

本节摘要：工作流是团队在引用拓扑上的组织设计。集中式最简单，功能分支是现代主流，Gitflow 为多版本并行而生，Forking 用仓库级分叉支撑开源协作。本节逐一勘查其分支布局与协作动作，并给出选型判据。

学习目标

1. 能描述每种工作流的典型分支结构与一次变更的完整路径
2. 能说出每种工作流不适用的信号
3. 能用三个判据（写权限、发布节奏、团队规模）完成选型
4. 能解释"短命分支"与"长命分支"对历史可读性的影响

一、集中式工作流：一条主干走到底

所有人对同一个仓库的主干拥有写权限，直接在 main 上提交推送——形态上最接近 SVN 时代的习惯。变更路径极短：commit、push、完事。

它的失效信号也最明显：人数超过三四人，推送互相被拒（第 4 章的非快进拒绝）成为日常；谁推了坏提交，所有人立刻遭殃；没有评审环节，代码质量全靠自觉。适合的形态：两三人的内部工具、原型验证、个人项目的多人备份。用它的前提是回滚成本足够低——一旦破环需要翻找"谁在什么时候推了什么"，集中式的薄弱审计立刻暴露。

二、功能分支工作流：一事一分支

现代团队的事实标准。每个变更（一个功能、一个修复、一次重构）开一条短命分支，完成后经合并请求（GitHub 叫 Pull Request，GitLab 叫 Merge Request，对象层面一回事）评审合入受保护的主干。一次变更的完整路径：

git switch -c feature/export-pdf origin/main   # 从主干最新镜像开分支
# ...开发 提交 若主干前进了...
git fetch origin && git rebase origin/main      # 变基跟上（第2章复印术）
git push -u origin feature/export-pdf          # 推上平台开评审
# 平台上：评审讨论 补提交 squash合并或普通合并
git switch main && git pull                    # 拿到合并结果
git branch -d feature/export-pdf               # 清理短命分支
​

它的两个关键纪律都来自前几章的机制：分支短命（存活以天计）——活得越久，与主干分叉越深，rebase 冲突的痛苦按天数复利；合并前先同步主干——把冲突解决在功能分支上，而不是留到合并现场。主干保护（禁止直推、必须评审）由平台层强制执行，是这套流程的制度护栏。

功能分支的一个变奏是主干开发加特性开关：分支只活几个小时甚至分钟级，未完成的功能用运行时开关藏起来。超大规模团队（持续交付、每日数十次发布）偏好这种形态，代价是开关管理的复杂度。中小团队不必跟风，普通功能分支已够用。

三、Gitflow：重型装配线

为"多版本并行维护"的软件设计——桌面软件、嵌入式、需要同时支持 1.x 与 2.x 的服务端产品。五类分支各司其职：

• main：只放发布代码，每次合并打标签（呼应 4.3 发布流程）。
• develop：日常集成的洪流，功能在此汇合。
• feature/：从 develop 分出，合回 develop。
• release/：从 develop 分出做发布前打磨（只修 bug 不加功能），合回 develop 与 main 两头。
• hotfix/：从 main 分出的紧急修复，同样两头合回。

它的双主线双合流结构，本质是用引用拓扑为"发布冻结"与"日常开发"建立隔离带。但注意适用边界：Web 服务、持续交付、只有一个生产版本的产品，Gitflow 是负资产——develop 中转徒增合并次数，release 分支的"冻结"与每周多次部署的节奏直接冲突。业界从 Gitflow 退回简化版（甚至只留 main 加短命分支）的案例很多。判断标准很简单：你的产品是否需要在生产环境同时跑多个大版本？不需要，就别上 Gitflow。

四、Forking 工作流：仓库级分叉

开源协作的标准形态。贡献者没有官方仓库的写权限，各自完整 Fork 一份（平台层的仓库复制），推送到自己的 Fork，再向官方发起拉取请求。本地配双远端（第 4 章 4.1 的 remote add upstream）：

git remote add upstream <官方仓库地址>
git fetch upstream
git rebase upstream/main     # 始终基于官方最新
git push origin feature-x    # 推到自己的Fork 再向官方发拉取请求
​

维护者在自己仓库里评审、合并或 squash。隔离性是最大优点：官方仓库的分支列表不会被外部贡献者污染，权限模型极简（只有维护者可写）；贡献者之间互不干扰，质量参差的提交由维护者把关。代价是流程最长、同步成本最高——Fork 与官方的持续偏移要求贡献者养成"开工先对齐 upstream"的习惯。

五、选型判据与对比结案

三个问题定生死：谁有写权限（全员可写 → 不必 Forking；外部贡献 → 必须 Forking）；发布节奏（持续交付 → 功能分支或主干开发；多版本并行 → Gitflow）；团队规模与信任（≤3 人高信任 → 集中式够用；再往上 → 功能分支加保护主干）。

💡 关键直觉：四种工作流不是"先进程度"的排序，而是四种组织结构在 Git 引用模型上的投影。选型错了，问题不会表现为"命令报错"，而是表现为"流程越来越别扭"——推送被拒频率、冲突频率、发布前手工步骤数，这三个指标升高，就是该换工作流的信号。

选型判据速查图

本节要点回顾

• 集中式：写权限开放、零流程，仅适合极小团队。
• 功能分支：短命分支加保护主干加评审，现代默认解。
• Gitflow：为多版本并行设计，持续交付场景是负资产。
• Forking：仓库级分叉，权限隔离成就开源协作。
• 选型三问：写权限、发布节奏、团队规模。

选好形态后，下一步是把它写成团队人人可执行的规范——5.2 的主题。