git rebase使用_020

git rebase 使用

rebase:顧名思義 ==變基==

假設如今從master 分支上,切出一個本地開發分支mydev

git checkout -b mydev

這時候master上的git記錄是這樣子的

A-->B-->C-->D

這個時候另一個開發人員把ta的dev分支合併到master分支了
tadev

A-->B-->C-->D
            |-->E-->F-->G

• 查看git記錄

git lg or git log

實際上如今master上的分支的git 提交記錄已是這樣子的了：

A-->B-->C-->D-->E-->F-->G

可是你本地上的分支仍是這樣的，你分別了提交了 3個 commit記錄。

|—->M-->N-->O
A-->B-->C-->D

這時，你的代碼開發完成了，須要合併代碼。這時候有兩種選擇：

直接

git merge

或者

通過 git rebase  再提交 git merge

git merge

若是直接git merge,假設你提交commit的時間和剛纔合併進去的其餘人的dev分支是有重合的：

A-->B-->C-->D
            |-->E       |-->F-->G
                |-->M-->N       |-->O

這樣的提交的記錄就比較亂，假設如今須要回退代碼什麼的，就有點小麻煩了，就須要一個文件去回退。對於多人協做的話 就比較須要git rebase

git rebase

先對mydev分支進行 git rebase 操做

這時候分支的提交記錄就會變爲以下所示：

A-->B-->C-->D-->E-->F-->G
                        |-->M-->N-->O

會把mydev分支新增的commit記錄新增在master分支最新的後面，這個時候push分支，就須要強制更新你的分支。再提交merge。

git push -f

變基的做用就是修整歷史，將分支歷史併入主線。

git rebase 注意事項

• 確保沒有其它分支同時更改同一個文件
• git rebase前須要確保master分支爲最新。
• 變基會修整歷史，而後將分支歷史併入主線，能夠理解成美化過的歷史，而合併則能夠不修改歷史，讓分支歷史依然獨立存在，能夠看做原始的歷史。
• 永遠不要對已經推到主幹分支服務器或者團隊其餘成員的提交進行變基，咱們選擇變基仍是合併的範圍應該在本身當前工做範圍內。

• 若是git rebase以後提示衝突的話，須要解決衝突：

  • 解決衝突後 add 更改的文件

  git add

  • 無需 commit, 繼續 rebase

  git rebase --continue

git rebase還有一些其餘的操做，

• 放棄git rebase

git rebase --abort

• 壓縮最近幾回提交

git rebase -i HEAD~4 合併最近4次提交

http://blog.codingplayboy.com...