Git 避免“合並分支主”

Question

我和一位同事正在將 git 與單個遠程源存儲庫一起使用。 我們都提交本地然后推送到原點。 在我們工作的過程中，自然會有一些分歧。

一旦到了推送到原點的時間，我懷疑我們可以合並本地，然后推送到原點。 我希望在沒有描述合並的情況下獲得相當直接的版本歷史。

從相當復雜的地鐵地圖版本和不斷出現的合並分支“主”消息來看，我猜我們做的事情不太正確。

• “merge branch to master”消息的原因是什么？
• 如何簡化此版本歷史？

我感覺這之前已經在這里得到了回答，但我無法完全理解我收集的信息。

Answer 1

我們有一個類似的案例。 盡管我們使用中央主存儲庫，但我們經常讓個別開發人員生成合並分支“主”消息。 我們的解決方案是讓開發人員在從遠程主存儲庫中git pull --rebase時執行git pull --rebase 。

Answer 2

我認為您正在尋找git rebase 。

從“保留真實歷史”的角度來看，歷史記錄中記錄的每個合並都是必需的。 您的分支此時發生了分歧，隨后被合並（請注意，兩個分支的提交都是獨一無二的，因此無法進行快進。

如果你變基，當前的提示（包括來自你同事的更改）將成為新的分支點，除非他們在中間推進，否則你的更改可以通過快進應用，給人一種線性發展的印象（但非-單調時間戳）。

Answer 3

你做的一切都是正確的。 你在並發開發，你不時地整合你同行的變化， git忠實地記錄了這段歷史。

雖然您可以通過變基“避免”合並提交，但通常最好堅持合並歷史：每當您變基提交時，您實際上是在創建一個新提交，它會撒謊說它是如何形成的。 而且，雖然這些謊言通常是良性的，但它們可能會在以后造成麻煩。 如果您在每次重新提交時跳過重新運行測試套件，則尤其如此。

我認為，“創建線性歷史”的整個想法有點誤導清潔。 你真的不想要線性歷史。 你想要一個真實的歷史，每一個提交都經過實際測試。 因為這允許您稍后以有意義的結果運行git bisect 。

---

TL;DR：不要改變你的習慣。 他們很好。 將來你可能會感謝他們。