当前位置：首页 > news >正文

Git merge 实操指南：从 fast-forward 到 three-way merge 的工程真相

news 2026/7/6 10:29:20

1. 这不是教科书里的合并，而是我每天在终端里敲出来的真活儿

Git merge 是我过去十年带团队、做交付、救火排障时用得最频繁、也最容易翻车的操作。它表面看只是把两个分支“合在一起”，但背后牵扯的是代码演进路径的逻辑一致性、协作节奏的隐性契约、以及你对项目历史真实状态的理解深度。很多人学 merge 只记git merge feature这一行命令，结果一到线上环境就遇到冲突无法解决、合并后功能异常、甚至误删他人提交——这些都不是 Git 的错，而是我们没真正理解 merge 在工程实践中的角色：它既是协作的终点，也是问题暴露的起点。

核心关键词Git merge、fast-forward merge、three-way merge、merge conflict、git rebase vs merge全部指向一个现实：你不是在操作文件，而是在编辑一段可追溯、可验证、可回滚的协作历史。这篇内容适合三类人：刚从 SVN 或 SVN-like 工具转过来、对“分支即快照”还没建立直觉的开发者；能写代码但一看到冲突提示就手抖、靠git push --force硬扛的新晋 Tech Lead；还有那些天天 review PR 却说不清“为什么这个 PR 要 rebase 不要 merge”的资深工程师。它不讲抽象原理，只讲我在 7 个不同技术栈（Java/Go/Python/JS/Rust/TypeScript/C++）、23 个中大型项目、400+ 次正式发布中反复验证过的 merge 实操逻辑。下面所有步骤、参数、判断依据，都来自真实日志、CI 失败记录和凌晨三点的紧急 rollback 操作。

2. 合并不是“把代码拼起来”，而是重演一次协作决策过程

2.1 为什么不能只学命令？因为 merge 的本质是“历史重构”

很多教程一上来就教git merge dev，却从不解释：Git 并没有真的“把 dev 分支的代码复制到 main”。它做的是基于共同祖先的差异重演。举个生活化例子：你和同事各自在一张白纸上画流程图，你先画了“用户登录 → 验证 token”，他后画了“验证 token → 查询数据库”。你们的起始点（白纸空白）就是 common ancestor。merge 不是把两张纸贴一起，而是让 Git 找出“谁在哪个节点加了什么”，再按逻辑顺序重新绘制一张新图。这个“重绘”过程，就是 merge 的全部意义。

所以，merge 的第一层设计逻辑，是必须识别出三个关键 commit：

O（Origin）：两个分支的最近共同祖先（lowest common ancestor）
A（Current）：当前所在分支的最新 commit（比如 main 的 HEAD）
B（Incoming）：待合并分支的最新 commit（比如 feature/login 的 HEAD）

Git 的所有 merge 策略，都是围绕这三个点如何计算差异展开的。这直接决定了你看到的是 fast-forward（无冲突、线性推进），还是 three-way merge（需人工介入、生成新 commit），甚至是 octopus merge（多分支同时合并，CI 流水线里常见）。

提示：你可以随时用git merge-base A B手动查出 O。例如git merge-base main feature/login会返回一个 commit hash。这不是理论，而是我在排查“为什么这个 PR 显示修改了 200 行，实际只改了 3 行”时必做的第一步——确认共同祖先是否被意外移动。

2.2 Fast-forward merge：看似省事，实则埋雷最多

Fast-forward（简称 FF）是 Git 默认行为，当目标分支（如 main）没有任何新提交，而当前分支（如 feature）是从 main 直接衍生出来时触发。此时 Git 不生成新 commit，只是把 main 的指针“快进”到 feature 的 HEAD。

表面上看很干净：

main: A — B — C ↑ feature: A — B — C — D — E

执行git checkout main && git merge feature后变成：

main: A — B — C — D — E ↑ feature: A — B — C — D — E

但问题在于：FF 合并抹去了“这是一个独立功能开发周期”的元信息。D 和 E 原本属于 feature 分支的上下文（比如有对应的 Jira ticket、设计文档链接、测试覆盖率报告），一旦 FF 进 main，它们就失去了分支归属，变成 main 历史中“凭空出现”的两笔提交。后果很现实：

Code Review 时无法关联 PR 上的讨论记录；
回滚时不能一键撤回整个 feature（因为没 merge commit 作为锚点）；
新成员看 git log，分不清哪些提交是修复 bug，哪些是新增功能。

我在一个支付网关项目吃过亏：FF 合并了风控规则模块后，线上突然出现误判，需要紧急回滚。但git revert <E>只撤销 E，D 里的核心校验逻辑还在，系统依然异常。最后只能git revert <D> <E>两次，而如果当时是普通 merge，一个git revert <merge-commit-hash>就搞定。

所以我的实操原则是：除非是临时调试分支或个人本地实验，否则禁用 FF 合并。强制生成 merge commit，保留上下文完整性。

2.3 Three-way merge：真正的协作现场，也是冲突高发区

当 main 分支在 feature 开发期间也有新提交时（比如其他人在修 bug），Git 必须启用 three-way merge：

main: A — B — C — F — G ↑ feature: A — B — C — D — E

此时 O = C，A = G，B = E。Git 会分别计算：

G - C：main 自 C 之后的变更（F、G）
E - C：feature 自 C 之后的变更（D、E）

然后尝试将这两组变更“叠加”到 C 的基础上。如果同一行代码在 F/G 和 D/E 中都被修改，冲突就产生了。

这里的关键认知是：冲突不是代码写错了，而是 Git 发现“人类协作意图存在歧义”。比如：

你在 D 中把if (user.age > 18)改成if (user.age >= 18)（支持 18 岁生日当天认证）；
同事在 F 中把同一行改成if (user.age > 16)（针对青少年版产品）；
Git 无法判断该取 16、18 还是 >=18，它把选择权交还给你。

这就是为什么 merge 冲突必须人工解决——它本质是跨团队的语义对齐会议，只不过开在终端里。

2.4 Octopus merge：CI/CD 流水线里的隐藏主力

当一次git merge同时指定多个分支时（如git merge release/v1.2 hotfix/db-timeout feature/i18n），Git 会执行 octopus merge。它不生成单个 merge commit，而是创建一个拥有多个 parent 的 commit：

H — I — J / \ A — B — C — D — E — F — G \ / K — L — M

其中 G 的 parent 是 F、J、M。这种结构在自动化发布场景极常见：比如 nightly build 脚本需要把当天所有通过测试的 feature、hotfix、release 分支一次性集成到 staging 分支。

但 octopus merge 的坑在于：只要任意一个分支引入冲突，整个合并就失败。而且git status不会清晰告诉你冲突来自哪个分支。我在一个微服务集群项目里，因一个被遗忘的文档分支（docs/update-api-spec）含有一处 README 冲突，导致整条 release 流水线卡住 47 分钟，直到手动拆解git merge --no-commit逐一分支测试才定位。

所以我的经验是：octopus merge 只用于 CI 脚本，且必须配合--no-commit --no-ff参数，确保失败时能精准回退，而不是留下半成品工作区。

3. 核心细节解析：从命令参数到工程决策的每一处深意

3.1`--no-ff`：不是可选项，而是协作契约的签名栏

git merge --no-ff feature强制 Git 生成 merge commit，即使满足 FF 条件。这个参数的价值远超“让 git log 看起来整齐”。

它在工程层面做了三件事：

创建可追踪的边界：每个 merge commit 都自带Merge: <main-head> <feature-head>，你用git show <merge-hash>就能立刻看到这次合并涉及哪两个分支的全部变更。
支持原子回滚：git revert -m 1 <merge-hash>（-m 1 指定第一个 parent 为“主干”）可一键撤销整个 feature，不会误伤其他并行开发。
暴露集成风险点：如果某次 merge commit 后 CI 失败，你知道问题一定出在该 merge 引入的代码范围内，而非更早的历史。

我在一个金融风控项目中，把--no-ff写进了团队.gitconfig的 alias：

[alias] mff = merge --no-ff --edit

--edit强制打开编辑器让你填写 merge message。这不是形式主义——一条好的 merge message 应包含：

关联的 issue ID（如FIN-1234）
本次合并解决的核心问题（如 “修复 token 过期后重复扣款”）
关键变更摘要（如 “修改 PaymentService.validate() 的幂等校验逻辑”）

这样，三年后审计时，git log --grep="FIN-1234"就能串起从需求提出、开发、测试到上线的完整证据链。

3.2`--squash`：当“功能原子性”比“开发过程”更重要时

git merge --squash feature不是真正的 merge，而是把 feature 分支的所有变更“压缩”成工作区的未暂存修改，然后由你手动git add && git commit。它生成的 commit 只有一个 parent（当前分支 HEAD），彻底切断与原分支的拓扑关系。

适用场景非常明确：

你接收了一个外部贡献者（非团队成员）的 PR，其 commit 历史混乱（如 “fix typo”、“oops revert”、“final final”），但代码质量过关；
你正在做一次性数据迁移脚本，不需要保留中间调试 commit；
你参与开源项目，维护者要求“单 commit 提交”。

但必须警惕：--squash会丢失所有原始 commit 的 author 信息（author 会变成执行 merge 的人）。如果你需要保留贡献者署名，必须用git commit --author="Name <email>"手动指定。

我在一个政府项目中用过--squash：供应商交付的硬件驱动适配代码，commit 记录全是中文乱码和无意义描述。我用git merge --squash driver-v2.1拉取全部变更，然后git commit -m "feat(driver): add support for Model X sensor (vendor: ABC Corp)"，既保证了代码可用，又让主干历史保持专业可读。

3.3`--abort`和`--continue`：冲突处理的“安全气囊”与“重启键”

当 merge 冲突发生时，Git 会停在中间状态（unmerged paths）。此时git status显示：

Unmerged paths: (use "git add <file>..." to mark resolution) both modified: src/auth/service.ts

很多人直接git add冲突文件就git commit，这是危险操作。正确流程是：

先git merge --abort：彻底退出 merge 状态，回到合并前。这是你的“后悔药”，任何时候都可以吃。我把它设为 shell 别名gmab（git merge abort），手指肌肉记忆已形成。
检查冲突根源：用git log --oneline --graph --all看分支拓扑，确认是否真有必要合并（有时发现 feature 分支其实已过时）。
手动解决或借助工具：VS Code 内置的 merge editor、git mergetool（配置 vimdiff/kdiff3）比纯命令行高效十倍。
验证后再git merge --continue：只有git add所有冲突文件后，--continue才允许执行。它会自动生成 merge commit。

注意：git merge --continue不接受任何参数，也不能跳过git add。这是 Git 的硬性保护机制——它强制你确认“所有冲突都已人工审查”，而非靠脚本蒙混过关。

3.4`--allow-unrelated-histories`：跨仓库整合的“破冰协议”

当两个仓库完全没有共同祖先时（比如把旧 SVN 迁移的代码库合并到新 Git 仓库），git merge默认拒绝。--allow-unrelated-histories解除这一限制。

但这不是“随便合”的许可证。它意味着：

你必须手动确认两个历史的业务语义是否兼容（比如旧库用 MD5 校验，新库用 SHA256，合并后加密模块会冲突）；
合并后首次构建极可能失败，因为路径、依赖、配置格式全不同；
所有后续 merge 都将以这次“破冰 commit”为共同祖先，影响深远。

我在一个 IoT 平台项目中用过它：把设备端固件仓库（C 语言，Makefile 构建）和云端管理后台（Node.js，Webpack 构建）合并到统一 monorepo。执行前我做了三件事：

用git filter-repo清洗旧仓库，把所有文件移到firmware/子目录；
在新仓库根目录创建cloud/目录，放入后台代码；
git merge --allow-unrelated-histories --no-ff firmware-import，并写明 message：“INIT: integrate legacy firmware repo (v1.0–v3.2) under /firmware, no shared code logic”。

这次合并花了两天，但换来的是后续所有跨端功能（如 OTA 升级协议同步）能在单一 PR 中完成，review 效率提升 40%。

4. 实操过程：从分支准备到线上验证的完整闭环

4.1 合并前的五项必检清单（我用 Shell 脚本自动执行）

在执行任何 merge 命令前，我运行一个叫pre-merge-check.sh的脚本，它检查以下五项，缺一不可：

检查项	命令示例	为什么重要	我的实操案例
1. 当前分支是否受保护	`git config --get branch.main.protect`	防止误操作 main 分支	曾因 alias`gm='git merge'`手滑在 main 上执行，触发 pre-commit hook 阻断
2. 待合并分支是否通过 CI	`curl -s "https://ci.example.com/api/v1/jobs?branch=feature/login" \| jq '.status == "success"'`	避免带 bug 的代码进入主干	一个未跑通 e2e 测试的 login 分支，合并后导致 SSO 登录成功率下降 12%
3. 本地与远程是否一致	`git fetch && [[ $(git rev-parse main) == $(git rev-parse origin/main) ]]`	防止基于过期历史合并	团队成员 A 推送 hotfix 后，B 未 fetch 就 merge，导致 hotfix 被覆盖
4. 是否存在未提交变更	`git status --porcelain \| grep -q '^??' && echo "UNTRACKED" \| exit 1`	避免 untracked 文件干扰 merge	本地 .env 文件被误加入，合并后泄露测试数据库密码
5. 共同祖先是否合理	`git merge-base main feature/login \| xargs git show -s --format='%ar %s'`	确认分支基线不过于陈旧	发现 feature 分支基于 3 个月前的 main，需先 rebase

这个脚本已集成到公司 pre-commit hook，任何 merge 操作前自动触发。它不阻止你工作，但强迫你面对事实。

4.2 标准合并流程：以 feature 分支为例的逐帧拆解

假设你要将feature/payment-methods合并到main，以下是我在生产环境执行的精确步骤（含时间戳和输出示例）：

Step 1：更新本地 main 并确认状态

$ git checkout main Switched to branch 'main' $ git pull origin main From github.com:org/project * branch main -> FETCH_HEAD Updating a1b2c3d..f4e5g6h Fast-forward README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean

实操心得：git pull后必须git status确认 “nothing to commit”。我见过太多人pull后看到 “Already up to date” 就以为万事大吉，其实本地有未 push 的提交，导致后续 merge 出现诡异的 diverged history。

Step 2：执行带保护的 merge

$ git merge --no-ff --edit feature/payment-methods Auto-merging src/payment/processor.ts CONFLICT (content): Merge conflict in src/payment/processor.ts Automatic merge failed; fix conflicts and then commit the result.

注意：这里 Git 没有报错，而是明确告诉你 “Automatic merge failed”，这是正常流程的开始，不是异常。

Step 3：用 VS Code 解决冲突

打开src/payment/processor.ts，VS Code 显示三栏视图：Current（main）、Incoming（feature）、Merged（结果）；
在processPayment()方法中，main 分支添加了logger.info("payment started")，feature 分支添加了validateCardNumber(card)；
我选择保留两者，并在 validate 后加一行logger.debug("card validated")；
保存文件，VS Code 自动标记为 resolved。

实操心得：永远不要在冲突文件里手动删掉<<<<<<< HEAD这些标记后直接git add。VS Code 的 merge editor 会帮你清理标记并高亮变更，错误率降低 90%。

Step 4：验证、测试、提交

$ git add src/payment/processor.ts $ npm test # 运行单元测试 PASS src/payment/processor.test.ts processPayment ✓ should reject invalid card number (3 ms) ✓ should accept valid card number (2 ms) $ npm run build # 确保能编译 $ git commit # 此时打开编辑器，填写标准 message

Message 示例：

feat(payment): add support for Apple Pay and Google Pay - Integrate Apple Pay SDK v5.2.1 (see docs/apple-pay.md) - Add Google Pay button component with fallback to credit card form - Refactor payment processor to support multiple gateways (Stripe, Adyen) Closes FIN-5678, FIN-5679

Step 5：推送并触发 CI

$ git push origin main Enumerating objects: 12, done. Counting objects: 100% (12/12), done. Delta compression using up to 8 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1.23 KiB | 420.00 KiB/s, done. Total 7 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 5 local objects. To github.com:org/project.git f4e5g6h..a7b8c9d main -> main

关键观察：推送后，CI 流水线（GitHub Actions）自动启动，运行 lint、test、build、e2e 全流程。只有全部通过，这次 merge 才算真正完成。

4.3 线上验证的黄金三分钟：合并后必须做的三件事

合并推送到远程后，别急着去喝咖啡。接下来三分钟决定这次合并是否成功：

检查 CI 状态页：不是看 “✅ passed”，而是点开每个 job，确认：
- test:e2e是否覆盖了新功能路径（如 Apple Pay 支付流程）；
- build:prod输出的 bundle size 是否合理（增长超过 10% 需警惕）；
- security:scan无 critical 漏洞（尤其新引入的 SDK）。
在 staging 环境手动验证核心路径：
- 用测试账号走一遍新功能全流程（如：选 Apple Pay → 输入测试卡号 → 查看订单确认页）；
- 检查浏览器 console 无 JS error，Network tab 无 5xx 请求；
- 对比合并前后 performance metrics（Lighthouse 报告）。
通知相关方：
- Slack 频道#dev-announcements发消息：“mainmerged FIN-5678: Apple Pay support ✅. Staging verified. Next deploy window: tomorrow 10AM CST.”；
- 给 QA 团队发邮件，附测试用例链接和已知限制（如 “Google Pay 仅支持 Chrome 90+”）。

我在一个电商项目中，因跳过第 2 步，导致 Apple Pay 的回调 URL 配置错误（本地测试用 http，staging 用 https），线上用户点击支付按钮后白屏。修复只花 2 分钟，但客服收到 37 个投诉电话。

5. 常见问题与排查技巧实录：那些凌晨三点教会我的事

5.1 “Already up to date” 却明明有新代码？—— 你可能 merge 错了分支

现象：

$ git checkout main $ git merge feature/login Already up to date.

但feature/login明明有新提交，且git log feature/login显示比 main 更新。

根因分析：
Git 认为feature/login已经是main的祖先（ancestor），即main的 HEAD 可以通过一系列 parent 指针到达feature/login的 HEAD。这通常发生在：

你之前用git cherry-pick把 feature 的某些 commit 移到了 main；
或有人git merge --squash feature/login后又git push，但没删掉 feature 分支。

排查命令：

# 查看 main 是否包含 feature/login 的所有 commit $ git merge-base --is-ancestor feature/login main && echo "YES" || echo "NO" NO # 说明 feature/login 不是 main 的祖先 # 查看两个分支的拓扑关系 $ git log --oneline --graph --all --simplify-by-decoration * a1b2c3d (HEAD -> main) Merge branch 'hotfix/db-timeout' |\ | * d4e5f6g (hotfix/db-timeout) fix: increase db timeout to 30s * | f7g8h9i (origin/main) docs: update deployment guide |/ * j0k1l2m (feature/login) feat: add biometric login

看到j0k1l2m在f7g8h9i下方，说明它不在 main 历史中，但git merge仍报 “Already up to date”？那一定是feature/login被 rebase 过，commit hash 已变。

解决方案：

# 强制 merge（忽略祖先检查） $ git merge --no-ff --allow-unrelated-histories feature/login # 或更安全的做法：rebase feature 到最新 main，再 merge $ git checkout feature/login $ git rebase main $ git checkout main $ git merge --no-ff feature/login

5.2 冲突文件里全是`<<<<<<< HEAD`，但`git status`显示 “not in a merge”？

现象：
手动编辑了冲突文件，删掉了所有<<<<<<<标记，保存后git status却显示：

On branch main nothing to commit, working tree clean

但文件内容明显不对（比如少了一段逻辑）。

根因：
你执行了git merge --abort，但没意识到git merge --abort只重置 index 和 HEAD，不重置工作区文件。那些冲突标记虽被你删了，但文件内容仍是 merge 前的状态，Git 认为“你已解决冲突”，所以status显示 clean。

验证方法：

$ git ls-files -u # 查看未合并的文件 100644 1234567... 1 src/auth/service.ts 100644 abcdefg... 2 src/auth/service.ts 100644 7890123... 3 src/auth/service.ts

如果有输出，说明 Git 仍认为文件处于未合并状态，只是你没git add。

正确做法：

# 1. 先恢复工作区到 merge 前状态 $ git checkout --ours src/auth/service.ts # 取 main 版本 # 或 $ git checkout --theirs src/auth/service.ts # 取 feature 版本 # 2. 再手动合并逻辑，保存 # 3. git add && git commit

5.3`git revert -m 1 <merge-hash>`后，为什么部分代码没撤销？

现象：
执行git revert -m 1 abc123（abc123 是 merge commit hash）后，git show abc123显示的变更没完全消失。

根因：
-m 1指定第一个 parent（通常是 main）为“主干”，Git 会计算 “main 的状态” 减去 “merge 引入的变更”。但如果在 revert 之后，main 分支又有新提交修改了同一文件，那么git revert产生的 patch 就可能因上下文变化而应用失败（hunk failure）。

排查命令：

# 查看 revert commit 的 diff $ git show HEAD # 如果看到 “Revert "Merge branch 'feature/login'"”，但 diff 很小，说明 patch 应用不完整 # 检查是否有 hunk failure $ git status # 如果显示 “unmerged paths”，说明 revert 过程中出现了冲突

终极方案：

# 1. 创建临时分支备份当前状态 $ git checkout -b revert-backup # 2. 重置 main 到 merge 前 $ git reset --hard <merge-base-commit> # 3. 强制推送（仅限私有分支或团队共识） $ git push --force-with-lease origin main

注意：--force-with-lease比--force安全，它会检查远程分支是否被他人更新，避免覆盖他人工作。

5.4 合并后 CI 失败，但本地`npm test`通过？—— 环境差异陷阱

现象：
本地npm test全绿，push 后 CI 报TypeError: Cannot read property 'then' of undefined，失败点正是刚合并的src/payment/processor.ts。

根因：
CI 环境和本地环境的 Node.js 版本、npm 包版本、甚至时区设置不同。最常见的是：

本地用 Node.js 18，CI 用 Node.js 16，而新代码用了Promise.withResolvers()（Node 17+）；
package-lock.json未提交，CI 安装了不同 minor 版本的依赖；
测试用例依赖系统时间，CI 服务器时区是 UTC，本地是 CST。

排查清单：

检查 CI 日志中的 Node/npm 版本：node -v && npm -v；
对比package-lock.json：git diff origin/main -- package-lock.json，确认是否引入了新依赖或版本漂移；

在本地模拟 CI 环境：

# 用 nvm 切换到 CI 版本 $ nvm use 16.18.0 # 清理 node_modules 和 lockfile $ rm -rf node_modules package-lock.json # 重新安装（模拟 CI 的纯净环境） $ npm ci # 再运行测试 $ npm test

预防措施：

在package.json中锁定"engines": {"node": "16.18.0"}，CI 脚本加nvm install；
所有测试用jest.useFakeTimers()避免时间依赖；
package-lock.json必须提交，且禁止npm install（只用npm ci）。

6. 合并策略选择指南：什么时候该 merge，什么时候该 rebase？

6.1 不是“merge vs rebase”二选一，而是“公开历史”与“私有历史”的治理边界

很多教程把 merge 和 rebase 对立起来，这是误导。真实世界中，它们服务于不同目的：

场景	推荐操作	为什么	我的团队规范
向公共分支（main/staging）集成	`git merge --no-ff`	保留协作上下文，支持审计与回滚	所有 PR 必须用 merge，CI 拒绝 rebase 后的 force-push
功能分支开发中整理提交历史	`git rebase -i main`	把 “fix typo”、“debug log” 等临时提交压缩成逻辑清晰的 commit	开发者可在 feature 分支上自由 rebase，但合并前必须`git push --force-with-lease`
修复已推送的 commit（如误传密钥）	`git rebase -i HEAD~3`+`git push --force-with-lease`	避免污染公共历史	仅限本人分支，且必须在 1 小时内完成，超时需走 hotfix 流程
将多个小功能合并为一个发布单元	`git merge --squash feature-a feature-b`	生成单 commit，简化发布 notes	Release 分支上使用，message 必须包含所有关联 issue

关键认知：rebase 是重写历史的手术刀，merge 是记录历史的钢笔。手术刀只能在自己没切开的皮肤上用（私有分支），钢笔则用于签署所有公开契约（公共分支）。

6.2 一个反直觉但救命的实践：永远不要在 feature 分支上`git merge main`

听起来违反直觉？但这是我在 12 个团队推行后故障率下降 63% 的铁律。

为什么禁止？

git merge main会在 feature 分支上生成一个 merge commit，把 main 的历史“拉进来”；
当你最终git merge feature到 main 时，Git 会看到两个分支都有 main 的提交，可能触发不必要的 three-way merge，甚至产生循环依赖；
更严重的是，它破坏了 “feature 分支只包含该功能变更” 的契约，让git log feature失去可读性。

正确替代方案：

git rebase main：把 feature 的提交“重放”到最新 main 之上，保持线性历史；
git pull --rebase origin main：等价于git fetch && git rebase origin/main，更安全；
git merge --ff-only main：只允许 fast-forward，如果失败说明 main 有新提交，此时再 rebase。

我在一个医疗 SaaS 项目中强制执行此规则后，git log --oneline feature/diagnosis-report从平均 42 行（含 8 个 merge commit）降到 5 行（纯功能提交），Code Review 时间缩短 35%。

6.3 合并窗口管理：让团队节奏不再被“最后一刻 PR”打乱

大型项目常有“周五下午 5 点狂 push”现象，导致 merge 冲突集中爆发。我的解决方案是设立合并窗口（Merge Window）：

每周一至周四 10:00–16:00：开放 merge，CI 优先级最高；
周四 16:00 后至周一 10:00：冻结合并，只允许 hotfix（需 Tech Lead 审批）；
周五 12:00 前：所有本周计划上线的 PR 必须 merge，否则顺延至下周。

配套工具：

GitHub Action 自动检测 PR 创建时间，非窗口期创建的 PR 添加标签awaiting-merge-window；
Slack bot 每日 9:55 提醒：“Merge window opens in 5 minutes. Last chance to approve pending PRs!”；
pre-merge-check.sh新增检查：date -d "now" +%u（星期几）和date -d "now" +%H（小时），非窗口期直接拒绝。

效果：团队平均 merge 冲突数从每周 17 次降至 2.3 次，发布成功率从 82% 提升至 99.4%。