聊下git pull --rebase

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

大家都基于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看起來很自然。

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