1、在git rebase -i 後 ，用git push -f origin local_branch:remote_branch ：

其實這個命令在你一個人單獨維護一個分支，不共享給其他人的時候 ，是可以隨便用的，因為你一個人在本地就能確定哪個是你想要的，哪個你不想要。 而當你和其他人合作的時候，這個命令就不要用了，因為你會覆蓋其他人的提交的，因為你用的命令是強制性覆蓋。那麼在多人合作時候，我們就應該學會git rebase的原理以及用法了，下面會講述這個問題。

2、在git rebase -i遇到衝突了怎麼辦。

系統會提示你解決衝突後，用git add，然後繼續用git rebase --continue完成後面的變基操作，並且還提示你，如果你不想用這次的git rebase -i操作，可以 用git rebase --abort來取消這次的操作，其實從這裡可以看到git 很人性化的一面，前提是你要細心看懂這些提示。

好了，前話就說這麼多，專案管理中一般會遇到很多問題，今天呢，要說的是git rebase 的原理 ，以及如何在專案中使用。

我相信大家在網上看到很我git rebase master的命令，告訴你這是什麼意思 ，那麼具體如何在專案上應用就很少有人說，首先，我自己來畫副圖玩玩，畫不好見諒。

OK，master是喜聞樂見的遠端分支，dev_branch那就是自己的分支了，有個人在維護遠端分支 ，而我在維護dev_branch分支 ，那麼這個時候需要master的修改，這個時候，一般我們會選擇merge，因為master是我的基礎分支，但是merge呢，就會出現很多人覺得不喜歡的一點，他會出現一個merge commit message，這讓自己的分支看起來很不美觀（不上圖了，自己看不下去自己的畫圖了），那麼這個時候，你可以選擇git rebase orgin master。

git rebase origin master，這個命令可能跟網上不同，我加上了origin，那麼這是什麼意思呢，意思就是  我在本地的分支 dev_branch上， 對遠端倉庫（預設origin代表遠端倉庫）的master使用變基揀選操作。 如果我用git rebase master，就是對本地的master分支進行rebase ，前提是你需要git fetch origin來更新本地的分支，可能這樣說大家有疑惑，那麼上一張圖

哎，自己畫圖的功底太渣了，還是動手解釋吧。

我們用git branch可以檢視到自己當前分支是dev_branch分支，那麼使用git rebase origin master

git 會檢測兩個分支 dev_branch origin/master的公共parent 節點，很顯然是B，這樣我們的當前分支dev_branch和origin/master分支的節點的差異就是D了，或者更多，這個時候git 會把差異提交一個個揀選上去，就成了 D' ，注意不是D，相當於cherry-pick，但是呢 commitId改變 了，這個時候你就不會看到git merger的時候那個渣渣merge commit message了。

好了，當我們在自己的私有的分支上面這麼操作的時候 ，會把自己的分支搞得很“乾淨”，很賞心悅目，那麼這個時候問題來了，如果兩個從共同維護一個分支 ，我們如何把分支也管理這麼漂亮呢，好，下面開搞這個問題，又到了畫圖的時候，XXXX~

基礎分支master，兩個人分別對應的分支為dev_branch_S01（開發者S01） 和dev_branch_S02（開發者S02），可以看到這個時候 ，兩個 人現在都在自己的分支上提交 了一個commit。

我們來假想下，如果S02 push了分支到master上去了，那麼就是Fast-Forward，俗稱快進式提交，有人會問什麼叫快進式提交，哎，難解釋 ，就我的理解就是，master的HEAD指標可以做簡單的向前移動，具體細節搜搜吧，通俗點master所有提交都是dev_branch_s00的父節點，因此可以快進式提交。

而當S02提交完了後，S01開始push了，S01突然發現 ，尼瑪，為什麼我的提交被reject了，提示的是非快進式的提交 ，這個時候經過溝通了解到S02 push過了，所以S01會想到先git fetch 後 merge ，也就是git pull orgin master ( = git fech origin master && git merge origin/master),然後現提交 ，這個時候 ，萬惡的merge commit message資訊就來了。 但是我們今天就是解決這個問題。

剛才我們講了git rebase master的原理，那麼這個時候在dev_branch_S01分支上先git fetch origin，然後用git pull --rebase origin master來執行變基操作

這個時候，你應該發現了，master所有的提交在dev_branch_S01上都有了，這樣就終於可以尼到的快進式的提交了，是不是很爽歪歪~