有一種場景是經常發生的。

大家都基於develop拉出分支進行並行開發，這裡的分支可能是多到數十個。然後彼此在進行自己的邏輯編寫，時間可能需要幾天或者幾周。在這期間你可能需要時不時的需要pull下遠端develop分支上的同事的提交。這是個好的習慣，這樣下去就可以避免你在一個無用的程式碼上進行長期的開發，回頭來看這些程式碼不是新的程式碼。甚至是會面臨很多衝突需要解決，而這個時候你可能還需要對衝突的部分程式碼進行測試迴歸，這就很麻煩了。

那麼我們來看一下你在pull時候需要習慣性的加上—rebase引數，這樣可以避免很多問題。--rebase的本意是想讓事情的發展看起來很連續和優美，而不是多出很多無用的merge commit 。

你在有些時候pull程式碼的時候會有這樣的一個提示：

這個時候你是習慣性的，”esc ：wq“，直接預設commit註釋。然後你的commit log就多了一筆很不好看的log。

如果你不懂的在最後release的時候合併掉這些無意義的commit，最後你的release分支就會被你搞的很醜陋。（合併commit請參考：聊下git merge –squash)

這個問題的出現是正常的，我們來看下為什麼會出現這個問題。正常情況下的分支commit路線：

當前develop分支上有三個commit。現在我們兩個專案開始啟動，需要分別拉出兩個分支獨立開發。

我們分別checkout –b 出來兩個分支，獨立開發互不干擾。正常情況下，如果這兩個分支的改動都沒有重貼或者衝突的時候，一切都很順利的。（重貼是指可以被系統自動合併的修改，而衝突是需要你手動解決的。你要重現這個現象還是有點小麻煩的，你要修改剛好可以重貼的位置，而不是直接導致衝突的地方）

我在develop_newfeature_authorcheck裡修改了點東西，push到develop。然後checkout 到develop_newfeature_apiwrapper。

git pull

這將會把develop_newfeature_authorcheck分支的修改直接拉下來於原生代碼merge，且產生一個commit，也就是merge commit。

你可以使用 git pull –rebase 這樣的結局就完全不一樣。—rebase 並不會產生一個commit提交，而是會將你的E commit附加到D commit的結尾處。在看commit log時，不會多出你所不知道的commit出來。其實此處的F commmit是無意義的，它只是一個merge commit。而且這裡面的message裡面的branch日後也不存了，這些分支都會被清除掉。

git pull –rebase 會使commit看起來很自然。

因為程式碼都有一個前後依賴，只是這個依賴在開發的時候誰先誰後的問題。

作者：王清培

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面