有一種場景是經常發生的。
大家都基於develop拉出分支進行並行開發，這裏的分支可能是多到數十個。然後彼此在進行自己的邏輯編寫，時間可能需要幾天或者幾周。在這期間你可能需要時不時的需要pull下遠程develop分支上的同事的提交。這是個好的習慣，這樣下去就可以避免你在一個無用的代碼上進行長期的開發，回頭來看這些代碼不是新的代碼。甚至是會面臨很多衝突需要解決，而這個時候你可能還需要對衝突的部分代碼進行測試迴歸，這就很麻煩了。
那麼我們來看一下你在pull時候需要習慣性的加上—rebase參數，這樣可以避免很多問題。
--rebase的本意是想讓事情的發展看起來很連續和優美，而不是多出很多無用的merge commit 。
我們來看一個場景，在有些時候pull代碼的時候會有如下圖所示的提示：
這個時候往往會習慣性地去”esc ：wq“，直接默認commit註釋。
直接commit註釋之後，commit log就多了一筆很不優美的log
這種情況下，如果沒有在最後release的時候合併掉這些無意義的commit，那麼最後的release分支就會以非常醜陋的姿態示人。
這個問題的出現是正常的，我們來看下爲什麼會出現這個問題。
首先是正常情況下的分支commit路線：
當前develop分支上有三個commit。現在我們兩個項目開始啓動，需要分別拉出兩個分支獨立開發。
我們分別checkout –b 出來兩個分支，獨立開發互不干擾。正常情況下，如果這兩個分支的改動都沒有重貼或者衝突的時候，一切都很順利的。（重貼 ☞ 指可以被系統自動合併的修改，衝突 ☞ 指需要你手動解決的出入。要重現這個現象還是有點小麻煩的，你要修改剛好可以重貼的位置，而不是直接導致衝突的地方）
但如果在develop_newfeature_authorcheck（D）裏修改了點東西，push到develop。然後checkout 到develop_newfeature_apiwrapper（E），隨後
git pull
這將會把develop_newfeature_authorcheck分支的修改直接拉下來於本地代碼merge，且產生一個commit，也就是merge commit。
產生的merge commit前文已表，不美觀的commit會隨着每次git pull而在commit log中如期而至。但如果此時執行的是
git pull -- rebase
那麼事情就不一樣了。
--rebase 並不會產生一個commit提交，而是會將你的E commit附加到D commit的結尾處。在看commit log時，不會多出你所不知道的commit出來。
其實此處的F commmit是無意義的，它只是一個merge commit。而且這裏面的message裏面的branch日後也不存了，這些分支都會被清除掉。
使用git pull –rebase 使commit看起來很自然優美
————————————————
版權聲明：本文爲CSDN博主「天漢執金吾」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_34865249/article/details/89210655