git rebase 使用詳解

2022-08-26 17:24:16 字數 1890 閱讀 8421

假設你現在基於遠端分支"origin",建立乙個叫"mywork"的分支。

現在我們在這個分支做一些修改,然後生成兩個提交(commit).

$ vi file.txt

$ git commit

$ vi otherfile.txt

$ git commit

...

但是與此同時,有些人也在"origin"分支上做了一些修改並且做了提交了. 這就意味著"origin"和"mywork"這兩個分支各自"前進"了,它們之間"分叉"了。

在這裡,你可以用"pull"命令把"origin"分支上的修改拉下來並且和你的修改合併; 結果看起來就像乙個新的"合併的提交"(merge commit):

但是,如果你想讓"mywork"分支歷史看起來像沒有經過任何合併一樣,你也許可以用 git rebase:

$ git checkout mywork

$ git rebase origin

這些命令會把你的"mywork"分支裡的每個提交(commit)取消掉,並且把它們臨時 儲存為補丁(patch)(這些補丁放到".git/rebase"目錄中),然後把"mywork"分支更新 到最新的"origin"分支,最後把儲存的這些補丁應用到"mywork"分支上。

注意:一般情況下rebase都是會有衝突的,詳細檢視衝突可以用命令git status然後就會顯示哪個檔案有衝突,然後開啟有衝突的哪個檔案,會發現有一些「<<<<<<>>>>>>」 這樣的符號。而根據上面描述,「*****==」的內容跟正常合併時相反的(待驗證)

當'mywork'分支更新之後,它會指向這些新建立的提交(commit),而那些老的提交會被丟棄。 如果執行垃圾收集命令(pruning garbage collection), 這些被丟棄的提交就會刪除. 

現在我們可以看一下用合併(merge)和用rebase所產生的歷史的區別:

在rebase的過程中,也許會出現衝突(conflict). 在這種情況,git會停止rebase並會讓你去解決 衝突;

rebase 和 merge的另乙個區別是rebase 的衝突是乙個乙個解決,如果有十個衝突,先解決第乙個,然後用命令

git add -u 

git rebase --continue

繼續後才會出現第二個衝突,直到所有衝突解決完,而merge 是所有的衝突都會顯示出來。 

另外如果rebase過程中,你想中途退出,恢復rebase前的**則可以用命令 

git rebase --abort
所以rebase的工作流就是

git rebase 

while

(存在衝突)

git rebase使用記錄

git rebase 最常用的操作有兩個 1 變基 本地dev分支修改 commit後發現遠端分支已經有了新的修改,此時需要git pull dev再git push推送到遠端,此時的提交記錄會出現分叉並多一次合併,如果使用git rebase dev會將本地提交的commit放到最新的遠端分支的提...

git rebase使用場景

1.當前分支落後拉取後,整理commit,使得提交歷史為直線 git pull git fetch git merge git pull rebase git fetch git rebase 其實 rebase的目的只有兩個 1.讓多個人在同乙個分支開發的提交節點形成一條線,而不是多條線 2.讓你...

Git Rebase原理以及黃金準則詳解

本文主要講解下git rebase的基本概念用法 其內部原理以及我們在真實專案中使用git rebase應該遵循的原則以及為啥需要遵循這些原則。相信對於rebase肯定不會陌生,就好像上圖描述的過程一樣,當你使用rebase命令的時候,即好像將你需要去rebase的分支拔下來然後重新插到另乙個分支上...