分支策略与提交规范

• 双主干分支的角色
• 各辅助分支的生命周期
• 适用场景

Git Flow 由 Vincent Driessen 提出，采用两条长期主干：master（main）保存始终可发布的稳定版本，每个发布点打 tag；develop 是集成分支，保存日常开发的功能。辅助分支按需创建并最终合并回主干：feature/* 从 develop 拉出，开发完成后合并回 develop；release/* 在准备发布时从 develop 拉出，只做修复与版本微调，完成后并入 master 和 develop；hotfix/* 从 master 拉出用于紧急修复，完成后并入 master 和 develop。各分支职责明确，适合版本化发布的产品。

Git Flow 的价值在于把"发布"与"开发"严格分离，通过 release 分支冻结发布内容、hotfix 分支快速修复线上问题。但流程较复杂，分支生命周期长，对团队协作要求高。它适合有明确版本节奏、需要维护多个版本线的产品（如桌面应用、移动 App），而对持续部署的 SaaS 可能过重。

• GitHub Flow 的核心模型
• 与 Git Flow 的差异
• 适用场景

GitHub Flow 是一种极简分支模型：只有一条长期主干 master（main），始终可部署；所有改动从 master 拉出短命 feature 分支，开发完成后通过 Pull Request 评审并合并回 master；合并后立即（或很快）部署。它没有 develop、release、hotfix 分支，紧急修复也只是从 master 拉分支快速合回。核心是"master 始终可部署 + 小步快跑 + PR 评审"。

GitHub Flow 的轻量级在于去掉所有长期辅助分支，用 PR 承载评审与核对，用"随时可部署的 master"保证主干始终健康。它非常适合 SaaS 与持续部署场景，因为发布频率高、无需维护多版本线。代价是需要完善的自动化测试与部署能力，否则"master 始终可部署"难以保证。

• 环境分支的含义
• 如何用环境分支管理多环境部署
• 与 GitHub Flow 的差异

GitLab Flow 在 GitHub Flow 基础上引入"环境分支"（environment branch）概念：每个部署环境（如 pre-production、production）对应一个分支，功能分支通过 PR 合并到环境分支，再按需向上游环境推进（如 pre-production → production）。合并到环境分支即触发对应环境的部署。这让"代码在哪个环境尚未上线"可以通过分支的关系直观表达，为多环境部署提供清晰模型。

环境分支把"部署状态"显式编码进分支拓扑，适合需要分阶段上线、多环境验证的 SaaS 场景。相比 GitHub Flow 的"单一 master 直接部署"，GitLab Flow 更适合发布节奏较慢、需要多环境逐步稳定（staging → pre-prod → prod）的团队。它兼顾了主干开发的简洁与多环境需求的清晰。

• 主干开发的核心理念
• 短小 PR 与高频率合并的意义
• 与 feature flag 的关系

Trunk-Based Development（主干开发）倡导所有开发者在单一主干（trunk/main）上持续集成，特性分支要么极短（< 1 天）要么直接向主干提交。核心是"短小 PR + 高频率合并"：把改动拆成小单元，频繁合并回主干，避免长期分支导致的高额合并成本与大 diff。配合特性开关（feature flag）将未完成功能遮蔽，即使未完成也不阻塞主干。主干始终可部署。

短小高频率合并的核心收益是减少冲突、加速反馈、提高主干的可集成性。主干开发适合 CI/CD 成熟、自动化测试充分的团队，因为它把"集成"从"发布前的灾难"变成"日常的常态"。代价是需要高度自律的拆分与强制的测试门禁。

• 保护规则的作用
• required reviewers 与 required status checks 的含义
• 对主干健康的价值

分支保护规则（branch protection）用于保护重要分支（如 main、master）不被随意改动。常见规则包括：required reviewers（至少指定数量的评审者批准后才能合并）、required status checks（必填的 CI 检查全部通过后才能合并，如测试、lint、构建）、以及禁止直接 push、要求线性历史等。这些规则把"代码质量门槛"变成平台强制，防止不合规代码进入主干。

保护规则是分支策略落地的强制手段。required reviewers 保证有人工把关，required status checks 保证自动化门禁，二者结合形成"人工 + 自动"的双重防线。工程上应为核心分支配置保护规则，并随团队需要调整（如紧急修复可临时放宽但需留痕）。

• 常见分支命名前缀
• 命名规范的价值
• 与工具/CI 的结合

分支命名规范约定用前缀表示分支意图，如 feature/xxx（新功能）、bugfix/xxx（缺陷修复）、release/xxx（发布准备）、hotfix/xxx（紧急修复）、chore/xxx（维护）。工程价值在于：一是可读性——一看名字就懂分支用途；二是可自动化——CI 可通过分支名判断触发场景（如 hotfix 触发紧急发布流水线、release 触发预发布）；三是便于过滤与清理——对应的 branch 规则、清理脚本可依赖前缀。

命名规范是"约定"而非"平台强制"，其价值通过一致性放大。统一前缀让团队协作有共同语言，也让 CI/脚本能按前缀分流处理。工程上应把命名规范写入团队约定文档，并在 CI 中利用前缀（如正则匹配）触发对应流程。

• 长期/短期分支的差异
• 各自的风险与收益
• 如何取舍

长期分支（long-lived）指存在时间很长的分支（如 develop、release、长期 feature 分支），其优势是隔离开发与发布、便于维护多版本线；劣势是分支间差异随时间增大，合并时冲突多、diff 大、集成困难，且评审难以覆盖大改动。短期分支（short-lived）指存在时间短、改动小的分支（如主干开发中的短命 feature 分支），优势是冲突少、集成频繁、评审聚焦、回滚容易；劣势是需要更强的 CI 与自律，且不适合多版本维护。

取舍的核心是"分支存在时间"与"集成成本"的关系。长期分支积累的债务（合并冲突、review 负担）往往在合并时刻集中爆发；短期分支把成本摊薄到每次小合并。工程上多数团队倾向尽量缩短分支寿命，仅在确有版本线需求时保留必要长期分支。

• Git LFS 的适用场景
• LFS 指针机制
• 配额与成本

Git LFS（Large File Storage）用于让 Git 管理大文件（如二进制模型、媒体、文档、数据集）而不使仓库膨胀。其原理是：LFS 将大文件内容存到远端 LFS 存储，仓库中仅保存一个"指针文件"（文本，含文件 oid 与指针），git 检出时再按需下载真实内容。适用边界是"二进制资产"而非"源码"——源码应保持文本、可 diff、可 merge，不适合进 LFS。LFS 有配额与成本：GitHub 等平台对 LFS 存储与带宽有配额限制，超出需付费，且 LFS 文件不参与常规 diff，历史中每份 LFS 版本都占存储。

判断是否用 LFS 的关键是"文件是否适合 git 的文本/增量模型"。大而不可 diff 的二进制进 LFS 合理；而源码、配置、小型文本应留在常规 git。LFS 的退出是"不可逆"的（一旦加入需 filter-repo 才能彻底移除），成本与配额约束要求谨慎评估。工程上应设定大文件策略（如 > 100MB 进 LFS 或进对象存储）。

• Git Flow 的特长
• 为何适合版本化产品
• 边界

Git Flow 适合需要"版本化发布、维护多个版本线"的产品，如桌面应用、移动 App。这类产品以明确的版本号发布（如 1.x、2.x），需要同时维护多个已发布版本（如旧版本仍收 hotfix），且发布节奏由产品决定而非"随时可部署"。Git Flow 的 release 分支用于冻结某个版本的内容、hotfix 分支用于对已发布版本快速打补丁，正好匹配这种多版本线管理需求。store 审核、版本冻结等场景也依赖此模型。

Git Flow 的"master 存稳定版、develop 做集成、release/hotfix 管版本线"与版本化产品的发布形态高度契合。但当产品转向持续部署（如云服务）时，Git Flow 的重流程会拖慢节奏。因此选择 Git Flow 的关键判断是"是否有明确版本号与多版本维护需求"。

• GitHub Flow 的特长
• 为何适合 SaaS 持续部署
• 边界

GitHub Flow 适合 SaaS 等需要持续部署的产品。其核心理念"master 始终可部署 + 短命 feature 分支 + PR 合并即部署"与持续部署的节奏天然契合：每次合并到 master 即可触发部署，无需维护多个版本线或冻结发布。SaaS 通常由服务端统一管理版本，用户无需安装特定版本，因此不需要 Git Flow 的多版本线，轻量模型能最大化迭代速度。

持续部署的关键是"高频、低风险地发布"，GitHub Flow 通过短命分支、PR 评审、自动部署实现这一点。它要求主干始终健康（靠测试与保护规则保证）以及部署能力自动化。当产品无需多版本维护、发布频率高时，GitHub Flow 是最佳选择。

• GitLab Flow 的特长
• 为何适合多环境 SaaS
• 与 GitHub Flow 的差异

GitLab Flow 适合需要多环境（如 staging、pre-production、production）逐步验证的 SaaS。通过环境分支（environment branch）让"代码在哪个环境"通过分支关系清晰表达：功能分支合并到对应环境分支即触发该环境部署，再按发布节奏向上游推进。这适合需要分阶段灰度、人工验证、或合规审批的多环境 SaaS，比 GitHub Flow 的"一步到位"更可控。

多环境 SaaS 的痛点是把"部署状态"与"发布节奏"显式管理起来。GitLab Flow 的环境分支正是为此设计，兼顾主干开发的简洁与多环境验证的清晰。若产品需要多环境逐步上线且节奏较慢，GitLab Flow 优于纯 GitHub Flow；若追求极致快速部署，则 GitHub Flow 更直接。

• TBD 的适用前提
• 为何适合成熟 CI/CD 的 SaaS
• 边界

Trunk-Based Development 适合 CI/CD 成熟、自动化测试充分的 SaaS 团队。其高频合并、主干始终可部署的前提是"每次合并都经过自动化验证"，因此需要成熟的 CI（快速测试、门禁）与 CD（部署自动化）。成熟的 CI/CD 让短小高频合并无风险，也让 feature flag 能安全遮蔽未完成功能。这样团队能最大化发布频率而不牺牲主干稳定性。

TBD 对基础设施要求高：没有强 CI 与 CD，高频合并会引入大量回归。成熟 CI/CD 的 SaaS 恰好具备这些条件，因此 TBD 是这类团队的主流选择。若团队 CI/CD 不成熟或发布频率低，TBD 收益有限，可能 Git Flow/GitLab Flow 更稳。

• 分支策略与 CI/CD 的关系
• 不同分支策略对 CI/CD 的要求
• 集成程度的工程影响

分支策略与 CI/CD 的集成程度决定了自动化能在何时、以何种方式介入。轻量分支策略（如 GitHub Flow、TBD）要求高集成：每次 push 触发测试、合并到 master 触发部署，CI/CD 是"主干可部署"的保障。重分支策略（如 Git Flow）也可以集成 CI/CD：release 分支触发预发布构建、hotfix 触发紧急发布流水线，但集成点更多、更复杂。集成程度越高，自动化对质量的保障越强，但配置与维护成本也越高。

分支策略本质上定义了"何时产生可部署的产物"，CI/CD 则负责在该时机执行验证与发布。团队应让 CI/CD 与分支策略匹配：轻量策略依赖强的 CI/CD 门禁，重策略可利用分支做差异化流程。工程上应按分支前缀/事件触发精准的流水线，避免过度集成或集成不足。

• 发布节奏与分支策略的关系
• 不同节奏匹配的分支策略
• 对齐的价值

发布节奏（release cadence）指发版的频率（日常、每周、每月、每季度等），分支策略应与之对齐。高频发布（如每天多次）适合 GitHub Flow / TBD，因为不需要版本冻结或多版本线；低频发布（如每月、每季度）适合 Git Flow，因为 release 分支可承载"冻结并打磨"的过程；多环境逐步发布适合 GitLab Flow。发布节奏越频繁，分支越应短命、流程越应轻量。

分支策略与发布节奏错配会导致冲突：高频发布用 Git Flow 的重流程会拖慢节奏；低频发布用 TBD 则缺乏版本冻结机制。对齐的意义是让"分支结构"为"发布节奏"服务，避免不必要的复杂度或缺失的管控。工程上应明确发布节奏，再据此选择分支与流程。

• 团队规模对分支策略的影响
• 小团队与大团队的分支选择
• 适配的价值

团队规模影响分支策略的选择。小团队（如 1-5 人）协作简单、合并冲突少，适合轻量模型（GitHub Flow / TBD 或简化 Git Flow），避免过度流程。大团队（数十人以上）并发改动多、冲突与集成风险高，需要更强的流程约束（保护规则、强制评审、明确分支角色），或更适合 TBD + 强 CI 以控制冲突。团队规模越大，越需要把"协作规则"显式化以降低协调成本。

分支策略本质是"团队协作的契约"。小团队可用口头约定维持，大团队则需平台强制（保护规则、评审门禁）。同时大团队并发大，TBD 的短小高频合并能减少冲突，但前提是强 CI。工程上应随团队扩张调整分支策略与保护规则，而非一成不变。

• sparse checkout 的原理
• partial clone 的原理
• 两者在 monorepo 中的应用

在大型 monorepo 中，完整检出体积巨大。sparse checkout（稀疏检出）只检出仓库中指定的子目录/文件到工作区，元数据仍完整，减少的是工作区文件量。partial clone（部分克隆）通过 --filter=blob:none 等选项延迟下载 blob（文件内容），本地只保留 commit/tree 等元数据，访问具体文件时才按需拉取，减少的是仓库体积。二者可组合使用：先部分克隆再稀疏检出，大幅降低 clone 与 checkout 成本。

monorepo 的性能痛点是"全量获取"成本高。sparse checkout 解决"工作区不必要文件"，partial clone 解决"历史上不必要内容"。工程上可在 CI 与本地开发中组合二者，只拉取改动涉及的子包。但要权衡：partial clone 在后续操作中可能因按需下载而增加网络往返，需配合 --filter=tree:0、--depth 等进一步优化。

• .gitattributes 的作用
• 换行符规范化
• 自定义 merge driver

.gitattributes 用属性模式控制 git 对文件的行为。换行符规范化通过 text 与 eol 属性实现：如 *.js text eol=lf 将 JS 文件强制使用 LF 存入仓库，*.bat text eol=crlf 强制 CRLF；* text=auto 让 git 自动检测文本文件。这能避免同一文件在不同平台检出/提交时换行符反复变化造成的"假 diff"。自定义合并驱动（merge driver）通过 *.conf merge=ours 等为特定文件指定 merge 属性，并结合 .git/config 中 [merge "ours"] driver = true 定义合并策略，使指定文件在合并时按自定义规则处理（如始终保留一方）。

换行符规范化是跨平台协作的核心，配合 core.autocrlf 可彻底解决 CRLF/LF 混乱。自定义 merge driver 用于对二进制或特殊文件（如锁文件、生成文件）在合并时应用特定策略，避免默认 merge 的误合并。工程上应把换行符规则与合并策略写入 .gitattributes 并入库，保证所有协作者一致。

• rebase 与 merge 的差异
• 线性历史 vs 完整历史的权衡
• 各自的工程价值

git merge 保留实时的分支拓扑与合并节点，生成的是"完整历史"——能如实反映分支何时合并、并行开发关系，但历史中有分叉与合并节点，git log --graph 较复杂。git rebase 将当前分支的提交"重放"到目标分支尖端，生成"线性历史"——无分叉，git log 清晰易读，但改变了提交的原始时间与身份（重写历史），且丢失了合并的原始拓扑信息。取舍在于：线性历史便于回溯、git bisect 与评审；完整历史保留了真实开发过程。

选择取决于团队对"可读性"与"真实性"的偏好。许多团队在共享主干上采用 merge 以保留真实历史，在个人/特性分支上采用 rebase 以保持整洁，再用 squash merge 合并。黄金法则是：不要 rebase 已共享（已推送）的分支，否则破坏他人历史。工程上应在"与共享分支合并用 merge、整理个人分支用 rebase"之间取得平衡。

• interactive rebase 的操作
• 各操作的含义与场景
• 注意点

git rebase -i（交互式变基）打开一个待整理提交列表，可对每个提交执行操作：squash（与前一提交合并，message 合并）、fixup（合并但丢弃 message）、reword（修改提交信息）、reorder（调整提交顺序）、drop（删除提交）、edit（暂停以分拆或修改）。常用于把开发过程中的零碎提交整理成逻辑清晰、粒度合理的提交序列，再合入主干。配合 autosquash 可自动整理 fixup!/squash! 前缀的提交。

interactive rebase 的工程价值在于"提交历史保洁"——把混乱的 WIP 提交整理成可读、可 bisect 的序列。但它重写历史，因此只应用于尚未共享的分支。工程上常见流程是：功能分支开发完成后交互式 rebase 整理，再 squash/merge 到主干。操作前应先备份（如用 reflog 兜底）。

• rerere 的原理
• 启用方式
• 工程价值

Rerere（reuse recorded resolution）是 Git 的一项功能，它会记录你曾经手动解决的冲突方案，并在后续遇到相同冲突时自动重放相同的解决方式。启用方式为 git config --global rerere.enabled true。工程价值在于：在 rebase 或 merge 中反复出现相同冲突时（如对同一分支多次 rebase），无需每次手动解决，且能减少冲突解决带来的错误。它特别适合"需要多次整理/重放提交"的场景。

Rerere 的价值在于"冲突解决的经验复用"。当同一代码冲突在多次 rebase/merge 中反复出现时，rerere 能自动沿用上次的解决结果，节省时间并保持一致性。但它也可能重放"错误"的解决，因此需谨慎。工程上建议在长期使用 rebase 或多次合并的团队中启用。

• --onto 的语法与含义
• 适用场景
• 与普通 rebase 的差异

git rebase --onto <newbase> <upstream> <branch> 用于把 <branch> 中从 <upstream> 之后的提交"嫁接"到 <newbase> 之上。它摆脱了普通 rebase 只能"重放到原基础上游"的限制，允许把一串提交移到任意新的基线上。典型场景：想把某个分支的提交平移到另一个分支上（如从 master 嫁接到 develop）、从一段历史中摘出某段提交重放到新基、或修复因错误 rebase 产生的混乱历史。

--onto 是"摘取一段提交并换基"的精确工具，比普通 rebase 更灵活。需理解其三个参数的作用：<newbase> 是新的父提交，<upstream> 界定要移动的提交范围，<branch> 是被移动的分支。用法有一定门槛，但掌握后能解决复杂的分支嫁接场景。使用前应确认范围，防止误移提交。

• 3-way merge 的原理
• recursive merge
• union merge

3-way merge是 Git 默认的合并算法：以"共同祖先（base）+ 两个分支的最新版本"三方比较，只有两侧都修改同一处且内容不同时才产生冲突。recursive merge是 3-way merge 的扩展，当两个分支存在多个共同祖先时，它先递归合并这些祖先形成一个虚拟基，再进行三方合并，从而更准确。union merge 是一种特殊合并驱动，将两侧的冲突行简单拼接（union），不产生冲突，适合某些特定文件（如文档、日志）但可能产生语义错误。Git 默认使用 recursive（现为 ort）策略。

理解冲突产生机制有助于更有效地解决。3-way/recursive 的"以祖先为基"是 git 能自动合并大部分改动的原因；union merge 则用"全保留"规避冲突。工程上应针对不同文件选择合适合并策略（如对生成文件用 union 或 ours），并通过清晰的小 PR 减少冲突。

• 冲突的成因
• 预防手段
• 工程价值

冲突的根源是"多人同时修改同一区域"。预防策略包括：小 PR——把改动拆小，并发改动重叠概率低，减少冲突面；频繁同步——定期把主干更新合并到自己的分支（或 rebase），使分支与主干保持接近，避免长期分叉后的集中冲突；单向所有权——对文件/模块建立"负责人"，降低多人同时改同一文件的概率。这些手段从源头减少冲突发生，而非仅靠事后解决。

冲突解决是"事后成本"，而预防是"事前收益"。小 PR 降低并发重叠，频繁同步把冲突摊薄到小批量，单向所有权组织化减少重叠。工程上应把冲突预防纳入团队协作规范（如拆分任务、及时同步、明确模块归属），与"事后有效地解决冲突"能力并重。

• reflog 的作用
• rebase 后找回丢失提交的步骤
• 恢复的边界

reflog（reference log）记录了 HEAD 与分支引用的历史移动，包括 rebase、reset、cherry-pick 等操作。rebase 会重写提交，若操作失误或丢失提交，可用 git reflog 查看 HEAD 的历史引用，找到 rebase 前分支指向的提交（如 HEAD@{before}），再用 git reset --hard <sha> 或 git branch <name> <sha> 恢复。恢复的边界是：只要提交未被 git garbage collection（GC）清除，即可找回；reflog 默认保留有期限（如 90 天），过期或 GC 后可能无法恢复。

reflog 是"git 撤销的世界里的时间机器"，是 rebase 事故的兜底。关键洞察是：rebase 不会立即删除旧提交，只是使其"不可达"，reflog 仍保留引用。工程上应养成"危险操作前记录原分支位置"的习惯，并在误操作时第一时间用 reflog 恢复，避免 GC 清除。

• 评审与主干开发的调和
• feature flag 的作用
• 短小合并与评审的平衡

在 TBD 中，虽然提倡短命分支或直接提交主干，但评审（code review）仍然必要。调和方式在于：改动被拆得足够小，使每个提交/PR 都是可快速评审的小单元，评审负担被摊薄；同时通过 feature flag 把未完成的功能遮蔽，使"未完成代码"也能安全合入主干而不影响用户，从而允许更小的、频繁的合并，而评审聚焦于每个小改动。评审仍保留人工把关，但审查对象是"小、可理解、被 flag 遮蔽"的改动。

传统上"直接提交主干"与"评审"看似矛盾，但 TBD 通过两个机制调和：一是 feature flag 让半成品可安全进主干，降低"必须完全完成才合入"的压力；二是小改动让评审更高频、更聚焦。这样既保持主干集成频率，又保留质量门禁。工程上应把评审重点放在"小提交的正确性"与"flag 开关的健壮性"上。

• release 与 hotfix 的评审差异
• 紧急修复的批准流程
• 事后补审机制

release 分支的评审接近常规流程：改动聚焦于修复与打磨，有相对充裕的时间，可走完整评审。hotfix 分支因紧急（线上事故）需快速上线，评审责任上往往"放宽门槛、加快放行"：通常由技术负责人/关键维护者快速批准，或收紧到"一人评审 + 必要测试"即可合入。事后补审（post-review）指在 hotfix 上线后，对合入的变更进行补充评审，记录上下文、确认改动质量，并沉淀为流程改进。核心是"紧急修复快速放行，但需事后补审以弥补质量把关"。

紧急修复与常规评审在"速度 vs 质量"上冲突。合理做法是：紧急场景下授权快速批准（由负责人把关），但必须事后补审，避免"紧急"成为绕过评审的借口。工程上应定义 hotfix 的放行授权、最小测试要求与事后补审时限，并让 release 分支走完整评审。

• type 驱动语义化版本
• type 驱动自动 CHANGELOG
• 对评审效率的价值

Conventional Commits 的 type 让提交自带"变更语义"：feat 触发 MINOR、fix 触发 PATCH、BREAKING CHANGE 触发 MAJOR，工具据此自动推算版本号；refactor、docs、chore 等不改变版本。同时，工具根据 type 把提交自动归类到 CHANGELOG 的对应分类（feat→Added、fix→Fixed），生成结构化 CHANGELOG。这让评审者无需追问"这是什么变更、影响哪个版本"，因为提交 header 已携带结构化信息，评审可聚焦于"变更是否正确"而非"变更是什么"。

评审中常见的"这个改动的类型/影响是什么"提问，其实是被结构化信息缺失所致。Conventional Commits 把"变更类型"编码进提交消息，使评审者、工具、文档共享同一语义，显著减少解释成本。工程上要求清晰的 type 与 scope，是让评审更高效、版本与 CHANGELOG 更准确的前提。

• 提交粒度的概念
• 细粒度提交的好处
• 巨型提交的弊端

提交粒度指"一个提交包含多少改动"。理想粒度是"一个逻辑变更一个提交"：每个提交自洽、可独立理解、可独立测试，便于逐提交评审、git bisect 定位回归、以及 cherry-pick 精确摘取。巨型提交（把大量无关改动混在一个提交）则难以评审、难以用 git bisect 定位具体回归、难以回滚或摘取，历史可回溯性差。粒度过细（每个提交过碎）也会增加噪音，需在"逻辑一致"与"足够小"间平衡。

提交是历史回溯的最小单元，粒度决定回溯效率。好的粒度让"某一改动"能精确定位，坏粒度让问题难以定位。工程上应遵循"一个逻辑变更一个提交"，在提交前用 git add -p 拆分改动，并在交互式 rebase 中整理。这既利于评审，也利于 QA 与事故定位。

• autosquash 的原理
• fixup! 与 squash! 的区别
• 使用方法

git rebase -i --autosquash（或配置 rebase.autoSquash）会自动识别以 fixup! <原提交描述> 或 squash! <原提交描述> 开头的提交，并在交互式 rebase 的 todo 列表中自动把它们放到对应原提交之后，标记为 fixup 或 squash。fixup! 会把该提交合并进原提交且丢弃其消息；squash! 合并进原提交但保留其消息供合并。这让"临时追加的修正"能自动归属到对应提交，无需手动调整顺序。

autosquash 把"提交保洁"半自动化：开发中新增修正提交时按 fixup!/squash! 命名，整理时自动归位合并。这减少手动 reorder 的繁琐，使历史始终整洁。工程上建议在功能分支用此模式，并结合 --fixup/--squash 参数让 git 自动生成这类提交。

• 黄金法则的含义
• 为什么不能 rebase 共享分支
• 例外与处理

rebase 的黄金法则：不要 rebase 已共享的分支（已被他人 clone 或 push 到远端的分支）。因为 rebase 会重写提交（改变 SHA），若他人已基于原提交工作，rebase 后他们的历史与远端冲突，需要强推，导致他人无法正常 pull、产生大量合并冲突。因此 rebase 只应用于自己私有、未共享的分支。对已共享分支，应使用 merge 整合。

黄金法则的实质是"不要破坏他人已依赖的历史"。重写已共享历史会迫使所有协作者处理混乱。工程上应区分"私有分支可自由 rebase"与"共享分支只能 merge"。若确需整理共享分支，需与团队协调并告知所有人，通常用强推前明确提示。

• BREAKING CHANGE 触发 major
• 评审加强机制
• 工程价值

BREAKING CHANGE（如 ! 后缀或 footer）会触发 MAJOR 版本升级，向用户发出"破坏性变更"信号。评审加强机制指：当提交包含 BREAKING CHANGE 时，团队应触发更强的评审与确认——因为这会影响所有下游用户。工程上可通过工具（如 commitlint 检查 BREAKING CHANGE 是否需要描述）、CI（在含 BREAKING CHANGE 的 PR 上要求额外评审/迁移说明）、以及发布流程（major 发布前强制 review 迁移指南）来加强把关。

BREAKING CHANGE 是"高影响"变更，其风险远高于普通 feat/fix。因此除了版本号升级，还应通过评审机制提高关注度。工程上把"是否含 BREAKING CHANGE"与评审强度挂钩，确保破坏性变更被充分评估、记录并传达。

• 长期分支与大 diff 的关系
• 评审负担与节奏
• 与分支策略的耦合

长期分支存在时间越长，与主干的差异越大，累积的 diff 越大，评审就越困难——评审者面对数千行改动难以聚焦、难以理解上下文，且评审本身拖慢合并，进一步延长分支寿命，形成恶性循环。这使"评审 SLA"（评审时效）与分支策略强耦合：短命分支（TBD / 短 PR）diff 小、评审快、SLA 高；长期分支 diff 大、评审慢、SLA 低。因此分支策略应推动小 diff、高频评审。

评审效率与 diff 大小负相关。长期分支的"大 diff"是评审的天然敌人，会让人难以保证质量、难以按时完成。工程上应通过短命分支、小 PR、频繁同步来保证 diff 可控，从而维持评审 SLA 与质量。若必须用长期分支，应定期同步主干以控制 diff 增长。

• 原子提交的含义
• 好处
• 实践方法

原子提交（atomic commit）指每个提交自身是自洽的：能独立编译、通过测试、不破坏主干。这样提交序列中的每个点都是"健康"的，可逐提交评审、可安全回滚到任意提交、可用于 git bisect 精确定位回归（因为每个点都可构建）。原子提交要求把改动拆成"逻辑完整且可运行"的单元，而非"改一半"的中间状态。

原子提交的价值在于"提交序列的每个点都可验证"。这在 git bisect 时至关重要——若某提交不可构建，bisect 会误判。工程上应通过 CI 验证每个提交、用 git add -p 组织改动、在回滚或 bisect 时依赖"每个提交健康"。这与"一个逻辑变更一个提交"互补。

• body 的撰写原则
• 评审价值
• 考古（历史回溯）价值

提交消息正文（body）应说明"为什么"做这个变更（动机、背景、权衡、限制），而非复述"做了什么"（diff 已能看出改了什么）。"为什么"的记录对评审者有价值——让他们理解变更动机，判断是否合理；对历史回溯（考古）更有价值——几个月或几年后，后人通过 body 理解当时为何如此设计，避免误改或重复犯错误。而"做了什么"能从 diff 看到，写在 body 中是冗余。

好的提交 body 是"决策记录"，承载了 diff 无法表达的信息。工程上应鼓励在 body 中写背景、方案权衡、影响与后续待办事项，而非罗列改动的文件。这使提交同时成为文档与历史，是"考古价值"的核心。