在基于 Git 的開發(fā)過程中，我們很容易遇到合并代碼的情況，例如我們從 master 分支拉取了一個(gè) feature 分支，當(dāng)我們開發(fā)到一段時(shí)間之后，可能需要將 master 的代碼合并到我們當(dāng)前的 feature 分支之中。

這時(shí)，我們有兩個(gè)選擇，一個(gè)是使用git merge命令，一個(gè)是使用git rebase命令，這兩個(gè)命令都是用來合并代碼的，但卻有一些差異。在本文中，我們主要講述git rebase命令的使用方法，也會(huì)簡(jiǎn)單介紹這兩個(gè)命令的差異。

如上圖所示，我們從 master 分支拉取了一個(gè)名為 feature 的分支，并且在拉取新分支之后，有過三次提交記錄；同時(shí)，master 分支在我們拉取 feature 分支之后，也有過兩次提交記錄?，F(xiàn)在我們已經(jīng)構(gòu)造了背景，接下來我們合并代碼。

首次，我們使用merge命令，其命令形式一般為git merge --no-ff master，即表示將 master 的代碼合并到 feature 分支，其中--no-ff參數(shù)是為了保留 master 分支的提交記錄。如上圖所示，在使用merge命令進(jìn)行代碼合并之后，Git 會(huì)自動(dòng)創(chuàng)建一個(gè)新的 commit 用來表示當(dāng)前的合并操作，此 commit 記錄了 master 代碼合并到 feature 分支時(shí)產(chǎn)生的所有改動(dòng)。

接下來，我們使用rebase命令，其命令一般形式為git rebase feature，即表示在 master 分支上執(zhí)行rebase命令，將 feature 分支的代碼合并到 master 分支。如上圖所示，在使用rebase命令之后，Git 會(huì)合并兩個(gè)分支的 commit 記錄，其規(guī)則為「在基準(zhǔn)分支上合并目標(biāo)分支的代碼，會(huì)將目標(biāo)分支的提交記錄全部前置到基準(zhǔn)分支的最新提交記錄之前」，就如上面這樣，我們?cè)?master 分支上使用了rebase命令之后，Git 將 feature 分支上面的所有 commit 記錄都前置到了 master 分支的最新 commit 記錄之前。

在這里，需要注意的是：rebase是以 commit 為維度的，按 commit 提交的順序依次進(jìn)行合并操作；如果在合并的過程中，某個(gè) commit 遇到了沖突，則需要我們先解決該沖突，然后才能繼續(xù)進(jìn)行合并操作。特別地，在我們解決沖突之后，需要使用git add + 沖突文件命令將當(dāng)前沖突標(biāo)記為已解決，然后使用git rebase --continue命令繼續(xù)合并操作。

通過上面的描述，我們能發(fā)現(xiàn)merge和rebase有一個(gè)很明顯的差異，那就是當(dāng)遇到?jīng)_突的時(shí)候，使用merge命令，我們只需要解決一次沖突即可；使用rebase命令，我們則需要依次解決每一個(gè)沖突。

對(duì)于 Git 的rebase命令，其除了能進(jìn)行代碼合并之外，還有一個(gè)常用的功能，那就是將多個(gè) commit 合并為一個(gè)，仍然以上面的 feature 分支為例，我們將其從 master 分支拉取之后，進(jìn)行了三次提交，現(xiàn)在我們將這三個(gè)提交結(jié)論合并為一個(gè)，其命令一般形式為：

git rebase -i HEAD~N

其中，N為我們需要合并的 commit 記錄的數(shù)量，因?yàn)槭纠惺侨翁峤挥涗?，所以在此?chǎng)景下，將N替換為3即可。

在執(zhí)行完上面的命令之后，我們會(huì)進(jìn)入vi或者vim文件編輯器：

如上圖所示，pick標(biāo)識(shí)了我們的三次提交記錄，按i建進(jìn)入編輯模式，保留第一個(gè)pick，然后將后面兩個(gè)pick修改為s或者f，然后鍵入:wq保留修改。最后，為了將變更同步到遠(yuǎn)程分支，我們需要使用git push -f命令，其中參數(shù)-f表示強(qiáng)制提交。

到此這篇關(guān)于Git 的 rebase 命令使用方法的文章就介紹到這了,更多相關(guān)git rebase 命令內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論