聊下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看起來很天然。

由於代碼都有一個先後依賴，只是這個依賴在開發的時候誰先誰後的問題。

 

做者：王清培

出處：http://www.cnblogs.com/wangiqngpei557/

本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面