Git PR合并策略选择指南：历史可读性与协作效率的平衡

Git 的 Pull Request 合并策略不是按钮点一下就完事的“流程终点”而是团队协作质量、历史可读性、故障回溯能力、甚至新人上手速度的“起点”。我带过 7 个不同规模的开发团队从 3 人初创到 40 人的跨时区项目踩过所有合并方式的坑——有人用 Squash 把三个月的迭代逻辑压成一行提交信息结果线上出 Bug 时连哪次重构引入的问题都定位不了也有人坚持 Create Merge Commit结果主干日志里塞满“Merge branch feature/login into main”这种毫无信息量的记录CI 流水线失败后排查两小时才找到真正出问题的那一次 commit还有团队盲目 Rebase and Merge导致 feature 分支被强制重写协作成员 fetch 后本地分支直接“失联”集体卡在 git status 里发呆……这些都不是理论风险是我凌晨三点帮同事救火时的真实截图。Git 本身没有对错但合并方式选错了就是把协作成本悄悄转嫁给了所有人。这篇文章不讲概念定义只讲我在真实项目中怎么选、为什么这么选、每种方式在什么场景下是银弹、又在什么条件下会变成地雷。核心关键词就一个Git。它不是命令行工具的代名词而是团队代码契约的载体。你今天点下的那个合并按钮本质上是在签署一份关于“我们如何共同维护这段历史”的协议。适合谁看刚学会 git push 的新人、正在制定团队 Git 规范的 Tech Lead、被混乱提交历史折磨得想重开仓库的维护者以及所有以为“能合进去就行”的开发者——这篇内容就是给你补上那张没人教过的“合并决策地图”。1. 合并策略的本质不是操作差异而是协作契约的三种形态1.1 所有合并方式都绕不开的底层事实Git 的“快进”与“三方合并”机制要真正理解三种 PR 合并方式的区别必须先回到 Git 最底层的两个动作fast-forward快进和three-way merge三方合并。这不是教科书里的抽象概念而是每次点击“Merge”按钮时Git 实际执行的物理过程。假设当前main分支最新提交是C3而你的feature/login分支是从C3拉出来的之后你本地提交了C4 → C5 → C6三个 commit。此时如果main分支自C3之后没有任何新提交那么 Git 就可以执行 fast-forward它不做任何合并计算只是把main分支指针直接“快进”到C6的位置。整个过程就像把一列火车从第 3 节车厢直接推到第 6 节中间轨道没被占用所以无需调度。这种情况下无论你在 GitHub 上选哪种合并方式最终效果都一样——main指针指向C6历史是线性的。但现实项目中这种情况极少发生。main几乎总是在你开发feature/login的同时被其他同事合入了C7、C8甚至C9。这时main和feature/login已经分叉Git 就必须启动三方合并它会找出两个分支的最近共同祖先common ancestor也就是C3然后把C3→C7/C8/C9main 的变化和C3→C4/C5/C6feature 的变化这两组修改以C3为基准做差异比对再尝试自动合并。如果冲突就停下来等你手动解决如果没有冲突Git 就会生成一个新的 commit我们叫它M1它的父节点有两个一个是C9main 当前 tip另一个是C6feature 当前 tip。这个M1就是真正的“合并提交”。提示GitHub 上所有 PR 合并按钮背后本质都是在触发这个三方合并流程。区别只在于是否生成这个M1提交这个M1提交里包含哪些变更以及feature分支的原始 commit 是否保留在主干历史中这三个问题的答案就定义了三种策略的根本差异。1.2 Create Merge Commit保留完整分支拓扑代价是历史“毛刺化”Create Merge Commit 是最忠实于 Git 原生行为的方式。它严格遵循三方合并逻辑生成一个真实的、带有两个父节点的合并提交M1并且完全保留feature/login分支上的所有原始 commitC4, C5, C6原封不动地接入主干历史。它的价值在于“可追溯性”被最大化。比如某天线上出现一个登录页样式错位的问题你通过git blame定位到某个 CSS 文件的某一行发现它是在C5中被修改的。你立刻就能git show C5看到当时的完整上下文这次修改是为了解决 iOS Safari 下按钮点击无反馈的问题配套改了 JS 的事件绑定逻辑并且测试用例test_login_button_tap.js也同步更新了。所有线索都在一个 commit 里闭环。你不需要去猜“这个样式改动是不是和那次权限校验重构一起合进来的”因为它们根本不在同一个 commit 里。但代价也很真实主干历史会变得“毛刺化”。想象一个持续半年的项目平均每天有 3~5 个 PR 合入每个 PR 平均含 4~6 个 commit。半年下来main分支的提交图谱会像一张密集的蜘蛛网大量Merge branch feature/xxx into main提交穿插其中。如果你用git log --oneline查看满屏都是a1b2c3d Merge branch feature/payment-v2 into main真正承载业务逻辑的e4f5g6h Refactor payment gateway adapter反而被淹没。更麻烦的是当你需要基于某个历史版本做 bisect二分查找时Git 会把每一个Merge commit都当作一个潜在的“坏提交”候选而它本身并不包含任何实际代码变更——这会让 bisect 过程多花 3~5 倍时间因为你得手动跳过所有 merge 提交。实操心得我在一个金融风控系统中坚持了 18 个月的 Create Merge Commit好处是审计时能精确到小时级还原每一次策略调整的完整链路坏处是新来的 SRE 同事第一次跑git log --graph --all --simplify-by-decoration --oneline时盯着终端沉默了三分钟然后问我“这个图……是需要配眼镜才能看懂吗”——后来我们加了一条团队规范所有 Merge commit 的 message 必须包含 Jira ID 和一句话摘要例如Merge branch feature/risk-score-boost into main (RISK-142: 15% false-negative reduction via new ML threshold)至少让git log --oneline不再是纯噪音。1.3 Squash and Merge用“单次交付”换取历史整洁但牺牲原子调试能力Squash and Merge 的核心动作是把feature/login分支上的全部 commitC4, C5, C6压缩squash成一个全新的 commitS1然后把这个S1以普通提交single-parent commit的形式追加到main分支的末尾。它不生成三方合并提交main的历史依然是线性的就像你一直在main上开发一样。这种方式最大的优势是主干历史极度“干净”。git log --oneline输出的结果是一条清晰的、按时间顺序排列的业务演进脉络a1b2c3d Add OAuth2 support for enterprise customers、e4f5g6h Fix race condition in session timeout handler、h7i8j9k Refactor notification service to use async queue……每个 commit 都是一个独立、完整、可描述的功能单元。CI 流水线失败时你能一眼锁定是哪个功能引入的问题产品同学问“XX 功能是哪天上线的”你git log --since2023-06-01 --grepXX一下就出结果甚至做季度复盘时导出git log --prettyformat:%ad %s --dateshort | sort就能得到一份天然的版本功能清单。但它付出的代价是原子调试能力的永久丧失。还是那个登录页样式问题git blame显示它来自S1。你git show S1看到的是一大坨混合了 HTML 结构调整、CSS 样式重写、JS 表单验证逻辑、以及配套单元测试的变更。你无法快速判断这个 CSS 修改到底是为了解决 Safari 兼容性还是为了适配新的设计稿它和 JS 的修改是否存在耦合测试用例的更新是覆盖了所有新逻辑还是只测了主路径你必须手动翻看 PR 的原始讨论、对比 diff、甚至去查 Slack 记录才能拼凑出上下文。在高压故障排查中这种信息缺失就是致命的延迟。注意Squash 的“单次交付”属性也意味着它天然不适合“渐进式重构”类工作。比如你用两周时间把一个 2000 行的旧服务逐步拆解为 5 个微服务模块期间每天提交 1~2 个小 commit 来保证 CI 通过、避免阻塞他人。如果最后 squash 成一个Refactor user-service to microservices architecture那这个 commit 的 diff 会超过 5000 行Code Review 几乎不可能完成CI 构建时间暴涨而且一旦失败你根本不知道是哪个模块的拆分出了问题。这类工作必须用 Create Merge Commit 或 Rebase and Merge 来保留中间状态。1.4 Rebase and Merge用“线性叙事”平衡历史与调试但要求强分支管控Rebase and Merge 的逻辑是先将feature/login分支上的所有 commitC4, C5, C6重新“播放”replay到当前main分支的最新提交比如 C9之后生成一组全新的 commitC4, C5, C6它们的 parent 是C9而不是原来的C3。然后再以 fast-forward 方式把main分支指针直接指向C6。整个过程不产生任何 merge commitmain历史保持绝对线性。它的精妙之处在于既获得了 Squash 的“线性历史”观感又保留了 Create Merge Commit 的“多 commit 调试能力”。git blame依然能精准定位到C5git show C5依然能看到那次 Safari 兼容性修复的完整上下文。你甚至可以用git log --oneline --first-parent main只看第一父节点得到一条干净的主干线也可以用git log --oneline main看所有节点展开看到完整的 feature 分支贡献。但它的脆弱性也正源于此。Rebase 的本质是重写 commit 的哈希值。C4变成了C4它们是两个完全不同的对象。这意味着如果你的feature/login分支已经推送到远程origin/feature/login而其他同事基于旧的C4在其上继续开发比如拉出了feature/login-ui那么当feature/login被 rebase 合并后feature/login-ui的基线就“断掉”了。那位同事git pull时会看到大量冲突或者更糟——他git push --force-with-lease强制推送会把feature/login的新历史覆盖掉导致团队协作彻底混乱。实操心得我在一个硬件驱动固件项目中推行 Rebase and Merge前提是制定了铁律所有 feature 分支必须设置为“不可推送”即只在本地存在PR 创建后立即启用 GitHub 的 “Require linear history” 保护规则并且所有成员必须养成git fetch origin git rebase origin/main的习惯。我们还写了一个 pre-commit hook检查当前分支是否跟踪远程如果是则禁止 commit。这套组合拳下来Rebase 的稳定性从 60% 提升到 99.8%。但代价是新成员入职培训的第一课就是《如何安全地 rebase》——这本身就是一种隐性的协作成本。2. 核心细节解析与实操要点参数、配置与不可见的陷阱2.1 GitHub 后台配置三种方式的开关逻辑与默认行为很多人以为三种合并方式是“点了就生效”其实 GitHub 的后台有一套精细的权限控制和默认策略。作为团队维护者你必须亲手配置否则新人随便点一下就可能破坏全队的历史规范。首先进入仓库 Settings → Options → Merge button。这里你会看到三个复选框[x] Allow merge commits[x] Allow squash merging[x] Allow rebase merging这三个选项不是“开启即可用”而是“开启后PR 页面才会显示对应按钮”。如果只勾选了前两个那么 PR 页面就只有 “Create a merge commit” 和 “Squash and merge” 两个按钮Rebase 选项根本不会出现。这是第一道防线。更重要的是默认合并方式Default merge method下拉菜单。它决定了当用户点击绿色的 “Merge pull request” 按钮而不是下面三个具体按钮时GitHub 会执行哪一种策略。这个默认值对新手极其危险。我见过太多团队把默认设为 Squash结果一位实习生在 PR 描述里写了 “WIP: don’t merge yet”但手滑点了那个大大的绿色按钮结果所有未完成的实验性代码被一股脑 squash 进了 mainCI 直接挂掉。所以我的建议是永远把默认合并方式设为 “Create a merge commit”。因为它是 Git 的“安全模式”——即使点错了也只是多一个无害的 merge commit不会丢失历史或重写分支。提示GitHub 还有一个隐藏配置项在 Settings → Branches → Branch protection rules → Edit rule。在这里你可以为main或develop分支启用 “Require linear history”。一旦开启GitHub 就会强制禁用 Create Merge Commit只允许 Squash 和 Rebase。这是推行线性历史的终极手段但必须配合严格的 Code Review 流程否则会极大增加 PR 合并阻力。2.2 VS Code 插件与本地 Git 配置让 IDE 成为你策略的延伸很多开发者以为合并策略只在 GitHub Web 界面生效其实 VS Code 的 GitHub Pull Requests Issues 插件以及本地 Git 配置都能深度影响你的日常操作。VS Code 插件在 PR 详情页右上角提供了一个下拉菜单让你选择合并方式。但它的行为有个关键细节当你选择 “Squash and merge” 时插件不会直接调用 GitHub API而是先在本地执行git merge --squash branch然后git commit最后git push。这意味着如果你本地的user.name和user.email配置错误比如还是你上一家公司的邮箱那么这个 squash commit 的 author 信息就会是错的后续审计时会出大问题。我见过一个医疗 SaaS 项目因为一位同事的 Git 邮箱没切过来导致一个关键的 HIPAA 合规性修复 commitauthor 显示为unknownold-company.com法务部直接发函要求追溯和修正。因此我强制团队在项目根目录下放置.gitconfig文件并加入.gitignore防止误提交内容如下[user] name Your Full Name email your-teamcurrent-company.com [commit] gpgsign true [merge] ff only最后一行ff only是关键。它告诉 Git任何 merge 操作都只允许 fast-forward禁止生成三方合并提交。这相当于在本地给 Create Merge Commit 加了一道锁。当你在 VS Code 里不小心点了 “Create a merge commit”Git 会直接报错fatal: Not possible to fast-forward, aborting.逼你停下来思考是不是该用 rebase 了是不是该先 fetch 更新 main 了这个看似“阻碍效率”的配置实则是防止低级错误的最强护栏。2.3 提交信息Commit Message的黄金模板让每种策略都物尽其用无论你选哪种合并方式提交信息的质量直接决定了这个策略是锦上添花还是画蛇添足。我总结了一套适用于所有场景的 “5W1H” 模板已在 5 个不同技术栈项目中验证有效type(scope): subject body footertype固定为feat、fix、refactor、docs、test、chore。这是自动化脚本如 semantic-release的基础。scope模块名如auth、payment、ui、api。它让git log --grepauth这类搜索成为可能。subject一句话摘要50 字以内用祈使句如 “Add OAuth2 support” 而非 “Added OAuth2 support”。body详细说明。必须回答What changed? Why is it needed? How was it tested?这是 Squash 和 Rebase 场景下替代原始 commit 信息的唯一载体。footer关联信息。Jira IDRISK-142、Breaking Change 声明BREAKING CHANGE: ...、Reviewed-by 签名。对于 Create Merge Commit这个模板主要用在feature分支的每个原始 commit 上。每个C4、C5都要严格遵守这样git log --oneline才有意义。对于 Squash and Merge这个模板必须用在 squash 之后的那个最终 commit 上。我见过太多团队把 PR 标题如 “Login Feature”直接当 squash message结果git log里全是废话。正确的做法是在 VS Code 的 squash commit 编辑框里手动输入符合模板的完整信息把 PR 描述、评论中的关键结论、测试结果全部浓缩进来。对于 Rebase and Merge这个模板同样适用但要注意rebase 过程中Git 会默认沿用原始 commit 的 message。所以你必须在 rebase 前确保所有原始 commit 都已按模板规范好。一个实用技巧是在git rebase -i HEAD~3的交互式编辑器里把所有pick改成reword然后逐个编辑 message。注意GitHub 的 “Squash and merge” 按钮有一个极易被忽略的细节——它默认会把 PR 的标题和描述作为 squash commit 的 message。这非常危险因为 PR 标题往往是 “WIP: Login Page UI” 这种草稿状态描述里可能包含 “TODO: add error handling” 这样的未完成项。所以永远不要依赖 GitHub 的默认 message务必在点击前手动清空并重写。我们团队在.github/PULL_REQUEST_TEMPLATE.md里第一行就写着“⚠️ Squash message must follow 5W1H template. Do NOT use PR title/description.”。2.4 CI/CD 流水线的适配不同策略对构建、测试、部署的影响合并策略的选择会直接影响你的 CI/CD 流水线设计。一个没适配好的流水线会让再好的策略变成灾难。首先是构建缓存Build Cache。Create Merge Commit 因为保留了所有原始 commit所以main分支的每次构建都可以精准复用C4、C5、C6对应的缓存块。而 Squash and Merge 生成的是一个全新的S1它的 hash 和任何旧 commit 都无关所以构建缓存命中率会暴跌。我们的 Node.js 项目在切换到 Squash 后CI 构建时间从平均 4.2 分钟涨到 7.8 分钟。解决方案是在S1的 commit message footer 里强制加入CACHE_KEY: feature-login-20230717然后在 CI 脚本里用这个 key 去主动拉取缓存。其次是测试策略。Create Merge Commit 天然支持 “per-commit testing” —— 你可以为每个C4、C5单独运行单元测试快速定位问题。而 Squash 后所有测试都只能在S1上运行一旦失败你得手动拆解 diff。为此我们为 Squash 场景定制了一个 “Squash Pre-Check” 流水线它会在 PR 关闭前自动 checkoutfeature分支运行git rebase -i --exec npm test HEAD~3确保每一个原始 commit 都能通过测试才允许 squash。最后是部署与发布。Rebase and Merge 的线性历史让git describe --tags这类语义化版本生成工具工作得无比顺畅。而 Create Merge Commit 的复杂图谱会让describe返回类似v2.1.0-34-ga1b2c3d这样难以解读的版本号。我们的解决方案是在 Create Merge Commit 场景下放弃describe改用git tag -l --sort-v:refname | head -n1获取最新 tag再结合git rev-list --count latest-tag..main计算距上次发布的 commit 数生成v2.1.042这样的版本号既准确又易读。3. 实操过程与核心环节实现从 PR 创建到合并完成的全流程拆解3.1 场景设定与初始状态一个真实的电商项目片段为了让你能跟着实操我们设定一个具体的、有血有肉的场景。这是一个名为shopify-plus的电商 SaaS 平台后端用 Go 编写前端用 React部署在 Kubernetes 上。当前main分支的状态如下git log --oneline -n 5a1b2c3d (HEAD - main) feat(api): add webhook retry mechanism for payment failures e4f5g6h fix(auth): resolve JWT token expiration race condition h7i8j9k refactor(cart): extract cart validation logic to dedicated service k0l1m2n docs: update API reference for /v2/orders endpoint m3n4o5p chore(deps): bump golang.org/x/crypto from v0.12.0 to v0.13.0现在你要开发一个新功能为商家后台添加“订单导出为 Excel”功能。你从main拉出分支feature/export-excel并在接下来的两天里完成了以下工作C1:feat(export): add basic CSV export endpoint实现了基础的 CSV 导出支持按日期范围筛选C2:fix(export): handle nil pointer panic when no orders found修复了空订单列表时的 panicC3:feat(export): add Excel (.xlsx) format support using github.com/tealeg/xlsx集成了 xlsx 库支持 Excel 格式C4:test(export): add integration tests for both CSV and Excel exports补充了端到端测试此时feature/export-excel分支的git log --oneline是w8x9y0z (HEAD - feature/export-excel) test(export): add integration tests for both CSV and Excel exports v7u8t9s feat(export): add Excel (.xlsx) format support using github.com/tealeg/xlsx r6s5t4u fix(export): handle nil pointer panic when no orders found q5p4o3n feat(export): add basic CSV export endpoint而main分支在这两天里又被其他同事合入了两个新 commita1b2c3d (HEAD - main) feat(api): add webhook retry mechanism for payment failures e4f5g6h fix(auth): resolve JWT token expiration race condition ...之前的提交所以main和feature/export-excel已经分叉共同祖先是m3n4o5p。3.2 Create Merge Commit 实操保留所有痕迹构建可审计历史第一步确保本地环境同步。在feature/export-excel分支下执行git fetch origin git rebase origin/main # 这一步可选但强烈推荐确保你的 feature 基于最新 mainrebase后你的feature/export-excel分支会变成w8x9y0z test(export): add integration tests for both CSV and Excel exports v7u8t9s feat(export): add Excel (.xlsx) format support using github.com/tealeg/xlsx r6s5t4u fix(export): handle nil pointer panic when no orders found q5p4o3n feat(export): add basic CSV export endpoint注意末尾的表示 commit hash 已变但 message 不变。第二步在 GitHub 上创建 PR目标分支为main。在 PR 描述中清晰写明What: 商家后台新增订单导出功能支持 CSV 和 Excel 两种格式。Why: 客户反馈现有 CSV 导出无法满足财务部门对格式和样式的严格要求。How: 使用tealeg/xlsx库生成 Excel所有导出逻辑复用现有 CSV 的数据查询层确保一致性。Test: 新增 4 个集成测试覆盖空订单、单订单、多订单、超长字段等边界场景。第三步等待 Code Review 通过后点击 “Create a merge commit” 按钮。GitHub 会生成一个新的合并提交M1其 message 默认为 “Merge pull request #123 from your-name/feature/export-excel”。但这是错误的你必须在点击前手动编辑 message改为Merge branch feature/export-excel into main (SHOP-456: Add Excel export for merchant dashboard) * feat(export): add basic CSV export endpoint * fix(export): handle nil pointer panic when no orders found * feat(export): add Excel (.xlsx) format support using github.com/tealeg/xlsx * test(export): add integration tests for both CSV and Excel exports Reviewed-by: Alice Chen alicecompany.com第四步合并完成后main的git log --oneline -n 10将是z1a2b3c (HEAD - main) Merge branch feature/export-excel into main (SHOP-456: Add Excel export for merchant dashboard) a1b2c3d feat(api): add webhook retry mechanism for payment failures e4f5g6h fix(auth): resolve JWT token expiration race condition h7i8j9k refactor(cart): extract cart validation logic to dedicated service k0l1m2n docs: update API reference for /v2/orders endpoint m3n4o5p chore(deps): bump golang.org/x/crypto from v0.12.0 to v0.13.0 w8x9y0z test(export): add integration tests for both CSV and Excel exports v7u8t9s feat(export): add Excel (.xlsx) format support using github.com/tealeg/xlsx r6s5t4u fix(export): handle nil pointer panic when no orders found q5p4o3n feat(export): add basic CSV export endpoint实操心得这个历史图谱就是你的“时间机器”。如果一周后发现 Excel 导出在特定字体下会崩溃你git bisect start HEAD q5p4o3nGit 会自动帮你二分最终精准定位到v7u8t9s这个 commit然后git show v7u8t9s就能看到当时集成tealeg/xlsx的全部细节包括它依赖的 Go 版本、已知的 issue 链接、以及你写的临时 workaround 注释。这种能力在 Create Merge Commit 下是开箱即用的。3.3 Squash and Merge 实操打造一条干净、可交付的主干线第一步同样从同步开始。但在feature/export-excel分支下我们不 rebase而是直接git fetch origin确保你知道main的最新状态是a1b2c3d。第二步创建 PR描述同上。但这次你明确在 PR 描述的开头加上⚠️ This PR MUST be merged with Squash and merge. Reason: The feature involves multiple small commits that are not meaningful on their own (e.g., C2 is just a panic fix for C1). A single, well-documented delivery commit provides the clearest signal for release notes and audit.第三步Review 通过后点击 “Squash and merge” 按钮。关键来了GitHub 会弹出一个编辑框预填充了 PR 标题和描述。你必须全部删除然后手动输入feat(export): add Excel export for merchant dashboard (SHOP-456) Implement full Excel (.xlsx) export functionality for the merchant order list, supporting date-range filtering and all existing CSV data fields. Why: - Customers require Excel format for financial reconciliation and reporting. - Existing CSV lacks formatting control (fonts, colors, formulas). How: - Integrated github.com/tealeg/xlsx v1.0.0. - Reused existing /api/v2/orders/export endpoint, added formatxlsx query param. - All business logic (filtering, pagination, data mapping) is shared with CSV export. Testing: - Added 4 new integration tests covering edge cases. - Manual QA on Chrome, Safari, Edge with 10k order datasets. BREAKING CHANGE: None. Backward compatible with existing CSV export. Reviewed-by: Bob Smith bobcompany.com第四步点击确认。main分支将新增一个 commitx9y0z1a (HEAD - main) feat(export): add Excel export for merchant dashboard (SHOP-456) a1b2c3d feat(api): add webhook retry mechanism for payment failures e4f5g6h fix(auth): resolve JWT token expiration race condition ...注意这个x9y0z1a的 diff会包含C1到C4的全部变更。所以你的 CI 流水线必须能处理这种“大 diff”构建。我们为此专门优化了 Go 的构建脚本使用-modreadonly和GOCACHE环境变量确保即使 diff 很大也能复用之前编译过的依赖包。3.4 Rebase and Merge 实操在不牺牲调试的前提下获得线性历史第一步这是最需要谨慎的。在feature/export-excel分支下执行git fetch origin git rebase -i origin/mainGit 会打开一个编辑器列出q5p4o3n到w8x9y0z的所有 commit。默认是pick。如果你觉得C2panic fix和C1CSV export逻辑紧密可以把它改成fixup这样C2的变更会被自动合并到C1中不产生独立 commit。最终你可能得到pick q5p4o3n feat(export): add basic CSV export endpoint fixup r6s5t4u fix(export): handle nil pointer panic when no orders found pick v7u8t9s feat(export): add Excel (.xlsx) format support using github.com/tealeg/xlsx pick w8x9y0z test(export): add integration tests for both CSV and Excel exports保存退出后Git 会依次 rebase。过程中如果遇到冲突比如C3修改的文件main也修改了它会暂停让你解决。解决后git add . git rebase --continue。第二步rebase 完成后你的分支变成了z1a2b3c (HEAD - feature/export-excel) test(export): add integration tests for both CSV and Excel exports y0z1a2b feat(export): add Excel (.xlsx) format support using github.com/tealeg/xlsx x9y0z1a feat(export): add basic CSV export endpoint所有 commit 的 hash 都变了但 message 保持不变除了你用reword修改的。第三步强制推送因为历史被重写了git push --force-with-lease origin feature/export-excel--force-with-lease比--force安全得多它会检查远程分支是否被他人更新如果被更新了会拒绝推送避免覆盖他人工作。第四步在 GitHub PR 页面点击 “Rebase and merge”。GitHub 会执行git merge --ff-only将main指针直接指向z1a2b3c。最终main的历史是z1a2b3c (HEAD - main) test(export): add integration tests for both CSV and Excel exports y0z1a2b feat(export): add Excel (.xlsx) format support using github.com/tealeg/xlsx x9y0z1a feat(export): add basic CSV export endpoint a1b2c3d feat(api): add webhook retry mechanism for payment failures e4f5g6h fix(auth): resolve JWT token expiration race condition ...提示这个历史git log --oneline看起来和 Squash 一样干净但git log --oneline --all会展开看到所有分支。更重要的是git blame依然能精准定位到y0z1a2bgit show y0z1a2b依然能看到 Excel 集成的全部上下文。你得到了 Squash 的“形”和 Create Merge Commit 的“神”。4. 常见问题与排查技巧实录那些文档里不会写的血泪教训