想象一下两家餐厅后厨。一家是五星级酒店的宴会后厨：分工极细，有专门的备菜台、炒菜线、出品区验收员，还有一口应急灶台随时处理顾客投诉；另一家是街角的快捷简餐店：只设一个出餐口，厨师随到随炒，炒好直接端上桌。两家店生意都很火，但管理后厨的方式完全不同。 Git 版本管理里的“分支策略”，就是后厨的管理制度。GitFlow 是那家宴会后厨——分支多、规矩严、流程完整；GitHub Flow 是那家简餐店——分支少、节奏快、响应迅速。选错了，就像把快餐店变成国宴后厨，菜还没上齐客人已经饿走了；或者反过来，用快餐店的规矩办国宴，必然手忙脚乱。 这篇文章带你从“后厨”的角度看懂两种主流分支策略，学会在什么场景用哪一套，让你的团队协作像一家运转顺滑的餐厅。

岗位关联

对 AI 从业者：AI 项目通常团队小、迭代快，频繁跑实验、定期上线模型，看懂分支策略能帮你搭建高效的协作流程，避免合并冲突和发布事故。

目录
  1. 可视化演示
  2. 分支模型对比：两种后厨的格局
  3. 核心分支解析：三位厨师的岗位
  4. 发布流程对比：上菜的节奏
  5. 紧急修复策略：客人催单时
  6. 主干开发理念：大道至简的快炒
  7. 团队规模适配：几人吃饭决定菜单
  8. 持续部署配合：全自动传菜系统
  9. 选型决策框架：怎样点出这桌菜
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

\u5c55\u793a\u5192\u6ce1\u6392\u5e8f\u7684\u9010\u6b65\u6267\u884c\u8fc7\u7a0b\uff0c\u901a\u8fc7\u76f8\u90bb\u5143\u7d20\u6bd4\u8f83\u548c\u4ea4\u6362\u5c06\u6570\u7ec4\u4ece\u5c0f\u5230\u5927\u6392\u5217\uff0c\u6bcf\u8f6e\u5c06\u6700\u5927\u5143\u7d20\u5192\u6ce1\u81f3\u672b\u5c3e\u3002

本节配有交互动效（进入视口后自动加载，约 3KB）。

\u5192\u6ce1\u6392\u5e8f \u9752\u8272\u67f1\u8868\u793a\u5df2\u6392\u5e8f\u5143\u7d20 \u6a59\u8272\u4e3a\u5f53\u524d\u6bd4\u8f83\u5143\u7d20 O(n\u00b2) \u65f6\u95f4\u590d\u6742\u5ea6 \u9010\u6b65\u6bd4\u8f83\u76f8\u90bb\u5143\u7d20\u5e76\u4ea4\u6362

分支模型对比：两种后厨的格局

宴会后厨里，食材要经过收货台、粗加工间、配菜区、炒灶、出品检验台，动线又长又复杂，但每一站都有明确责任人。简餐店却只有一个出餐口、两个灶台，厨师转身就能把菜端给客人，整个动线短得惊人。GitFlow 和 GitHub Flow 的差别，正是这两种后厨格局的差别。

GitFlow 由 Vincent Driessen 在 2010 年提出，定义了 master、develop、feature、release、hotfix 五种分支，其中 master 和 develop 是常驻分支。GitHub Flow 是 GitHub 公司在 2011 年简化出的模型，常驻分支只有 main 一条，其余全是临时拉出的 feature 分支。分支种类越多，团队需要维护的“动线”就越多，每次合并都要考虑该往哪条线上合。

分支多了，两两之间就要频繁“碰头”，合并成本会随分支数量增长：

用后厨的话说：宴会后厨有五个功能区，传菜、清洗都要绕过很多动线；简餐店只有一个出餐口，一转身菜就端上去了。动线越长，协作成本越高。

Cmerge≈n(n−1)2×Tlife\displaystyle C_{\text{merge}} \approx \frac{n(n-1)}{2} \times T_{\text{life}}
这个公式告诉你：分支种类越多、存活时间越长，团队为合并付出的代价就越大。
  1. $n$ 的含义常驻分支的种类数。GitFlow 有 master、develop 两类常驻分支；GitHub Flow 只有 main 一类。
    n=常驻分支种类数n = \text{常驻分支种类数}
  2. 组合数 $\frac{n(n-1)}{2}$n 类分支之间两两配对的组合数，代表需要维护的合并通路数量。n=2 时只有 1 对，n=5 时就有 10 对。
    (n2)=n(n−1)2\binom{n}{2} = \frac{n(n-1)}{2}
  3. 存活时间 $T_{\text{life}}$一条分支从拉出到合并回主干、彻底删除的平均天数。GitFlow 的 feature 分支常存活数周，GitHub Flow 要求一两天内合并。
  4. 乘积 $C_{\text{merge}}$合并总成本。分支越多、活越久，冲突概率和合并工时越大，这就是为什么 GitFlow 必须配严格的流程纪律来管控成本。

核心分支解析：三位厨师的岗位

在宴会后厨，出餐口是唯一权威，只有通过最终检验的菜才能从这里出去；掌勺大厨负责把每道新菜试味、汇总；每位帮厨则有自己的操作台，在操作台上切配自己的食材。GitFlow 的分支体系就像这三个岗位。

master 分支永远只放可以发布的代码，是“出餐口”；develop 是汇集所有新功能的“试菜大厨”；feature 分支从 develop 拉出，每位开发者做完自己的功能后，通过 Pull Request 合回 develop。GitHub Flow 则砍掉了试菜大厨这个岗位，feature 直接从 main 拉出，做完直接合回 main。

一次变更从“开始做”到“真正上线”要经过多少道关卡？GitFlow 要走完 feature→develop→release→master 三段流程，GitHub Flow 只有 feature→main 一段。每一道关卡都可能打回重做：

宴会后厨做一道菜要经过“试菜 → 摆盘 → 检查 → 上菜”四道工序，每个环节都可能打回重做；简餐店只过“看一眼熟了没有”这一关。岗位多，分工细，但也意味着每一道菜都要排队过审。

P上线=∏i=1Lpi\displaystyle P_{\text{上线}} = \prod_{i=1}^{L} p_i
这个公式说明关卡越多，一次变更顺利走完全程的概率越低。
  1. 关卡数 $L$合并到 master 前必须通过的关卡数量。GitFlow 是 3 道，GitHub Flow 是 1 道。
    LGitFlow=3,LGitHubFlow=1L_{\text{GitFlow}} = 3, \quad L_{\text{GitHubFlow}} = 1
  2. 通过率 $p_i$第 i 道关卡的测试与评审通过率，比如 0.9，代表九成概率能过这一关。
  3. 连乘 $\prod$所有关卡通过率相乘。若每关都是 0.9，GitFlow 总通过率 $0.9^3 \approx 0.73$，GitHub Flow 是 0.9。
    0.9×0.9×0.9=0.7290.9 \times 0.9 \times 0.9 = 0.729
  4. $P_{\text{上线}}$一次变更顺利到达生产的概率。关卡越多，返工、积压、阻塞的概率就越高。

发布流程对比：上菜的节奏

宴会后厨讲究批次出菜：凉菜、热菜、汤、甜品按顺序走，凑齐一桌才一起上；简餐店则来一单炒一单，菜熟即出。分支策略里的“发布”就是对上菜节奏的管理。

GitFlow 在临近发布时从 develop 拉出 release 分支，进入“冻结期”——不再接受新功能，只修 bug、补文档、做最终验收，准备就绪后合入 master 并打上版本标签（tag）。GitHub Flow 没有 release 分支，main 随时可以部署，代码合入 main 就意味着立即发布。一次发布的完整周期：

宴会后厨一次接待二十桌，需要提前一天把菜单定死；简餐店客人随到随点随上菜。如果你的产品也需要“凑齐一个版本才能端出去”，那就是 GitFlow 的节奏。

Tcycle=Tdev+Tfreeze+TQA\displaystyle T_{\text{cycle}} = T_{\text{dev}} + T_{\text{freeze}} + T_{\text{QA}}
这个公式把发布周期拆成三段时间，告诉你“等发布时间”花在了哪里。
  1. 开发时间 $T_{\text{dev}}$新功能从开发到合入 develop 的时间，两类策略差别不大。
  2. 冻结期 $T_{\text{freeze}}$release 分支创建后不再加新功能的窗口。GitFlow 通常预留几天到一周；GitHub Flow 没有这个环节，此项为 0。
    TfreezeGitHubFlow=0T_{\text{freeze}}^{\text{GitHubFlow}} = 0
  3. 测试验收 $T_{\text{QA}}$GitFlow 在 release 分支上做集中测试；GitHub Flow 把测试前置到 PR 的自动检查中，所以合并到 main 时已经通过测试。
  4. 三者之和一次发布的完整周期。GitFlow 的总周期更长，但换来的是更可控的批次质量。

紧急修复策略：客人催单时

客人说菜咸了、上错了，宴会后厨不会停下整场宴席的炒菜流水线，而是开一口应急灶台，用最短的时间单独重炒一份；简餐店更直接——厨师把锅一洗，重炒一份，前后不到三分钟。这就是两种策略处理线上紧急 bug 的方式。

GitFlow 的 hotfix 分支从 master 拉出，修完后要同时合并回 master 和 develop，确保这次修复不会在未来的版本里丢失。GitHub Flow 的 hotfix 本质上仍是 feature 分支：从 main 拉出修复分支，修完 PR 合回 main，再打一个补丁版本 tag 即可。从发现事故到修复上线，总耗时是四段之和：

处理突发事件时，后厨动线越短越好。一条修复路径上少一个岔路口，就少一分忙中出错的可能。

Thotfix=T察觉+T修复+T合并+T部署\displaystyle T_{\text{hotfix}} = T_{\text{察觉}} + T_{\text{修复}} + T_{\text{合并}} + T_{\text{部署}}
这个公式把一次紧急修复拆成四段，每一段都值得优化。
  1. 察觉时间 $T_{\text{察觉}}$监控报警或用户反馈发现事故所需时间。监控越完善，这一步越快。
  2. 修复时间 $T_{\text{修复}}$定位问题并写好修复代码的时间。hotfix 分支只修一个问题，不做无关改动，才能保证快。
  3. 合并时间 $T_{\text{合并}}$GitFlow 要把修复合并回 master 和 develop 两条分支；GitHub Flow 只需合并回 main 一条，这步天然更快。
    T合并GitFlow≈2×T合并GitHubFlowT_{\text{合并}}^{\text{GitFlow}} \approx 2 \times T_{\text{合并}}^{\text{GitHubFlow}}
  4. 部署时间 $T_{\text{部署}}$修复代码上线的时间。自动部署每快一分钟，事故影响范围就小一分钟。

主干开发理念：大道至简的快炒

有些大厨索性把备菜台也撤了，只留一个出餐口和一块大铁板，所有菜直接在铁板上现切现炒——这就是 Trunk Based Development（主干开发）的哲学：不要冗长的分支，要快。

主干开发强调所有开发者共用一条主干，分支存活时间以小时计，而不是以天、周计。功能点要拆得足够小，小到一两天内一定能做完并入主干；主干始终保持可发布状态。分支存活时间取决于功能规模与团队合并速度的比值：

快炒的秘诀是食材提前切好（小 feature）、锅不凉（主干持续更新）、炒完就上桌（合并即部署）。GitHub Flow 正是主干开发理念的轻量级实现。

Tlife=Sfeaturevteam\displaystyle T_{\text{life}} = \frac{S_{\text{feature}}}{v_{\text{team}}}
这个公式告诉你：想让分支活得短，要么把功能拆小，要么提高团队的合并频率。
  1. 功能规模 $S_{\text{feature}}$单个功能点包含的工作量。拆得越小，$T_{\text{life}}$ 越短，如果 100 行的改动两天就能合入主干。
    Sfeature=单功能工作量S_{\text{feature}} = \text{单功能工作量}
  2. 团队速度 $v_{\text{team}}$团队平均每天能合入主干的“吞吐量”，由代码评审效率和 CI 自动化程度决定。
  3. 比值功能从拉出分支到合并回主干的天数。Trunk Based 要求这个值小于 1 天，有的团队按小时计。
  4. 两种改进方向要么拆小功能点，要么增强自动化合入能力，两者都能压缩 $T_{\text{life}}$。

团队规模适配：几人吃饭决定菜单

小两口在家吃饭，自己做三菜一汤，不需要五个厨师和三个灶台；办百人婚宴，就必须把洗、切、配、炒、传的岗位分开，不然后厨会撞成一团。团队规模决定了该用多细的分支制度。

2-10 人的小团队适合 GitHub Flow：人少、沟通直接、决策链路短，流程越简单越好。几十人的大团队或跨地域协作团队适合 GitFlow：通过分支分工，把团队拆成几个“岗位”小组，每组只需和相邻岗位沟通，互不干扰。团队沟通成本随人数增长的速度惊人：

人少的餐厅靠喊，人多的餐厅靠菜牌和传菜铃。人数决定你该用多细的分支制度。

C沟通=N(N−1)2\displaystyle C_{\text{沟通}} = \frac{N(N-1)}{2}
这个公式告诉我们：人越多，靠口头沟通越不靠谱，必须靠制度——也就是分支策略——来兜底。
  1. 团队人数 $N$参与同一仓库协作的开发者数量。
  2. 两两通道数 $\frac{N(N-1)}{2}$团队内部任意两人之间可能的沟通通道。5 人团队是 10 条，20 人团队是 190 条。
    C沟通(5)=10,C沟通(20)=190C_{\text{沟通}}(5) = 10, \quad C_{\text{沟通}}(20) = 190
  3. 沟通成本的含义每多一条通道，就多一分信息失真和等待。人越多，越需要把协作规则“写下来”。
  4. 分支策略作为契约GitFlow 相当于把大团队分成“配菜组”“炒菜组”“品控组”，只用对接相邻岗位；GitHub Flow 则是所有人直接面对同一口锅，人少才转得开。

持续部署配合：全自动传菜系统

现代餐厅引入了自动传菜带：菜炒好放上去，传送带自动送到对应餐桌，厨师不用亲手端。对应到开发里，就是 CI/CD 流水线——主干每次变更都会自动触发构建、测试、部署。

GitHub Flow 天然契合持续部署：main 是被监控的“上菜带”，每次合入 main 都自动走完构建 → 测试 → 部署流程，所以每次合并都是一次发布。GitFlow 因为存在 release 冻结期，更适合需要人工审核的批次发布，通常搭配持续集成（CI）但不一定全自动部署。一段时间的部署吞吐量：

传菜带越快，后厨就越不能有积压的菜。GitHub Flow 把“上菜”变成每次提交的默认动作，而 GitFlow 的传菜带是有批次限制的。

fdeploy=KmergedTcycle\displaystyle f_{\text{deploy}} = \frac{K_{\text{merged}}}{T_{\text{cycle}}}
这个公式衡量团队平均多久能完成一次发布，是持续部署的关键指标。
  1. 有效提交数 $K_{\text{merged}}$一段时间内合并到主干且通过质量门禁的提交数量。
  2. 观测周期 $T_{\text{cycle}}$统计用的总时长，比如一个月。
  3. 比值 $f_{\text{deploy}}$平均每个单位时间能完成几次发版。GitHub Flow 的合并即部署让这个值接近每日多次。
  4. 两个优化方向提升合并通过率（把质量门禁前置到 PR 阶段），或缩短周期（去掉 release 冻结等待），都能提高部署吞吐量。

选型决策框架：怎样点出这桌菜

点菜时你要看今天几个人、预算多少、有没有忌口。选分支策略同样要先问三个“忌口”：产品是给谁用的、多久上一次新、团队熟不熟 Git。

第一个问题看产品类型：面向外部客户、需要版本化交付的软件（手机 App、企业软件）适合 GitFlow；持续运营的 Web 服务适合 GitHub Flow。第二个问题看发布频率：月更、季更的项目用 GitFlow 更从容；每天要发多次的项目必须用 GitHub Flow。第三个问题看团队经验：全员熟悉 Git 和代码评审，可以用更轻的流程；新手多、需要明确指引，就用 GitFlow 的强流程兜底。把三个维度加权打分：

没有“最好吃”的菜，只有“适合今天这桌人”的菜。GitFlow 适合版本化交付的成熟团队，GitHub Flow 适合持续交付的紧凑团队。先把三个“忌口”问清楚，再点菜单。

Score=w1⋅Frelease+w2⋅Tsize+w3⋅Eteam\displaystyle Score = w_1 \cdot F_{\text{release}} + w_2 \cdot T_{\text{size}} + w_3 \cdot E_{\text{team}}
这个公式给出系统化的选型方法：把主观判断量化为三维打分，不靠拍脑袋。
  1. 发布适配度 $F_{\text{release}}$该策略与团队发布频率的匹配程度，高频部署给 GitHub Flow 打高分，低频批次发布给 GitFlow 打高分。
  2. 团队适配度 $T_{\text{size}}$策略与团队规模的匹配程度。小团队配简单流程分高，大团队配严格流程分高。
  3. 经验适配度 $E_{\text{team}}$团队对 Git 的熟练程度。新手团队用强流程更稳妥，老手团队用轻流程不拖沓。
  4. 权重 $w$根据公司当前最痛的点分配权重。比如最缺发布速度，就把 $w_1$ 调大。
    w1+w2+w3=1w_1 + w_2 + w_3 = 1

AI 应用场景

AI 创业团队：每日部署模型实验

阶段：模型迭代与部署

解决的问题：AI 团队经常跑实验、调参、上线新模型。传统 GitFlow 流程每次上线都要等一个发布周期，实验代码容易堆积。GitHub Flow 让实验代码合并即部署，算法工程师的每个调参实验都能快速进入生产线。

具体案例：一家做推荐算法的创业公司，算法工程师在 feature 分支上调参，PR 合并后自动触发训练流水线，新模型在灰度环境验证后自动上线，整个周期从两周缩短到一天。

大型 ToB 软件：多版本并行维护

阶段：多版本发布维护

解决的问题：ToB 软件需要同时维护多个大版本，每个版本有各自的修复需求。GitFlow 的 release 分支可以冻结版本，hotfix 分支能独立修复每个线上版本，互不干扰。

具体案例：一家做 AI 客服系统的厂商同时维护 V1 和 V2 两个大版本，V1 的客户出现语音识别问题后，开发从 master 拉出 hotfix 分支修复并合并回 develop，既处理了危机，又不影响 V2 的新功能开发。

数据科学团队：实验分支管理

阶段：数据处理与特征工程

解决的问题：数据科学家要尝试不同特征工程方案，但基础训练管线要保持稳定。用分支隔离实验代码，main 分支始终保留可复现的基线特征集。

具体案例：某金融风控团队的数据科学家在独立分支上开发新的反欺诈特征，与主基线并行验证效果，实验通过后合入 main 并打 tag 记录模型版本，方便回滚对比。

Python 演示

python56 行
# -*- coding: utf-8 -*-"""branch_strategy_sim.py模拟 GitFlow 与 GitHub Flow 两种分支策略下的分支存活时间与合并成本。""" import random  class BranchSim:    """分支策略模拟器：用随机模拟对比两种策略的代价。"""     def __init__(self, dev_count=6, feature_cnt=8, seed=42):        self.dev_count = dev_count        self.feature_cnt = feature_cnt        random.seed(seed)        self.merge_cost_gitflow = 0.0        self.merge_cost_github = 0.0        self.life_total = {"gf": 0, "gh": 0}        self.life_count = {"gf": 0, "gh": 0}     def simulate_githubflow(self):        """GitHub Flow: 功能小、分支存活短、合并通路少。"""        for _ in range(self.feature_cnt):            dev_days = random.randint(1, 3)            self.merge_cost_github += dev_days * dev_days * 0.5            self.life_total["gh"] += dev_days            self.life_count["gh"] += 1     def simulate_gitflow(self):        """GitFlow: 功能大、有冻结期、合并通路多。"""        for _ in range(self.feature_cnt):            dev_days = random.randint(2, 5)            freeze_days = random.randint(1, 2)            total_days = dev_days + freeze_days            self.merge_cost_gitflow += total_days * total_days * 0.8            self.life_total["gf"] += total_days            self.life_count["gf"] += 1     def run(self):        self.simulate_gitflow()        self.simulate_githubflow()        avg_life_gf = self.life_total["gf"] / self.life_count["gf"]        avg_life_gh = self.life_total["gh"] / self.life_count["gh"]        print("=== 分支策略模拟结果 ===")        print(f"GitFlow   平均存活 {avg_life_gf:.1f} 天, 合并成本 {self.merge_cost_gitflow:.0f}")        print(f"GitHubFlow平均存活 {avg_life_gh:.1f} 天, 合并成本 {self.merge_cost_github:.0f}")        if self.merge_cost_github < self.merge_cost_gitflow:            print("建议: 小团队 / 高频发布场景, 优先考虑 GitHub Flow")        else:            print("建议: 多版本并行的复杂项目, GitFlow 更合适")        return avg_life_gf, avg_life_gh  if __name__ == "__main__":    sim = BranchSim(dev_count=6, feature_cnt=8, seed=7)    sim.run()
目的：用随机数值模拟两种分支策略下的分支存活天数和合并成本，输出选型建议。
  1. dev_days = random.randint(1, 3)GitHub Flow 的功能点小，开发天数短，对应“简餐店炒一份菜只要几分钟”。
  2. self.merge_cost_github += dev_days * dev_days * 0.5合并成本与存活时间平方成正比，存活越短合并越便宜。
  3. freeze_days = random.randint(1, 2)GitFlow 多出一段 release 冻结等待期，像宴会等菜凑齐一桌。
  4. dev_days * dev_days * 0.8GitFlow 的合并通路多一倍，成本系数更高，体现两种策略的结构差异。
  5. if self.merge_cost_github < self.merge_cost_gitflow:用模拟结果给出量化选型建议。

常见误区

误区GitFlow 定义了 master、develop、feature、release、hotfix 五种分支，分支管得细、规矩多，肯定比只有一条 main 的 GitHub Flow 更安全更正规。

正解分支多不等于严谨，而是意味着更多的合并通路和更长的发布周期。GitFlow 的严谨来自配套的流程纪律：谁可以合入 master、release 冻结期多久、hotfix 必须双路合并。如果团队执行不到位，5 条分支只会让代码更乱。就像宴会后厨的五个功能区，没有严格的动线管理，反而容易撞车。

为何常见：因为 GitFlow 的教程图看起来很完整、很“专业”，初学者容易把“复杂”误当成“成熟”。

误区GitHub Flow 只有一条 main，合并即部署，那怎么区分版本？是不是没法做版本回滚和发布记录？

正解GitHub Flow 依然用 Git 标签（tag）做版本管理。每次发布时在 main 上打一个版本号标签，例如 v1.2.0，既记录了发布时间点，也能随时回滚到任意发布版本。合并即部署说的是“发布的动作”更快，而不是“放弃版本管理”。就像简餐店虽然出菜快，一样有菜单记录每道菜的做法。

为何常见：GitFlow 的教学里特别强调 release 分支和 tag 的配合，容易让人以为 tag 是 GitFlow 专属。

误区GitFlow 的流程图里画着 hotfix 从 master 分出，所以只从 master 拉修复分支，即使线上跑的是别的版本。

正解正确做法是从“实际发布到线上”的那个分支拉 hotfix。如果线上是 V1.2 而 master 已经开发到 V2.0，从 master 拉修复会让修复带上 V2.0 的未发布代码，事故扩大化。应该从线上版本对应的 tag 或 release 分支拉 hotfix。就像顾客手里的菜是今天炒的，你要重炒的是同一锅，而不是拿明天的方案来救今天的急。

为何常见：因为教材里的示意图为了简洁只画了 master，忽略了多版本并行的真实场景。

误区主干开发的字面意思就是所有人都不拉分支，直接 commit 到 main，不需要代码评审。

正解Trunk Based 的核心是分支存活时间短，而不是禁止分支。大多数团队仍然通过 Pull Request 合入主干，只是这个 PR 分支只存活几小时到一天，且所有检查自动化。它把“代码评审”从漫长的流程变成快速的小检查，就像铁板烧大厨虽然直接在铁板上操作，但每道菜依然要过品控。

为何常见：把“主干”和“单分支”等同起来，忽略了短分支和自动化门禁的配合。

面试题

Q1. GitFlow 中哪两条是常驻分支？

单选题 · easy

  • A.master 与 develop← 正确答案
  • B.master 与 release
  • C.feature 与 develop
  • D.hotfix 与 release

答案：A。GitFlow 中只有 master 和 develop 长期存在，feature、release、hotfix 都是用完即删的临时分支。就像宴会后厨的炒灶和出餐口是常设的，备菜台和应急灶是临时搭的。

Q2. GitHub Flow 中唯一的常驻分支通常叫什么？

单选题 · easy

  • A.develop 分支
  • B.main 主干分支← 正确答案
  • C.release 分支
  • D.feature 分支

答案：B。GitHub Flow 只保留一条常驻分支 main，所有其他分支都是临时拉出的短分支。它对应简餐店唯一的出餐口，没有额外的试菜台和冻结区。

Q3. GitFlow 的 feature 分支是从哪条分支拉出的？

单选题 · mid

  • A.master 主干线
  • B.develop 开发线← 正确答案
  • C.release 发布线
  • D.hotfix 修复线

答案：B。feature 分支统一从 develop 拉出，开发完成后再合并回 develop。master 只接收 release 和 hotfix 合入，不直接接 feature。就像帮厨从掌勺大厨的备菜台领食材，不从出餐口拿。

Q4. GitFlow 中 hotfix 修复完成后需要合并回哪些分支？

单选题 · mid

  • A.仅 master 一条
  • B.仅 develop 一条
  • C.master 与 develop← 正确答案
  • D.仅 release 分支

答案：C。hotfix 要同时合回 master 和 develop，否则修复会在下一次发版时丢失。双路合并相当于应急灶台的菜既要补给出餐口，也要补进备菜清单。

Q5. 合并成本公式 C≈n(n-1)/2×T 中，n 表示什么？

单选题 · hard

  • A.分支的种类数← 正确答案
  • B.开发者的总人数
  • C.提交的总数量
  • D.发布的总次数

答案：A。n 是分支种类数，n(n-1)/2 是这些分支之间两两配对的组合数，代表需要维护的合并通路数。分支种类越多，合并通路越多，成本就越高。

Q6. GitHub Flow 更适合下面哪种产品？

单选题 · easy

  • A.每季发版的 PC 应用
  • B.每天多次部署的 Web 服务← 正确答案
  • C.需长时间测试的嵌入式软件
  • D.版本固化交付的政企软件

答案：B。GitHub Flow 的核心是合并即部署、高频迭代，天然适合每天多次发版的 Web 服务。版本化交付、长测试周期的产品更适合 GitFlow 的批次发布。

Q7. GitFlow 的临时分支包括哪些？

多选题 · mid

  • A.feature 特性分支← 正确答案
  • B.release 发布分支← 正确答案
  • C.hotfix 修复分支← 正确答案
  • D.develop 开发分支

答案：ABC。feature、release、hotfix 都是用完即删的临时分支；develop 是常驻分支，和 master 一起长期存在。这就像备菜台、冻结区和应急灶是临时搭的，而炒灶和出餐口是常设的。

Q8. 哪些做法能降低分支合并成本？

多选题 · hard

  • A.拆小功能点按时合并← 正确答案
  • B.提升合并频率缩短存活← 正确答案
  • C.增加常驻分支的种类
  • D.尽量缩小分支存活时间← 正确答案

答案：ABD。合并成本与分支种类数和存活时间正相关。拆小功能、提升合并频率、缩短分支存活时间都能降低成本；增加分支种类只会让合并通路更多、成本更高。

Q9. Trunk Based 开发的核心要求是什么？

单选题 · mid

  • A.保留多条长期分支
  • B.分支存活时间尽量短← 正确答案
  • C.必须有 develop 分支
  • D.禁止使用拉取请求

答案：B。Trunk Based 的核心是共用主干、缩短分支存活时间，通常要求几小时到一天内合入。它并不禁止 PR，也不要求必须有 develop 分支。铁板烧的菜要现炒现上，不能提前切好放三天。

Q10. 关于分支策略选型，以下说法正确的有哪些？

多选题 · extreme

  • A.小团队持续交付优先用 GitHub Flow← 正确答案
  • B.多版本并行的项目适合 GitFlow← 正确答案
  • C.持续部署较契合 GitHub Flow← 正确答案
  • D.GitFlow 适合每天多次部署

答案：ABC。GitHub Flow 适合小团队、高频发布、持续部署；GitFlow 适合多版本并行、批次发布。GitFlow 的 release 冻结期让它在每天多次部署的场景下显得笨重，所以 D 错误。选型要像点菜一样先问产品类型、发布频率和团队经验。