1. rebase變基

問題：
工作中我們一般是從master分支拉自己的開發分支開發，如果master分支被組長合并了其他同事的開發，也就是master分支ahead你的分支，我們這時一般不能直接提交自己的dev分支到遠程提pr，需要先把master最新的變更合并到本地分支，怎么做呢？
merge肯定不行，這樣提交時別人的變更提交者就是你，很不合理。這里使用rebase更合理。

rebase,直接翻譯過來就是變基。通過rebase命令，我們可以改變一串commits的基點(父commit)。首先我們先來操作一遍這個命令，看看效果就知道這個命令是干啥的了。

假設我們的git歷史是這樣子的。我們在commit3這個地方開出了一個分支branch1用于開發,然后在branch1分支上開發并提交了兩個commit(6和7)。同時其他分支合并到master分支導致master分支多了兩個提交(4和5)。

這時我們執行以下命令： (注: 此時的活動分支是branch1)

(branch1) git rebase master

執行完命令后的git結構如下：

我們可以看到，在使用rebase命令之前，branch1和master的交叉點是commit3，這也是branch1的"基點"。通過執行git rebase命令后，branch1的"基點"就變成了5，也就是master的最新一次提交commit5。通俗的講就是將branch1的基變成了master分支最新的那次提交

注意不要在公共分支上使用rebase提交到遠程，你的隊友會崩潰的！官方講rebase

上面是rebase工作中經常遇到的一個場景，rebase還有更多高級用法
https://blog.csdn.net/allanGold/article/details/87168012

2. 改善你的提交歷史

• 有時候我們提交完了才發現漏掉了幾個文件沒有添加，或者提交信息寫錯了，怎么辦呢？

  git commit --amend 這個命令會將暫存區中的文件提交。 如果自上次提交以來你還未做任何修改（例如，在上次提交后馬上執行了此命令）， 那么快照會保持不變，而你所修改的只是提交信息。如果修改了文件，則最終你只會有一個提交——第二次提交將代替第一次提交的結果。文本編輯器啟動后，可以看到之前的提交信息。 編輯后保存會覆蓋原來的提交信息

  修補提交最明顯的價值是可以稍微改進你最后的提交，而不會讓“啊，忘了添加一個文件”或者 “小修補，修正筆誤”這種提交信息弄亂你的倉庫歷史

• 那么如何修改之前某次提交的message呢？

  git rebase -i 77de453e 修改77de 之后的提交信息，注意不包含77de這次提交。
  把要修改的某次的提交的pick改為r保存,然后在彈出的對話框中修改提交message即可。

  pick 08c4cfa add index and pick 988098e update readme pick 8dc72e1 mv readme.md pick 3f79e47 delete# Rebase dde6fb8..f3482f6 onto dde6fb8 (5 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit

• 如何將多次提交合并為一次提交呢？
  同樣的git rebase -i 77de453e 使用s（use commit, but meld into previous commit）或者f(會自動拋棄提交信息）。
  注意順序，最新的提交會在下面，f的含義是將最近的提交合并到之前的提交里，所以第一行不要動。

  這種在準備提交到遠程倉庫時特別有用，改善你本地的提交歷史，無論你本地開發時多么亂七八糟的提交信息，提交后其他同事看到的是很干凈清爽的提交歷史。

3. git stash

有時會遇到這樣的情況，正在dev分支開發新功能，做到一半時有人過來反饋一個bug，讓馬上解決，但是新功能做到了一半你又不想提交，切一個新分支又有些麻煩,這時就可以使用git stash命令先把當前進度保存起來，然后切換到另一個分支去修改bug，修改完提交后，再切回dev分支，使用git stash pop來恢復之前的進度繼續開發新功能。

git stash保存暫存區和工作區的改動。執行完這個命令后運行git status命令，就會發現當前是一個干凈的工作區，沒有任何改動。
git stash save 'message...'可以添加一些注釋,推薦添加注釋,不然有多個的時候你會分不清

git stash list顯示保存進度的列表

git stash pop 恢復最新的進度到工作區。git默認會把工作區和暫存區的改動都恢復到工作區。注意pop會刪除當前進度。
git stash pop stash@{1}恢復指定的進度到工作區。stash_id是通過git stash list命令得到的
git stash apply 除了不刪除恢復的進度之外，其余和git stash pop 命令一樣。

git stash drop [stash_id]刪除一個存儲的進度。如果不指定stash_id，則默認刪除最新的存儲進度。
git stash clear刪除所有存儲的進度。

可以把一些本地開發時需要修改的配置(但是不能上傳)暫存,加上詳細的注釋,這樣就相當于個本地的提交歷史了.

4. cherry-pick

對于多分支的代碼庫，將特定的幾個提交移到另一個分支是常見需求
git cherry-pick <commitHash> 將指定的提交commitHash，應用于當前分支
git cherry-pick feature 表示將feature分支的最近一次提交，轉移到當前分支
git cherry-pick <HashA> <HashB> 轉移多個commit
git cherry-pick A..B 轉移從 A 到 B 的所有提交. 注意不包含提交 A 如果要包含提交 A使用git cherry-pick A^..B
使用IED的圖形化操作工具也很方便的!
阮一峰的git cherry-pick 教程

5. 回滾遠程版本

回滾本地版本

git reflog git reset --hard Obfafd

直接查看版本歷史回滾即可。

回滾遠程版本
一種方式是先回滾本地版本，然后提交到遠程，但是這時因為本地版本落后遠程分支提交遠程會失敗，必須使用強制推送覆蓋遠程分支。但是這樣還有問題，你的同事這時pull之后，會發現：

$ git status On branch master Your branch is ahead of 'origin/master' by 2 commits.(use "git push" to publish your local commits) nothing to commit, working directory clean

如果他不知道你回滾了遠程版本，或者是個豬隊友然后他push了，你辛辛苦苦回滾的遠程版本就又復原了。

---

還有一種比較優雅的方式，是使用revert

git revert HEAD //撤銷最近一次提交 git revert HEAD~1 //撤銷上上次的提交，注意：數字從0開始 git revert 0ffaacc //撤銷0ffaacc這次提交

git revert 命令意思是撤銷某次提交。它會產生一個新的提交，雖然代碼回退了，但是版本依然是向前的，所以當你用revert回退之后，所有人pull之后，他們的代碼也自動的回退了。

但是，要注意以下幾點：

revert 是撤銷一次提交，所以后面的commit id是你需要回滾到的版本的前一次提交
使用revert HEAD是撤銷最近的一次提交，如果你最近一次提交是用revert命令產生的，那么你再執行一次，就相當于撤銷了上次的撤銷操作，換句話說，你連續執行兩次revert HEAD命令，就跟沒執行是一樣的
使用revert HEAD~1 表示撤銷最近2次提交，這個數字是從0開始的，如果你之前撤銷過產生了commi id，那么也會計算在內的。
如果使用 revert 撤銷的不是最近一次提交，那么一定會有代碼沖突，需要你合并代碼，合并代碼只需要把當前的代碼全部去掉，保留之前版本的代碼就可以了.

git revert 命令的好處就是不會丟掉別人的提交，即使你撤銷后覆蓋了別人的提交，他更新代碼后，可以在本地用 reset 向前回滾，找到自己的代碼，然后拉一下分支，再回來合并上去就可以找回被你覆蓋的提交了。

總結

以上是生活随笔為你收集整理的工作中必须要知道的git高级用法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。