We are using a git rebase workflow and the feature branch is ready to go into master. Let's rebase the feature branch onto our master branch.
我們使用了 git rebase 工作流,feature 分支準(zhǔn)備合并到 master。rebase 這個 feature 分支到我們的 master 分支之上。
在第28關(guān)我們曾經(jīng)使用過一次 git rebase
命令,現(xiàn)在我們再詳細講解一下。
git rebase
和 git merge
都是用來合并,各有優(yōu)缺點,所以有些團隊會約定合并時只能用 git merge
或只能用 git rebase
,如果約定只能用 git rebase
來合并,這種工作方式就被稱為 'git rebase 工作流'。在用 git rebase
合并分支時,合并后的日志并非按各分支的提交時間排列,而是把一個分支的日志全部排列在另一個分支的日志之上,即使它們是并行開發(fā)的,在開發(fā)過程中交錯提交,但看起來也好像是按先后順序開發(fā)的一樣。
以本題為例,master 是主線,從 master 創(chuàng)建出 feature 分支,此后,master 提交了一次,提交說明是 “add content”,feature 也提交了一次,提交說明是 “add feature”,這時在 master 上執(zhí)行以下命令:
$ git rebase feature
那么 master 的日志就會變成 "add content" 在 "add feature" 之上。
而反過來,如果是在 feature 上執(zhí)行以下命令:
$ git rebase master
那么 feature 的日志就會變成 "add feature" 在 "add content" 之上。
第40關(guān)過關(guān)畫面如下:
http://wiki.jikexueyuan.com/project/githug-walkthrough/images/level-40-rebase.png" alt="第40關(guān) rebase" />