git不提供重合度数值，但可通过git diff -u0 origin/main...feature/login聚焦真正重叠修改行，结合git merge-base定位共同祖先，并用git log --oneline --graph --left-right main...feature/payment查看分支独有提交以评估重合程度。
怎么快速识别两个分支哪些文件/行真正存在重叠修改
Git 本身不直接提供“代码重合度”数值，但能精准定位git merge或git rebase时实际触发冲突的区域。关键不是看“改了哪些文件”，而是看“哪些变更在相同行区间有交集”。
最实用的命令是：
git diff --cherry-pick --oneline origin/main feature/login
它只列出在feature/login中存在、但在origin/main中**没有等价提交**的改动——也就是真正“新增且未合并”的部分。配合-U0可压缩上下文，聚焦变更行：
git diff -U0 origin/main...feature/login | grep '^+' | grep -v '^\+\+\+' | head -20
常见误判点：
- 仅用
git diff --name-only会漏掉同一文件中“看似不同但实际语义冲突”的情况（比如都改了config.timeout但值不同） - 依赖IDE插件显示的“changed lines”统计，可能包含空行、注释等非实质性修改，误导判断
用rerere自动复用历史冲突解决方案
如果你反复在main和多个feature/*分支间合并，且总在同一个文件的同一段落冲突（比如package.json的dependencies块），rerere能省下大量手动编辑时间。
启用后，Git会在每次解决冲突时悄悄记录“冲突前内容 → 你选的解决结果”映射：
git config --global rerere.enabled true
下次遇到完全相同的冲突（哪怕在不同分支、不同commit hash下），Git会自动应用上次的选择，并标记为已解决：
Auto-merging src/utils.js CONFLICT (content): Merge conflict in src/utils.js Resolved 'src/utils.js' using previous resolution.
注意两个限制：
- 冲突文本必须字节级一致（空格、换行符差异都会导致匹配失败）
- 只对已提交的冲突生效；如果某次你用
git merge --abort退出，该冲突不会被记录
合并前用git merge-base定位最近共同祖先
所谓“重合度高”，本质是两个分支从某个提交之后各自演进的路径短、共同祖先近。直接查git merge-base比肉眼看git log更可靠：
git merge-base main feature/payment
返回的commit hash就是三方合并的基准点。再用：
git log --oneline --graph --left-right main...feature/payment
能清晰看到两边各自独有的提交数——如果某分支独有提交极少，说明它基本只是同步了主线，重合度天然高。
容易被忽略的细节：
-
main...feature/payment（三点）表示“不在两者共同祖先中的所有提交”，而main..feature/payment（两点）只表示feature/payment独有的提交 - 如果
git merge-base返回多个hash，说明存在多条合并路径，此时应加--all确认，避免误判
精简合并策略：用--no-ff + --squash控制提交粒度
当一个功能分支包含15次调试提交，但上线只需一个语义清晰的变更包，强行git merge会污染主线历史。这时--squash比--no-ff更彻底：
git checkout main git merge --squash feature/reporting git commit -m "feat: add daily report export"
它把整个分支的所有改动压成一次暂存区变更，不保留原始提交链。适合：
- 外部贡献者提交（避免引入不可信的提交信息）
- CI验证通过后的一键集成（跳过中间调试痕迹）
- 修复类分支（如
hotfix/*）需保持主线干净
但要注意：--squash后原分支的提交历史就与main彻底断开，后续无法用git cherry-pick精准回溯某次小修——这是为简洁性付出的可追溯代价。
