你在本地做了两个 commit，队友同时推了三个 commit 到同一分支。你执行 git pull --rebase，遇到冲突，手动解了两次，git rebase --continue 后推送。随后发现 git log --oneline 里出现了奇怪的景象：你的 commit 时间戳比队友的早，但出现在历史更靠后；或者同一个改动出现了两次；又或者 git log --all --graph 里有分叉点出现在意想不到的地方。git pull --rebase 本意是产生线性历史，但解冲突过程中的每一步细节都可能让历史变成一团乱麻。
常见原因
1. 解冲突时误用了 git commit 而非 git rebase --continue
rebase 进行中遇到冲突，解决后执行了 git commit 而不是 git rebase --continue。这产生了一个新的”解冲突 commit”，而不是把改动合并进正在 rebase 的 commit，导致历史里多出一个孤立的”fix conflict”提交。
怎么判断：git log --oneline -10，若有类似「Merge branch ‘main’」或「fix conflict」的无意义 commit，就是这种情况。
2. 多次 git pull --rebase 在同一个冲突点上叠加
同一个文件在多次 pull —rebase 中反复冲突，每次解决的方式稍有不同，导致历史里出现多个”修改同一处代码”的 commit，逻辑上重复但内容细节不同，难以追溯哪次是真正的修改意图。
怎么判断：git log -p -- path/to/conflicted-file | grep '^[+-]' | sort | uniq -d 若有大量重复的增删行，说明同一改动被应用了多次。
3. rebase 过程中混入了 merge commit
本地历史里有一个 git merge 产生的 merge commit，rebase 时 Git 不知道如何处理 merge commit，默认策略是展开 merge commit 的所有 commit 逐一 replay，导致历史顺序打乱，且原本隔离在 feature 分支的改动被平铺到主线历史里。
怎么判断：git log --all --graph --oneline -20 若 rebase 前有分叉节点，rebase 后这些节点消失但 commit 数量增多，说明 merge commit 被展开了。
4. git pull --rebase 与 git config pull.rebase 全局设置冲突
本地 git config --global pull.rebase true 使得所有 git pull 都隐式变成 git pull --rebase，而开发者以为在执行普通 merge pull，不知道在 rebase 过程中。解冲突时按 merge 的逻辑操作，产生错误的历史结构。
怎么判断：git config --global pull.rebase 若输出 true，且操作者不知道这个设置，就是这种情况。
5. rebase 中途执行了 git stash pop 把额外改动混入
rebase 遇到冲突暂停时，手动执行了 git stash pop 把之前暂存的改动也恢复到工作区，解冲突时把 stash 的改动也一起提交进了 rebase 的 commit，导致历史里的 commit 包含了不应该在那个时间点存在的改动。
怎么判断：git diff HEAD~1 HEAD 若包含不属于当前 commit 预期范围的改动，说明有额外内容被混入。
6. 时区或系统时钟错误导致 commit 时间戳异常
rebase 重写 commit 时使用当前系统时间作为新的 committer date（但保留原始的 author date）。若系统时钟错误，committer date 会出现未来时间或过去时间，让 git log --date-order 产生混乱的排序。
怎么判断：git log --format="%H %ai %ci" -5 对比 author date（%ai）和 committer date（%ci），若两者差异超过数小时，说明 rebase 时时钟有问题。
最短修复路径
Step 1：在推送之前用 interactive rebase 清理历史
git tag backup/before-cleanup HEAD
# 查看需要清理的 commit 数量
git log --oneline origin/main..HEAD
# 用 interactive rebase 合并/删除多余 commit
git rebase -i origin/main在编辑器里把多余的「fix conflict」commit 改为 fixup 或 squash，合并进相关的业务 commit。
Step 2：如果历史已经推送，用 reset 退回重来
# 退回到与 origin/main 分叉点
git reset --mixed origin/main
# 重新 stage 并提交，产生干净的 commit
git add -p # 逐块确认需要提交的改动
git commit -m "feat: 干净的提交信息"
# 再次 pull --rebase，这次只有一个 commit 需要 replay
git pull --rebase
git push --force-with-leaseStep 3：中途遇到冲突时的正确操作顺序
# 1. 解决冲突（编辑文件）
# 2. 标记为已解决
git add path/to/resolved-file
# 3. 继续 rebase（不要用 git commit！）
git rebase --continue
# 4. 若某个 commit 的改动完全被吸收，跳过它
git rebase --skip
# 5. 若整个 rebase 需要放弃
git rebase --abortStep 4：修复重复 commit
# 找出重复的 commit（patch-id 相同）
git log --all --oneline | head -20
git cherry -v main HEAD
# cherry 输出中 - 号开头的表示已在 main 中存在，可以删除
git rebase -i main # 把重复的 commit 改为 drop预防建议
- 解冲突后始终用
git rebase --continue，绝不在 rebase 进行中执行git commit或git merge。 - pull 之前先把本地 WIP 打包进一个整洁的 commit，减少 rebase 时的冲突点数量。
- 多人协作的分支上推荐使用
git pull（默认 merge），只在个人 feature 分支上用--rebase，减少共享历史的重写风险。 - 设置
git config --global pull.rebase false把 pull 默认回 merge，避免隐式 rebase 让人不知情。 - 在
git pull --rebase遇到冲突时，先用git status确认哪些文件冲突，解决完后git diff --cached验证 staging 内容再--continue。 - 使用
git rerere（git config --global rerere.enabled true）记录冲突解决方案，相同冲突下次自动应用，减少反复手动解冲突。
常见问答 (FAQ)
Q: git pull --rebase 和 git pull 产生的历史有什么实质区别？
A: git pull 遇到分叉时会产生一个 merge commit，历史是非线性的；git pull --rebase 把本地 commit 移到远端最新之后，历史是线性的。线性历史更易读，但 rebase 会重写 SHA，不适合已推送到共享分支的 commit。
Q: 我同事说历史乱了，能用 git log --simplify-merges 让它看起来更清晰吗？
A: --simplify-merges 只影响显示，不改变实际历史。真正清理历史需要用 git rebase -i 合并多余 commit 或用 filter-repo 重写。git log --first-parent 可以只显示主线历史，屏蔽 merge 分支的细节。
Q: git rerere 是什么，怎么用？
A: rerere（Reuse Recorded Resolution）会记录每次手动解决的冲突，下次遇到相同冲突时自动应用之前的解决方案。启用：git config --global rerere.enabled true。查看记录的解决方案：git rerere diff。
Q: rebase 过程中 --continue 提示 no changes，该用 --skip 还是 --continue？
A: 提示「no changes」时，该 commit 的所有改动已被之前的冲突解决步骤吸收或已在目标分支存在，应该用 --skip 跳过，不要强行 --allow-empty 产生空 commit。
相关阅读
- Rebase 之后 commit 消失了
- Cherry-pick 解冲突后变成空 commit
- Force push 覆盖了队友的 commit
- 二进制文件合并冲突 — 手动无法 resolve
- AI 帮你解决合并冲突
- AI 意外修改了 Git 历史
标签: #git #version-control #排查