git rebase
Git rebase 與 Git merge 的區(qū)別
如果經(jīng)常多人協(xié)作開發(fā)的話，可能都很熟悉 git merge , 我經(jīng)常遇到這樣的情況：
- 項目開發(fā)主分支是 develop 分支
- 我自己從 develop 分支上切出一個feature1 的分支進(jìn)行開發(fā)
-
另一個同事切出一個 feature2 的分支進(jìn)行開發(fā)!
image.png
當(dāng)同事提前完成后將他的 feature 合并到 develop 分支（他的分支兩個commit c6, c7）
image.png
而我后面完成后為了怕有沖突文件，一般都要先拉取下最新的 develop 合并到我們當(dāng)前分支，沒有沖突或者有沖突文件修改好沖突文件后再把我當(dāng)前的分支 merge 到 develop 上去這樣看流程是沒啥問題哇,但是，看下圖。
image.png
我的分支上只做了兩次提交 c5 和 c8 但是我的分支上卻多出一個 c9 是為啥呢？ 都知道是 merge develop 后都會生成一個 merge 的 commit。
如果我有好幾個同事之前都做了提交，我先 merge develop 第一次，發(fā)現(xiàn)我還有個問題，我又返回去改代碼， 另外一個同事又提交了代碼，這樣我需要 merge 好幾次，我這條分支就會多出很多merge的commit，就不能保持commit的清潔，查看 commit 記錄非常不方便。如果想讓你的分支在合并了 develop 的代碼之后沒有 commit 記錄，就像沒經(jīng)歷過合并，就該用 git rebase。
現(xiàn)在我同樣有兩個分支 feature1 和 feature2, 都有各自的新的 commit，
我們先吧 feature2 merge 到 develop 上
$ git checkout develop
$ git merge feature1
現(xiàn)在我們切換到 feature1 上進(jìn)行 rebase
$ git checkout feature1$ git rebase develop
從上圖我們可以看出，原本c4的提交指向c3提交的 develop 分支，rebase 之后c4就指向了c7了，而且這些提交都待了 一撇，其實(shí)這是 git 把 feature1 上的 commit 取消掉了， 然后臨時保存成補(bǔ)丁，然后吧develop 分支更新到最新的，在把臨時保存的補(bǔ)丁應(yīng)用到 feature1 分支上。（
當(dāng) feature1 分支更新之后，它會指向這些新創(chuàng)建的提交(commit), 而那些老的提交會被丟棄在一邊。
如果運(yùn)行垃圾收集命令(pruning garbage collection), 這些被丟棄的提交就會刪除.
總的來說就是把 feature1 變基到 develop 分支上，怎么理解這個變基呢，基就是根基、基礎(chǔ)，我們把 feature1 的修改當(dāng)做是在 develop 的基礎(chǔ)上做的修改，改變這個基礎(chǔ)的內(nèi)容就叫變基。
沖突
在rebase的過程中，也許會出現(xiàn)沖突，在這種情況，Git會停止rebase并會讓你去解決沖突；在解決完沖突后，用
git add命令去更新這些內(nèi)容的索引(index), 然后，你無需執(zhí)行git commit,只要執(zhí)行:
$ git rebase --continue
這樣git會繼續(xù)應(yīng)用余下的補(bǔ)丁。
在任何時候，你可以用--abort參數(shù)來終止rebase的行動，并且"mywork" 分支會回到rebase開始前的狀態(tài)。
$ git rebase --abort
rebase 作為參數(shù)
另外，我們在使用git pull命令的時候，可以使用--rebase參數(shù)，即git pull --rebase,這里表示把你的本地當(dāng)前分支里的每個提交(commit)取消掉，并且把它們臨時 保存為補(bǔ)丁(patch)(這些補(bǔ)丁放到".git/rebase"目錄中),然后把本地當(dāng)前分支更新 為最新的"origin"分支，最后把保存的這些補(bǔ)丁應(yīng)用到本地當(dāng)前分支上。
