Git rebase疑问：基于与共同祖先同状态分支为何仍冲突？

冲突出现的核心原因 #

1. cherry-pick提交带来的重复修改 #

你提到master的维护提交偶尔会cherry-pick到new分支，这就导致new分支里存在和master后续提交内容重叠的修改。当你把new rebase到共同祖先时，Git会把new的所有提交（包括这些cherry-pick来的）重新往共同祖先上应用，但这些修改原本就来自master在共同祖先之后的变更，Git检测到内容重复，自然会触发冲突。

2. --rebase-merges参数的影响 #

使用--rebase-merges会保留new分支里的合并提交结构，这意味着rebase时不仅要处理单个提交，还要重新执行合并操作。如果合并提交涉及的分支本身就有和共同祖先重叠的修改，或者之前合并时的冲突解决逻辑Git无法自动复用，就会再次出现冲突。

关于历史记录的担忧 #

只要冲突解决时逻辑清晰，不会破坏历史依赖的追溯性。反而--rebase-merges保留了PR合并的结构，比普通rebase更能保留上下文，方便后续查阅历史。

可落地的解决方法 #

• 清理new分支里的cherry-pick提交：先用git log --cherry-mark --right-only master...new找出new里来自master的cherry-pick提交，再用git rebase -i把这些提交从new的历史中删掉，之后再做rebase，能避免大部分重复修改的冲突。
• 批量处理冲突：如果冲突都是cherry-pick导致的重复内容，rebase时可以加参数批量解决：git rebase master -X theirs（保留new分支的修改）或者git rebase master -X ours（保留master的修改），减少手动解决的工作量。
• 换用merge替代rebase：如果rebase冲突成本太高，直接把master合并到new分支，解决冲突后再合并回master。虽然多了一个合并提交，但历史记录更直观，不用重写new分支的提交历史。

内容的提问来源于stack exchange，提问作者ajc