我爲什麼要做git rebase？

我見過很多人談論git rebase以及它做什麼，例如Hg: How to do a rebase like git's rebase和人們談論它達到的效果（給出線性歷史記錄），例如這裏Git rebase loses history, then why rebase?但我無法理解你爲什麼想要這樣做。我爲什麼要做git rebase？

它看起來像一個大費用，回去並修改您的提交歷史記錄（肯定會涉及一些與n方式衝突的醜陋合併）。我可以想象這種情況可能會引起誤解（例如，如果兩個人用不同的方式解決同一問題，但歷史並不表明他們的工作是同時發生的;似乎也可能容易導致批評和怨恨在一些高壓編碼環境中）。

你獲得的是一個更容易理解，但不正確的歷史圖。什麼使這值得努力？

在此先感謝。

來源

2012-11-02 Hbcdev

偉大的問題 - 我個人避免重新裝訂，因爲你提到的確切原因。我想這是個人喜好的問題，但我更喜歡歷史圖表顯示真正發生的事情。 –

在短時間內（小時或分鐘）推出單次提交或少量提交時，Rebase非常有用。

在推送到共享服務器之前，必須先提交對原始HEAD進行的提交，否則將創建非快速推送。這樣做，人們可以選擇合併（git pull）還是重設（git pull --rebase）操作。合併選項雖然在技術上更具吸引力，但會創建額外的合併提交。對於小提交，每次更改兩次提交的外觀實際上使得歷史記錄的可讀性更低，因爲合併操作會干擾提交的消息。

在一個典型的共享開發樹中，每個開發人員通過執行git pull; <resolve conflicts>; git push的一些變化而最終推送到共享分支。如果他們使用git pull而不使用--rebase，會發生什麼情況是幾乎所有提交都會伴隨一個合併提交，即使沒有進行並行開發。這從實際上是線性的提交序列創建了一個交織的歷史。出於這個原因，git pull --rebase對於短開發所導致的小更改是一個更好的選擇，而合併僅用於長壽命功能分支的集成。

所有這些都適用於重新綁定本地提交或重新綁定由緊密連接的同事共享的短期特徵分支（坐在同一個房間中）。一旦提交被定期推送到其他分支，它應該永不重新分配。

來源

2012-11-02 11:01:42 user4815162342

完全同意;在_my_腦子裏唯一使用rebase就是那個。我無法理解爲什麼有些項目完全不允許合併它們的歷史。 –

禁止合併聽起來像對答案中描述的大量虛假合併的膝反應。這是錯誤的反應，但在我看到我的同事（包括我自己）在幾年前開始使用git後立即創建的提交圖後，我有點了解它 - 它看起來更像是印刷電路板，而不像提交歷史。 – user4815162342

任何已經禁止合併的人可能還沒有學過關於'git log --no-merges'的問題 – jbowes

執行rebase通常不會涉及比合並更多的衝突解決方案，因此與此相比，花費很少（只需重新提交提交所需的時間）。

與有關git的大多數事情，你應該只，如果你知道什麼你正在做的，和爲什麼你這樣做底墊。這裏是我的一些rebound的原因：

我已經在一個補丁系列，沒有觸及任何組件已在上游同時更改。在這種情況下合併提交不會包含任何有用的信息。
我即將提交GitHub的拉取請求，並且所需的合併提交將會很多工作。首先通過重新綁定，使上游所有者更輕鬆地處理拉取請求。當然，我可以合併，但是因爲他們以前從未看過我的代碼，所以只會使補丁系列難以閱讀。
我正在合併來自上游的更改，並且存在大量衝突。 git rebase可讓我一次解決提交時的這些衝突，使其更容易理解，並隨時隨地測試。如果我關心維護合併提交，那麼我可以稍後再回到分支的非基礎版本，將其與上游合併，然後將diff與rebased版本作爲解決合併提交的衝突。

來源

2012-11-02 11:12:30 jbowes

我爲什麼要做git rebase？

回答

相關問題