这是一个想象中的问题,但我遇到了补丁的真正问题.假设我有一个包含以下git历史的项目:
A - B - C
现在,如果我收到两个补丁,C1并且C2应该应用C它们,我应该如何处理它们？如果我先应用补丁C1,那么我将无法应用补丁,C2因为存储库已成为:
A - B - C - C1
是否可以同时应用它们,或者我是否必须回复发送C2的人告诉他/她更新补丁？
现在假设我离线并工作和提交,以便存储库变为:
A - B - C - D - E
然后我查看我的电子邮件并收到补丁C.再次,是否可以简单地应用该补丁,或者我是否需要更新补丁？
经典的方法是:
一般的想法是,您无法解决合并冲突:只有补丁的创建者具有解决与当前源代码的任何冲突的必要知识.
正如Linus Torvalds(Git的创建者)在他2007年的Google演讲中所说:
所以发生的事情是,记住,分配意味着没有人是特别的.
所以不是我合并,我只是推出我的第一棵树,没有任何合并问题,我告诉第二个人:"嘿,我试图从你身上拉过来,但是我已经合并了冲突,并且它们并不是完全无足轻重的,所以我决定让你获得荣誉."
他们这样做.他们知道自己在做什么,因为这是他们的变化.所以他们可以做合并,他们可能认为我是一个白痴,因为合并是如此简单,很明显我应该采取他们的代码,但他们做合并,他们更新他们的树,并说"嘿,你能拉现在从我这里来,"我从他们那里拉出来,他们为我做了所有的工作.
这就是全部:他们为我做了所有的工作.所以,......我认可.现在我只需要弄清楚第3步:获利.
大多数情况下,C2将适用于C1.只有当他们对相同文件的重叠部分进行编辑时,才会出现合并冲突.Git将采用不冲突的补丁的所有部分,并插入可帮助您解决合并的冲突标记.
至于做什么,这取决于你的项目有多大以及你在代码的这一部分中的能力 - 我总是自己修复冲突,只要提交者使用合理的近期结账作为基础为他们的补丁.
另一位评论者提到莱纳斯的话说他总是让其他人解决冲突,但即便如此也不是这样.他经常要求人们在发送拉动请求时留下未解决的冲突,这样他就可以射击他们.