我的分支結構如下。3個分支。
a - b - c - d *main*
\
e - f *feature1*
\
h *feature2*
功能1和功能2在技術上實際上是完全獨立的。我只是想用feature1代碼測試feature2。但計劃的改變意味著我需要先把功能2放在主功能中，然后再把功能1放進去。
因此，我們的目標是在main上從h中挑選d。
這是我的困惑。當我在Fork這樣的查看器中查看diff時，diff非常干凈。事實上，這正是我想要挑選的。當我查看commit h中的更改時，只顯示了行的更改。
問題是，當我轉到main并嘗試在h中進行櫻桃選擇時，它會合并沖突。在合并沖突中，是來自提交e和f的代碼，我想這在技術上是有意義的，因為這是對整個文件狀態的選擇性選擇，但會使選擇性選擇提交變得更加困難。
我嘗試將提交h保存為補丁，但由于沖突，它無法應用于d。我先嘗試在main上重新設置feature2的基礎，但這也有同樣的問題。一句話：當我查看h的diff時，我看到的diff正是我想應用于d的diff。因為存在合并沖突，所以感覺e和f的歷史被帶入了h的櫻桃采摘中。如果我能以某種方式提取f上h的diff并將其應用于d，那將是我正在嘗試做的更多事情。
沖突意味著
h中的更改建立在e和f中更改的基礎上。由于e和f不在main中，因此h不能干凈地應用。在
h和e+f之間有一個明顯的依賴關系，這就是沖突告訴你的。如果特征1和特征2這兩個特征在概念/語義上是獨立的，使得其中一個可以在沒有另一個的情況下存在，那么沖突意味著實現是文本交錯或耦合的，并且不能自動分離（例如，一個子例程實現兩個不同的特征）。你需要解決沖突。當您最終將Feature1合并到main中時，您將遇到另一個沖突。
沖突看起來很痛苦，但它告訴了代碼的質量，即不同的功能沒有很好地分離。重寫它。