Git合併簡單vs壁球。什麼目的？如何跟蹤每個功能的一次提交？

Question

我不喜歡Git的一件事是提交的數量。不要誤解我的意思，這是存儲（安全）工作的一種非常方便的方法，但從長遠來看，搜索的粒度太大。

讓我來描述以下情景，同時使用從分支的特徵分支開發。

• 特徵1從支開發並具有5條
• 特徵2從支開發和具有3提交
• 特徵3從特徵1支鏈且具有5 +2提交。

有三個分支的原因是因爲有一個團隊在存儲庫上工作。 特徵3假設特徵1完成，等待合併到開發。還有其他的用例，但這是最簡單的例子。

我的目標是在完成所有功能後在上開發三次提交。

使用Git合併/拉

上述場景效果很好。因爲實質上這兩個命令都將提交移動到開發分支。當合並特徵1時，發展參考它是五個提交。當特徵3將要合併時，只有最後兩個提交將合併到開發。

這個唯一的負面因素是開發得到太多的提交。這意味着，當合併到主所有「噪音」移動。所以我的目標沒有實現。

使用Git壁球

當特徵1合併合併，發展獲取一個新的提交這是所有特徵1聚集。這非常好，因爲現在只用一個提交來跟蹤功能。當Feature1被刪除時，所有中間提交不再可見，從而使跟蹤更容易。這也與諸如一個請求和一個github問題等概念相匹配。

當功能3將要合併有衝突，問題開始。爲了解決這個問題，你需要合併開發返回到功能3。與衝突。這導致一個新的提交沒有更改文件。現在我們合併了壁球Feature3到develop。

我的目標是實現的，但有很多微觀管理的犧牲。

問題/備註

據我理解，這是git的現實。我讀過的一條建議是創建一個保存壓縮合並提交的同級功能分支。使用兄弟分支進行拉取請求，從而強制每個要素使用一次提交。這不能解決嘗試合併其他分支時創建的衝突，尤其是從其他功能分支繼承的分支。

• 可以在同一個分支內做一個內部壁球嗎？我不這麼認爲，但是不要問。
• 我我錯過了什麼？
• 這是壁壘合併的權衡？解決可能沒有代碼更改的衝突？
• 追隨「每個功能一個提交」概念值得嗎？
  • 如果沒有，那麼壁球的目的是什麼？誰在使用這個？

我讀過與重訂和合並後的模擬與復位壁球替代，但據我瞭解沒有解決提到合併特點3的開銷。

Answer 1

是的，這麼多提交git的目的是讓每一個變化都能跟蹤。如果某些提交不重要，或者可以在一次提交中記錄所有更改以查看歷史原因，則可以壓縮這些提交。

對於您的問題：

1.是，你可以做一個內部的壁球。假設你的git提交歷史，如下圖：

   K---L---M  Feature2 
      /
A---B---…---C---…    develop 
    \   
     D---E---F---G---H   Feature1 
         \ 
          I---J Feature3 

您可以使用這些步驟壁球每個分支：

git checkout Feature1 
git rebase -i HEAD~5 

輸入i

pick D 
squash E 
squash F 
squash G 
squash H 

按Esc鍵，然後輸入:wq

git checkout Feature3 
git rebase -i HEAD~7 

pick D 
squash E 
squash F 
squash G 
squash H 
squash I 
squash J 

git rebase Feature1 
git checkout Feature2 
git rebase -i HEAD~3 

pick K 
squash L 
squash M 

你的過程是確定。

要壓縮提交，第一個（最早的）應該是使用選擇，其他人可以使用壓縮，以便它只顯示一個提交的分支。如果存在衝突，則可以修改並保存衝突文件，然後使用git add .和git rebase --continue。

這不是必要的，它取決於你最喜歡的。壁球的主要目的是使歷史看起來更整齊清晰。

Answer 2

我真的認爲rebasing是你的解決方案。

如果我的理解，下面是你的git結構：

develop \ A - B - C [feature1] \ D - E [feature3]

你的問題是，一旦你被壓扁併合並特徵1中發展，最初的三個提交特點3引用不再存在。你實質上留下如下，除了特徵1並不存在。

develop — feature1Merge \ A - B - C [feature1] \ D - E [feature3]

所以feature1Merge犯發展對那些在特點3的歷史不同。

在這種情況下，如果你試圖rebase特點3回到上發展，提交AB和C會去用它，這在理論上不應導致任何問題，因爲變化已經在開發所以git應該快速提交這些提交。顯然，這似乎並沒有發生。

我在這種情況下建議做的是rebase onto。

再次基於走上

的--onto選項可以讓你變基具體的提交，而不是整個分支。

因此停止混帳試圖用承諾AB和C基礎重建的時候，我們使用--onto，這需要3個參數：

• 的分支

• 目前基地的新基地分行

• 分行轉賬的名稱

在你的情況，這將是：

git rebase --onto develop C feature3

這將檢查發展，然後應用所有提交的特點3因爲C：

develop — feature1Merge \ D - E [feature3]

希望這一切都是有道理的，並且儘可能實現你想要的一樣儘可能的！