有一種場景是經(jīng)常發(fā)生的。
大家都基于develop拉出分支進(jìn)行并行開發(fā)，這里的分支可能是多到數(shù)十個(gè)。然后彼此在進(jìn)行自己的邏輯編寫，時(shí)間可能需要幾天或者幾周。在這期間你可能需要時(shí)不時(shí)的需要pull下遠(yuǎn)程develop分支上的同事的提交。這是個(gè)好的習(xí)慣，這樣下去就可以避免你在一個(gè)無用的代碼上進(jìn)行長期的開發(fā)，回頭來看這些代碼不是新的代碼。甚至是會(huì)面臨很多沖突需要解決，而這個(gè)時(shí)候你可能還需要對沖突的部分代碼進(jìn)行測試回歸，這就很麻煩了。
那么我們來看一下你在pull時(shí)候需要習(xí)慣性的加上—rebase參數(shù)，這樣可以避免很多問題。--rebase的本意是想讓事情的發(fā)展看起來很連續(xù)和優(yōu)美，而不是多出很多無用的merge commit 。
你在有些時(shí)候pull代碼的時(shí)候會(huì)有這樣的一個(gè)提示：
這個(gè)時(shí)候你是習(xí)慣性的，”esc ：wq“，直接默認(rèn)commit注釋。然后你的commit log就多了一筆很不好看的log。
如果你不懂的在最后release的時(shí)候合并掉這些無意義的commit，最后你的release分支就會(huì)被你搞的很丑陋。（合并commit請參考：聊下git merge –squash)
這個(gè)問題的出現(xiàn)是正常的，我們來看下為什么會(huì)出現(xiàn)這個(gè)問題。正常情況下的分支commit路線：
當(dāng)前develop分支上有三個(gè)commit?，F(xiàn)在我們兩個(gè)項(xiàng)目開始啟動(dòng)
