假设我 fork 某人的 git repo 并提交 A、B、C 和 D。我从那时分叉的 persom 选择了 A 和 C，因此成为 A' 和 C'。他还自己提交 X、Y 和 Z。所以在这一切之后，我的分支有 A B C D，而他的分支有 A' C' X Y Z。假设两个分支都已发布，所以 rebase 不是一个有吸引力的选择。还假设 X Y Z 不与任何 A B C D 冲突。如何以有用的方式合并这两个分支？我应该简单地合并然后手动解决所有问题吗？对于合并头的日志中的重复提交消息，我能做些什么吗？从现在开始，这两个分支是否注定只能通过挑选彼此的提交来同步？
【问题讨论】：
标签： git merge cherry-pick merge-conflict-resolution
直接合并应该可以。 Git 应该注意到相同的更改集，并且不会尝试合并 A/A' 或 C/C'。如果 X、Y 或 Z 触及 A'/C' 更改的相同代码，您可能必须解决那里的冲突，尤其是当 B 或 D 触及相同代码时。
您可以随时git merge --no-commit 并检查结果是否符合您的预期。
【讨论】：
如果没有冲突，直接合并是显而易见的。但是如果有冲突...
您可以先合并他的 C'，此阶段的任何冲突都来自重新应用您自己的更改，如果它们不重要或应用有点乱。如果您的 C 建立在 B 上并且他的 C' 不是一个干净的副本，或者如果 B C D 中的任何一个建立在 A 上，因此重新应用他的 A' 不再是明显的无操作，等等，就会发生这种情况。
您可以跳过详细的冲突调查，直接手动接受您的版本，或者：
git merge --strategy=ours C'
然后合并其余的，更加注意那里的冲突。如果他的 X Y Z 确实不碰 A B C D 的东西，这应该没有冲突。如果他在将 C 合并为 C' 的过程中做了一些奇怪或错误的事情，而你在合并 C' 时将其丢弃，它可能会在这里或未来的任何时间回来咬你。
【讨论】：