合并代碼還在用git merge嗎?互聯(lián)網(wǎng)公司都用git rebase!
你知道的越多,不知道的就越多,業(yè)余的像一棵小草!
你來(lái),我們一起精進(jìn)!你不來(lái),我和你的競(jìng)爭(zhēng)對(duì)手一起精進(jìn)!
編輯:業(yè)余草
juejin.cn/post/7001409038307033119
推薦:https://www.xttblog.com/?p=5302
據(jù)我所知,絕大部分程序員在合并代碼時(shí)使用 git merge,不少人不知道 git rebase 怎么用。當(dāng)然也包括我微信群里的部分網(wǎng)友,基于群友的討論。我整理了本文,希望大家喜歡。不喜歡的可以輕噴!
git merge 和 git rebase的區(qū)別
目的都是將一個(gè)分支的 commit 合并到到另外一個(gè)分支中去。
git merge
在gitlab上新建一個(gè)項(xiàng)目,push一個(gè)test文件上去

在本地修改test文件做兩次commit,每次commit都在文件中加一句修改



在遠(yuǎn)程倉(cāng)庫(kù)中直接修改文件并 commit,模擬其他開(kāi)發(fā)者的 commit。


4.如果此時(shí)我push本地的提交到遠(yuǎn)程,就會(huì)被拒絕,因?yàn)檫h(yuǎn)程和本地已經(jīng)各自有commit了,我們常規(guī)的做法是git pull一下,在本地解決沖突,然后繼續(xù)push,本質(zhì)上git pull = git fetch + git merge。
產(chǎn)生沖突:


處理沖突:

重新走add commit 然后push,可以看到必須將合并當(dāng)作一個(gè)新的commit:

git rebase
如果我們此時(shí)采用git pull --rebase,也就是=git fetch + git rebase。
一樣本地commit2次,遠(yuǎn)程commit2次


使用可以看到git pull --rebase,還是會(huì)提示我們?nèi)ヌ幚頉_突,但是從git log 上可以看出明顯已經(jīng)發(fā)生了rebase,也就是變基,本地分支基于了遠(yuǎn)程的最新commit,而不是上次的本地commit。


處理沖突,每處理完一次本地commit沖突,用git add標(biāo)記沖突已處理完,用git rebase --continue繼續(xù)處理下一個(gè)本地commit,也可以先用git rebase -i將本地的commit合并為一個(gè)commit,這樣git pull --rebase就能一次處理所有的沖突。

push到遠(yuǎn)程之后,在分支圖可以明顯看到,跟merge的區(qū)別在于,rebase不會(huì)產(chǎn)生分支,并且也不會(huì)產(chǎn)生新的提交。

總結(jié)
merge 是一個(gè)合并操作,會(huì)將兩個(gè)分支的修改合并在一起,默認(rèn)操作的情況下會(huì)提交合并中修改的內(nèi)容。 merge 的提交歷史記錄了實(shí)際發(fā)生過(guò)什么,關(guān)注點(diǎn)在真實(shí)的提交歷史上面。 rebase 并沒(méi)有進(jìn)行合并操作,只是提取了當(dāng)前分支的修改,將其復(fù)制在了目標(biāo)分支的最新提交后面。 rebase 操作會(huì)丟棄當(dāng)前分支已提交的 commit,故不要在已經(jīng) push 到遠(yuǎn)程,和其他人正在協(xié)作開(kāi)發(fā)的分支上執(zhí)行 rebase 操作。 merge 與 rebase 都是很好的分支合并命令,沒(méi)有好壞之分,使用哪一個(gè)應(yīng)由團(tuán)隊(duì)的實(shí)際開(kāi)發(fā)需求及場(chǎng)景決定。 如果比較關(guān)注commit時(shí)間的話,還是用git merge,rebase會(huì)打亂時(shí)間線是不可避免的。
評(píng)論
圖片
表情
