爲什麼重新合併會導致git中的重複合併衝突？

Question

比方說，我們有一個「主」分支，說1000年的承諾超過2年。我們有一個長壽命的功能分支「feature1」，大約2個月大（當時從主分支），有100次提交。我們繼續在master和feature1上工作，偶爾會將master合併到feature1中（大約每5天提交5次提交）以防止它漂移過多。每次我們這樣做，一個特定的合併衝突不斷髮生，每次都是一樣的（我手動解決它）。爲了完整起見，在本例中它是一個JavaScript項目。

我的問題：爲什麼git不能「記住」第一次解決這個衝突，併爲後續合併使用相同的分辨率？

可選除皺可以幫助回答：

我的直覺是，如果我創建主一個新的分支，然後合併特徵1到結果（姑且稱之爲「大師+特徵1」），同樣合併衝突將停止發生隨後從主站到主站+ feature1的合併。在實踐中，我相信我已經看到了這一點，儘管我沒有證據。證明或解釋會很有趣，我相信它可以幫助解釋我主要問題的答案。

我沒有興趣在基礎重建的這個問題。 （假設特徵1被推到一個共享的遠程和重訂基期是不可取的。）

Answer 1

的Git可以和會記得以前的決議，如果你enable "rerere"。

沒有更多的細節我不能說爲什麼你合併master到feature1不斷碰到同樣的衝突。我只能描述合併工作的一般方法：它找到您正在合併的東西（master）和您所在的分支（feature1）的「合併基礎」（最近的共同祖先），然後發現（git diff）自這兩個分支中的每一個的共同祖先以來所做的更改。如果只有一個「方」發生了變化，那麼在那裏就不應該有衝突，所以「雙方」必須進行變更 - 至少在運行過程中至少相互衝突。

如果你目前所在的分支feature1 ，並希望看到，因爲你最近的共同祖先是什麼已經master改變：

git diff feature1...master # three dots 

發現，因爲那有什麼在feature1改變本身，扭轉名稱：

git diff master...feature1 # still 3 "."s 

有三個點的形式指示git diff使用git merge-base找到的合併基礎。然後差異是在右側的名稱上完成的。

---

其實，你不必是在樹枝上的。如果您是在樹枝上，你可以使用快捷HEAD：git diff ...master和git diff master...。