Git rebase 冲突解决后如何确认提交内容没丢

Git rebase 成功结束，只能说明 Git 已经把提交重新应用到目标基线上，不能直接证明冲突解决时没有删掉某一段业务改动。最稳妥的做法是给旧尖端留一个引用，再依次核对冲突文件、核心文件差异、reflog 和项目测试。

官方地址：https://git-scm.com/

确认提交内容没丢，不要只看“Successfully rebased”或分支变绿。至少要把 rebase 前后的文件差异看一遍，并用 reflog 保留回退入口，最后再运行项目原有测试。

第1步：先固定 rebase 前的提交边界

先在当前分支的项目窗口打开 Source Control → Changes，确认没有未提交文件；再打开底部的 Terminal 面板执行下面的命令。示例分支名是 feature/profile-cache，请替换成自己的分支。

# 确认工作区没有未处理的修改
git status --short

# 给 rebase 前的分支尖端保留一个可读的本地引用
git branch backup/feature-profile-cache-before-rebase

# 获取目标基线，并确认当前分支名称
git fetch origin
git branch --show-current
git log --oneline --decorate -5

# 将当前分支的提交重新应用到远端主分支
git rebase origin/main

这里的备份分支不是新的功能分支，而是一个不会跟着当前分支移动的参照点。后面执行 git diff backup/feature-profile-cache-before-rebase HEAD 时，比较对象明确得多。若第一条命令已经输出文件，先处理这些修改或使用项目规定的暂存方式，不要在脏工作区上叠加排查。

第2步：在界面和命令行中完成冲突处理

如果 rebase 停在冲突处，在编辑器中按 Source Control → Conflicts 打开对应文件。先阅读冲突两侧的上下文，再选择 Accept Current、Accept Incoming 或手动合并；不要因为按钮方便就整块覆盖。保存文件后，在 Source Control → Changes 中点击文件右侧的 Stage Changes。

# 查看 Git 认为仍未处理的路径
git status

# 确认工作区没有残留冲突标记或空白错误
git diff --check

# 只把已经人工复核过的文件放入暂存区
git add src/profile/cache.go

# 检查即将作为冲突解决结果提交的内容
git diff --cached --check
git diff --cached -- src/profile/cache.go

# 继续当前 rebase；不要把 --skip 当成普通的“下一步”按钮
git rebase --continue

每次 --continue 后都重新看一次 git status。如果还有第二个提交冲突，重复同样的路径；如果编辑器弹出提交信息窗口，保留能说明这次业务改动的消息。只有明确判断某个提交的全部改动都已经由其他提交覆盖时，才考虑 git rebase --skip。

第3步：用 diff 核对重写后的文件内容

rebase 完成后，先在 Source Control → Graph/History 查看新提交链，再回到 Terminal 比较旧尖端和当前尖端。旧尖端是第 1 步创建的备份引用，不依赖 reflog 的序号。

# 先看哪些文件发生了变化，快速发现异常删除或新增
git diff --name-status backup/feature-profile-cache-before-rebase HEAD

# 再看变更规模，判断是否出现整文件替换或意外清空
git diff --stat backup/feature-profile-cache-before-rebase HEAD

# 对核心文件做逐行核对；这里的路径替换为本次功能涉及的文件
git diff backup/feature-profile-cache-before-rebase HEAD -- src/profile/cache.go

# 查看当前分支重写后的提交摘要
git log --oneline --decorate --stat origin/main..HEAD

这个比较会包含目标基线带来的上游变化，所以不要把所有差异都当成自己的提交丢失。重点看三件事：原来新增的函数或配置是否还在，冲突附近的业务分支是否保留，文件数量和行数是否出现无法解释的骤减。需要逐个对比提交时，再用 git log --reverse --stat origin/main..HEAD 按时间顺序检查每个重写后的提交。

第4步：用 reflog 和测试完成最终验收

如果 diff 中出现疑点，打开 Source Control → History 只能看到当前可达历史；这时应使用 Terminal → reflog 找到 rebase 前的旧尖端。reflog 记录的是本地引用移动，不是远端永久备份，因此找到旧哈希后最好立即建立恢复引用。

# 查看当前分支最近的引用移动，定位 rebase start 前的旧尖端
git reflog show --date=local feature/profile-cache

# 用 reflog 输出的旧哈希创建恢复引用，避免后续操作改变位置
git branch backup/feature-profile-cache-reflog OLD_TIP_SHA

# 复查旧尖端的提交摘要和当前尖端的最终提交
git show --stat --oneline backup/feature-profile-cache-reflog
git show --stat --oneline HEAD

# 用项目已有的测试入口做行为验收；请替换为仓库实际命令
make test

# 最后确认工作区干净，提交链指向预期分支
git status --short
git log --oneline --decorate -5

OLD_TIP_SHA 只是说明位置的占位符，实际使用时替换为 reflog 中的完整或足够唯一的提交哈希。测试通过后再执行推送；如果发现内容确实少了，不要继续在新历史上盲改，可以先从 backup/feature-profile-cache-reflog 导出需要恢复的文件，或者和新旧提交逐段比较。

常见问题

rebase 后提交哈希变了，是不是内容一定丢了？

不一定。rebase 会重新生成提交，哈希变化是正常现象。用旧备份引用与新尖端做文件差异，再结合测试判断内容是否保持。

为什么不直接用 ORIG_HEAD 做长期对比？

Git 官方文档说明，后续某些会改写 ORIG_HEAD 的操作可能让它不再指向原分支尖端。自己的备份分支和 reflog 恢复引用更适合持续核对。

冲突解决后可以直接点 rebase --continue 吗？

先暂存已经复核的文件，再看 git diff --cached 和 git diff --cached --check。暂存动作只代表 Git 接受了文件状态，不代表人工选择的业务内容正确。

真正可靠的验收不是某一个绿色提示，而是“旧尖端可回看、差异可解释、提交链完整、测试能通过”。把这四项作为固定清单，下一次遇到 rebase 冲突时就不会只能凭记忆判断。