git中merge后提交历史“重复”是log默认拓扑排序导致的视觉假象，并非真实重复；使用--first-parent可沿主干过滤视图，安全高效；rebase虽得线性历史但破坏上下文且协作风险高；误删merge提交危害极大，应优先用revert撤销。
为什么 merge 后提交历史看起来重复了
这不是 Git 真的重复保存了提交，而是 git log 默认按拓扑顺序展示，把合并提交（merge commit）和它两个父提交都列出来，导致你看到同一组变更“出现两次”。比如 feature 分支上 3 个提交，在 main 上 git merge feature 后，git log 可能显示这 3 个提交 + 1 个 merge 提交，而其中那 3 个在 feature 上的提交，又作为 merge 的第一个父提交被再次展开。
用 --first-parent 快速过滤掉“假重复”
绝大多数时候，你只想看主干（比如 main）上的主线演进，不关心被合并进来的分支细节。这时加 --first-parent 就能只沿第一个父提交（即被合并前的主干）往上追溯：
git log --first-parent main
这个参数会让 git log 忽略 merge 提交的其他父提交（比如来自 feature 的那些），自然就看不到“重复”的提交了。它不改历史，只是视图过滤，安全、即时生效。
- 适合日常查看主干进展、CI/CD 日志分析、生成 changelog
- 不能用于
git rebase或git cherry-pick场景——它们本身不走--first-parent路径 - 如果主干是通过
git merge --no-ff合并的，--first-parent效果最明显；若用了--ff（快进），那就根本没 merge 提交，也不会有“重复”感
rebase 替代 merge 会彻底避免 merge 提交，但代价不小
如果你坚持要线性历史（即所有提交都像一条直线排下来），可以用 git rebase 把 feature 提交“重放”到 main 最新位置上，再 git merge --ff-only。这样没有 merge 提交，自然无“重复”。
但要注意：
- rebase 会改写
feature分支的提交哈希，已推送到远程的分支必须git push --force-with-lease，协作时需提前同步所有人 - 丢失合并上下文：无法从历史中看出“哪几个提交是一次完整功能开发”，对回滚、审计不利
- 如果
feature分支已有多个提交且中间有依赖关系，rebase 过程中冲突可能比 merge 更难解
别碰 git reset --hard + push -f 除非你清楚后果
有人想“删掉 merge 提交”来消除重复，于是执行 git reset --hard HEAD~1 再强制推送。这看似干净，实则危险：
- 它不仅删掉了 merge 提交，还把该 merge 带入的所有变更一并撤回（除非你立刻用
git cherry-pick补回来） - 远程仓库的历史被改写，其他协作者执行
git pull会遇到 diverged 错误，必须手动处理 - CI 记录、PR 关联、代码审查痕迹全部断裂
真正需要清理的，通常是误操作导致的多余 merge（比如反复 merge 同一分支），这时应优先用 git revert -m 1 <merge-commit-hash></merge-commit-hash> 撤销合并，而不是重写历史。
“重复提交历史”本质是视角问题，不是数据污染。选对查看方式（--first-parent）比大动干戈改历史更稳妥，也更符合团队协作的实际约束。
