假設(shè)我們有如下git 提交記錄
WX20191226-111014@2x.png
- 初始節(jié)點(diǎn)
- master 基于初始節(jié)點(diǎn)進(jìn)行了2次更改
- feature 基于初始節(jié)點(diǎn)進(jìn)行了2次更改
WX20191226-110941@2x.png
這樣做法是沒(méi)有問(wèn)題的, 但是對(duì)于code review是一個(gè)很不好的體驗(yàn), 特別是實(shí)際項(xiàng)目中的代碼合并情況往往特別復(fù)雜, 經(jīng)常出現(xiàn)feature需要master中的新功能, 導(dǎo)致反復(fù)合并的情況,git 提交記錄更沒(méi)辦法看了. 這個(gè)時(shí)候, 如果正確的使用rebase , 可以大幅減少git log 的復(fù)雜度.
我們先切回到feature分支, 然后執(zhí)行rebase
image.png
得到下圖的結(jié)果
image.png
git 提交的線被擼直了, 好像feature是基于最新的master進(jìn)行修改的, 并且feature里也包含的master的所有代碼.
結(jié)合交互式的折疊 就可以大幅減少git 中的提交記錄的次數(shù), merge的數(shù)量, code review的時(shí)候, 每一次更改都一目了然.
注意: 如果需要rebase的分支已經(jīng)推送到了remote , 那么進(jìn)行rebase的操作的時(shí)候, 請(qǐng)將本分支再分支一個(gè)出來(lái), 因?yàn)閞ebase是對(duì)分支已有的提交進(jìn)行修改, 如果其他人拉取了你的舊的提交, 你再推送新的更改上去, 會(huì)讓人很困惑, 所以對(duì)于已經(jīng)推送到遠(yuǎn)端的分支, rebase一定要?jiǎng)?chuàng)建一個(gè)新的分支, 不要推送到遠(yuǎn)端的時(shí)候,進(jìn)行rebase(變基)
