Git merge 后代码无法运行，如何直接用当前 branch 的代码替换？

2026-11-04排障赵师傅

可以从目标分支的最新提交新建分支，将当前正确 commit 的完整文件快照恢复到新分支，再提交一次。这样无需自动合并文件，就能得到一个基于目标分支、只包含一个新 commit 的 PR。

这样做会撤销目标分支中未包含在当前快照里的改动，包括其他人新增的文件或修复。目标分支的历史会保留，但这些改动的效果会被新提交覆盖。

为什么 merge 会影响没有修改过的文件？

普通 merge 会参考共同祖先和双方分支的变化。即使你没有修改某个文件，目标分支对它的修改也可能进入合并结果。Git 能处理文本差异，却不能判断合并后的业务逻辑是否正确。Git merge 文档

仅凭描述，还无法确定代码位置变化的具体原因，也不能断定 Git 出了错误。如果已经确认当前 commit 的文件快照正确，可以直接用它创建新提交，省去逐个处理旧提交和冲突的过程。

操作步骤：用正确快照创建一个新提交

以下操作假设：

当前正确代码所在分支为 feature。
目标分支为远程的 origin/main。
新建的 PR 分支为 replace-main。
使用普通完整检出；如果启用了 sparse checkout，应先恢复完整检出。

将示例名称替换成实际名称，在仓库根目录执行。每一步成功后再继续。

1. 确认并备份正确的 commit

先检查仓库状态：

git status

如果仍处于失败的 merge 或 rebase 中，先保存需要保留的手工修改，再根据实际状态选择一条命令退出：

# 仅在 merge 尚未结束时执行
git merge --abort

# 仅在 rebase 尚未结束时执行
git rebase --abort

回到正确分支，确认最新 commit 就是需要保留的版本：

git switch feature
git status
git log -1 --oneline

如果正确代码还包含未提交的修改，先检查并提交。备份分支只保存 commit，不会保存未提交的修改或未跟踪的文件。

确认工作区干净后，创建备份引用：

git branch backup/feature-good HEAD

如果该名称已经存在，换一个新的备份名称，不要覆盖旧备份。

2. 从最新目标分支创建 PR 分支

git fetch origin
git switch -c replace-main origin/main

此时，replace-main 以刚获取的 origin/main 为起点，完整保留目标分支的已有历史。

3. 用备份快照替换全部已跟踪内容

git restore --source=backup/feature-good --staged --worktree -- :/

这条命令将源快照恢复到暂存区和工作区。:/ 表示整个仓库。目标分支中已跟踪、但源快照中不存在的文件也会被删除，因此不会留下目标分支独有的已跟踪文件。Git restore 文档

这一步会覆盖未提交的已跟踪修改，所以执行前要确保工作区干净。未跟踪文件和被忽略文件不属于 commit 快照，这条命令不能用来清理构建产物或本地配置。

4. 检查替换范围并验证快照

先审查即将提交的变化，尤其是文件删除和对其他人改动的撤销：

git diff --cached --stat
git diff --cached

再比较暂存区与正确快照：

git diff --cached --exit-code backup/feature-good --

正常情况下，这条命令应无输出并返回 0，表示暂存区与源提交没有差异。如果出现差异或报错，先查明并处理原因，再继续提交。Git diff 文档

随后执行项目实际使用的构建和测试。如果使用子模块，还需要按项目流程同步子模块工作区；主仓库的快照记录的是子模块 commit 引用。

5. 创建单个 commit 并提交 PR

确认替换范围和运行结果后，执行：

git commit -m "Replace tracked content with verified feature snapshot"
git diff --exit-code backup/feature-good HEAD --
git push -u origin replace-main

第二条命令用于在提交后再次核对最终快照，确认通过后再执行推送。将 replace-main 的 PR 目标设为 main，并在 PR 说明中写明：这次提交会将仓库内容恢复为指定快照，其中包含对目标分支部分改动的撤销。

git restore 已经更新了暂存区，因此不需要再执行 git add .。避免额外添加文件，也能减少将本地产物误带入提交的机会。

这是否满足 rebase 和 squash 的要求？

如果公司的要求是“基于最新目标分支，只保留一个业务提交”，创建时的结果已经满足：新 commit 的父提交就是刚获取的 origin/main，此前多个 feature commit 的最终内容集中在这一次提交中。

如果流程还要求执行特定操作或通过平台检查，仍需按团队规则处理。这种方法不能保证自动通过所有检查。

如果 PR 合入前 main 又有了新提交，最终结果可能再次变化，需要重新审查最新目标分支的改动。如果仍决定完整替换，可以从最新 origin/main 另建分支，重复恢复和验证步骤。只执行一次普通 rebase，不能保证文件快照仍与备份一致。

为什么不用 `-X ours`、`-s ours` 或强推？

git merge -X ours 只在冲突片段上偏向当前一方，对方没有冲突的改动仍会进入结果，因此无法保证完整保留当前快照。

git merge -s ours 会忽略另一方的文件内容，保留执行命令时所在分支的快照，而且通常会产生 merge commit。这与需要的单个普通提交不同，操作方向弄反时也容易保留错误版本。Git merge 策略说明

将目标分支 reset 到 feature 后再强推，会移动共享分支的历史，绕开正常 PR 流程。当前需求通过新增一个替换提交就能完成，无需重写目标分支历史。