当有人从我的 git 提交中挑选并做出自己的提交时，我该如何合并？
假设我 fork 某人的 git repo 并提交 A、B、C 和 D。我从那时 fork 出来的人挑选了 A 和 C，因此成为 A' 和 C'。他还做出了自己的 X、Y 和 Z 提交。所以在这之后，我的分支有 ABCD，他的分支有 A' C' XY Z。假设两个分支都已发布，所以 rebase 不是一个有吸引力的选择。还假设 XYZ 不与 ABC D 中的任何一个冲突。如何以有用的方式合并这两个分支？我应该简单地合并然后手动解决所有问题吗？对于合并头日志中的重复提交消息，我能做些什么吗？从现在开始，这两个分支是否注定只能通过挑选彼此的提交来同步？
Suppose I fork someone's git repo and make commits A, B, C, and D. The persom who I forked from then cherry-picks A and C, which therefore become A' and C'. He also makes commits X, Y, and Z of his own. So after all this, my branch has A B C D, and his has A' C' X Y Z. Assume that both branches are published, so rebase is not an attractive option. Also assume that X Y Z don't conflict with any of A B C D. How do I merge these two branches in a useful way? Should I simply merge and then manually resolve everything? Is there anything I can do about duplicate commit messages in the log of the merged head? Are these two branches doomed to sync only by cherry-picking each other's commits from now on?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
直接合并应该可以。 Git 应该注意到相同的更改集，并且不会尝试合并 A/A' 或 C/C'。如果 X、Y 或 Z 接触了 A'/C' 更改的相同代码，您可能必须解决那里的冲突，特别是如果 B 或 D 接触了相同的代码。
您始终可以 git merge --no-commit 并检查结果以查看是否符合您的预期。
A straight merge should work. Git should notice the identical change sets and will not attempt to merge A/A' or C/C'. If X, Y, or Z touched the same code that A'/C' changed, you may have to resolve conflicts there, especially if B or D touched the same code.
You can always
git merge --no-commitand inspect the result to see if it's what you expected.如果没有冲突，直接合并是显而易见的。不过，如果存在冲突...
您可以先合并他的 C'，此阶段的任何冲突都来自于重新应用您自己的更改（如果它们不平凡或因为它们的应用有点无序）。如果你的 C 在 B 上构建，而他的 C' 不是干净的副本，或者如果任何 BCD 在 A 上构建，则重新应用他的 A' 不再是明显的无操作，等等，都会发生这种情况。
您可以跳过详细的冲突调查，然后只需手动接受您的版本或：
git merge --strategy=ours C'然后合并其余版本，更多地注意那里的冲突。如果他的 XYZ 确实不接触 ABCD 的东西，那么这应该不会发生冲突。如果他在将 C 合并为 C' 的过程中犯了一些奇怪或错误的事情，而你在合并 C' 时丢弃了它，那么它可能会在这里或将来的任何时候回来咬你。
In case there are no conflicts, a straight merge is obvious. If there are conflicts though...
You could merge his C' first, any conflicts during this stage are from re-applying your own changes, if they are non-trivial or because they are applied a bit out of order. Can happen if your C builds up on B and his C' was not a clean copy, or if any of B C D builds up on A so reapplying his A' no longer is obvious no-op, etc.
You could skip detailed conflict investigation and just accept your version, manually or:
git merge --strategy=ours C'Then merge the rest, paying more attention to conflicts there. If his X Y Z indeed don't touch A B C D stuff, this should go without conflicts. If he made something weird or wrong during merging C as C', and you discarded it when merging C', it can come back and bite you here or any time in the future though.