本文主要分享了5個在開發中實用的 Git 命令和設置短命令的方式。
1.stash：存儲臨時代碼。
2.reset --soft：軟回溯，回退 commit 的同時保留修改內容。
3.cherry-pick：復制 commit。
4.revert：撤銷 commit 的修改內容。
5.reflog：記錄了 commit 的歷史操作。
6.rebase：改變當前分支的基點
1.stash
官方解釋：當您想記錄工作目錄和索引的當前狀態，但又想返回一個干凈的工作目錄時，請使用git stash。該命令將保存本地修改，并恢復工作目錄以匹配頭部提交。
stash 命令能夠將還未 commit 的代碼存起來，讓你的工作目錄變得干凈。
應用場景
我猜你心里一定在想：為什么要變干凈？
應用場景：某一天你正在 feature 分支開發新需求，突然產品經理跑過來說線上有bug，必須馬上修復。而此時你的功能開發到一半，于是你急忙想切到 master 分支，然后你就會看到以下報錯：
因為當前有文件更改了，需要提交commit保持工作區干凈才能切分支。由于情況緊急，你只有急忙 commit 上去，commit 信息也隨便寫了個“暫存代碼”，于是該分支提交記錄就留了一條黑歷史...(真人真事，看過這種提交)
命令使用
如果你學會 stash，就不用那么狼狽了。你只需要：
git stash
就這么簡單，代碼就被存起來了。
當你修復完線上問題，切回 feature 分支，想恢復代碼也只需要：
git stash apply
相關命令
# 保存當前未commit的代碼
git stash
# 保存當前未commit的代碼并添加備注
git stash save "備注的內容"
# 列出stash的所有記錄
git stash list
# 刪除stash的所有記錄
git stash clear
# 應用最近一次的stash
git stash apply
# 應用最近一次的stash，隨后刪除該記錄
git stash pop
# 刪除最近的一次stash
git stash drop
當有多條 stash，可以指定操作stash，首先使用stash list 列出所有記錄：
git stash list
stash@{0}: WIP on ...
stash@{1}: WIP on ...
stash@{2}: On ...
應用第二條記錄：
git stash apply stash@{1}
pop，drop 同理。
2.reset --soft
回退你已提交的 commit，并將 commit 的修改內容放回到暫存區。
一般我們在使用 reset 命令時，git reset --hard 會被提及的比較多，它能讓 commit 記錄強制回溯到某一個節點。而 git reset --soft 的作用正如其名，--soft (柔軟的) 除了回溯節點外，還會保留節點的修改內容。
應用場景
回溯節點，為什么要保留修改內容？
應用場景1：有時候手滑不小心把不該提交的內容 commit 了，這時想改回來，只能再 commit 一次，又多一條“黑歷史”。
應用場景2：規范些的團隊，一般對于 commit 的內容要求職責明確，顆粒度要細，便于后續出現問題排查。本來屬于兩塊不同功能的修改，一起 commit 上去，這種就屬于不規范。這次恰好又手滑了，一次性 commit 上去。
命令使用
學會 reset --soft 之后，你只需要：
# 恢復最近一次 commit
git reset --soft HEAD^
reset --soft 相當于后悔藥，給你重新改過的機會。對于上面的場景，就可以再次修改重新提交，保持干凈的 commit 記錄。
以上說的是還未 push 的commit。對于已經 push 的 commit，也可以使用該命令，不過再次 push 時，由于遠程分支和本地分支有差異，需要強制推送 git push -f 來覆蓋被 reset 的 commit。
還有一點需要注意，在 reset --soft 指定 commit 號時，會將該 commit 到最近一次 commit 的所有修改內容全部恢復，而不是只針對該 commit。
舉個栗子：
commit 記錄有 c、b、a。
reset 到 a
git reset --soft 1a900ac29eba73ce817bf959f82ffcb0bfa38f75
此時的 HEAD 到了 a，而 b、c 的修改內容都回到了暫存區。
3.cherry-pick
給定一個或多個現有提交，應用每個提交引入的更改，為每個提交記錄一個新的提交。這需要您的工作樹清潔（沒有從頭提交的修改）。
將已經提交的 commit，復制出新的 commit 應用到分支里
應用場景
commit 都提交了，為什么還要復制新的出來？
應用場景1：有時候版本的一些優化需求開發到一半，可能其中某一個開發完的需求要臨時上，或者某些原因導致待開發的需求卡住了已開發完成的需求上線。這時候就需要把 commit 抽出來，單獨處理。
應用場景2：有時候開發分支中的代碼記錄被污染了，導致開發分支合到線上分支有問題，這時就需要拉一條干凈的開發分支，再從舊的開發分支中，把 commit 復制到新分支。
命令使用
復制單個
現在有一條feature分支，commit 記錄如下：
需要把 b 復制到另一個分支，首先把 commitHash 復制下來，然后切到 master 分支。
當前 master 最新的記錄是 a，使用 cherry-pick 把 b 應用到當前分支。
完成后看下最新的 log，b 已經應用到 master，作為最新的 commit 了。可以看到 commitHash 和之前的不一樣，但是提交時間還是保留之前的。
復制多個
以上是單個 commit 的復制，下面再來看看 cherry-pick 多個 commit 要如何操作。
一次轉移多個提交：
git cherry-pick commit1 commit2
上面的命令將 commit1 和 commit2 兩個提交應用到當前分支。
多個連續的commit，也可區間復制：
git cherry-pick commit1^..commit2
上面的命令將 commit1 到 commit2 這個區間的 commit 都應用到當前分支（包含commit1、commit2），commit1 是最早的提交。
cherry-pick 代碼沖突
在 cherry-pick 多個commit時，可能會遇到代碼沖突，這時 cherry-pick 會停下來，讓用戶決定如何繼續操作。下面看看怎么解決這種場景。
還是 feature 分支，現在需要把 c、d、e 都復制到 master 分支上。先把起點c和終點e的 commitHash 記下來。
切到 master 分支，使用區間的 cherry-pick。可以看到 c 被成功復制，當進行到 d 時，發現代碼沖突，cherry-pick 中斷了。這時需要解決代碼沖突，重新提交到暫存區。
然后使用 cherry-pick --continue 讓 cherry-pick 繼續進行下去。最后 e 也被復制進來，整個流程就完成了。
以上是完整的流程，但有時候可能需要在代碼沖突后，放棄或者退出流程：
放棄 cherry-pick：
git cherry-pick --abort
回到操作前的樣子，就像什么都沒發生過。
退出 cherry-pick：
git cherry-pick --quit
不回到操作前的樣子。即保留已經 cherry-pick 成功的 commit，并退出 cherry-pick 流程。
4.revert
將現有的提交還原，恢復提交的內容，并生成一條還原記錄。
應用場景
應用場景：有一天測試突然跟你說，你開發上線的功能有問題，需要馬上撤回，否則會影響到系統使用。這時可能會想到用 reset 回退，可是你看了看分支上最新的提交還有其他同事的代碼，用 reset 會把這部分代碼也撤回了。由于情況緊急，又想不到好方法，還是任性的使用 reset，然后再讓同事把他的代碼合一遍（同事聽到想打人），于是你的技術形象在同事眼里一落千丈。
命令使用
revert 普通提交
學會 revert 之后，立馬就可以拯救這種尷尬的情況。
現在 master 記錄如下：
revert 掉自己提交的 commit
git revert 21dcd937fe555f58841b17466a99118deb489212
因為 revert 會生成一條新的提交記錄，這時會讓你編輯提交信息，編輯完后 :wq 保存退出就好了。
再來看下最新的 log，生成了一條 revert 記錄，雖然自己之前的提交記錄還是會保留著，但你修改的代碼內容已經被撤回了。
revert 合并提交
在 git 的 commit 記錄里，還有一種類型是合并提交，想要 revert 合并提交，使用上會有些不一樣。
現在的 master 分支里多了條合并提交。
使用剛剛同樣的 revert 方法，會發現命令行報錯了。
為什么會這樣？在官方文檔中有解釋。
通常無法 revert 合并，因為您不知道合并的哪一側應被視為主線。此選項指定主線的父編號（從1開始），并允許 revert 反轉相對于指定父編號的更改
我的理解是因為合并提交是兩條分支的交集節點，而 git 不知道需要撤銷的哪一條分支，需要添加參數 -m 指定主線分支，保留主線分支的代碼，另一條則被撤銷。
-m 后面要跟一個 parent number 標識出"主線"，一般使用 1 保留主分支代碼。
git revert -m 1 <commitHash>
revert 合并提交后，再次合并分支會失效
還是上面的場景，在 master 分支 revert 合并提交后，然后切到 feature 分支修復好 bug，再合并到 master 分支時，會發現之前被 revert 的修改內容沒有重新合并進來。
因為使用 revert 后， feature 分支的 commit 還是會保留在 master 分支的記錄中，當你再次合并進去時，git 判斷有相同的 commitHash，就忽略了相關 commit 修改的內容。
這時就需要 revert 掉之前 revert 的合并提交，有點拗口，接下來看操作吧。
現在 master 的記錄是這樣的。
再次使用 revert，之前被 revert 的修改內容就又回來了。
5.reflog
如果說 reset --soft 是后悔藥，那 reflog 就是強力后悔藥。它記錄了所有的 commit 操作記錄，便于錯誤操作后找回記錄。
應用場景
應用場景：某天你眼花，發現自己在其他人分支提交了代碼還推到遠程分支，這時因為分支只有你的最新提交，就想著使用 reset --hard，結果緊張不小心記錯了 commitHash，reset 過頭，把同事的 commit 搞沒了。
沒辦法，reset --hard 是強制回退的，找不到 commitHash 了，只能讓同事從本地分支再推一次（同事瞬間拳頭就硬了，怎么又是你）。于是，你的技術形象又一落千丈。
命令使用
分支記錄如上，想要 reset 到 b。
誤操作 reset 過頭，b 沒了，最新的只剩下 a。
這時用 git reflog 查看歷史記錄，把錯誤提交的那次 commitHash 記下。
再次 reset 回去，就會發現 b 回來了。
6.rebase
當執行rebase操作時，git會從兩個分支的共同祖先開始提取待變基分支上的修改，然后將待變基分支指向基分支的最新提交，最后將剛才提取的修改應用到基分支的最新提交的后面
一、提交節點圖解
首先通過簡單的提交節點圖解感受一下rebase在干什么
構造兩個分支master和feature，其中feature是在提交點B處從master上拉出的分支
master上有一個新提交M，feature上有兩個新提交C和D
此時我們切換到feature分支上，執行rebase命令，相當于是想要把master分支合并到feature分支（這一步的場景就可以類比為我們在自己的分支feature上開發了一段時間了，準備從主干master上拉一下最新改動。模擬了git pull --rebase的情形）
# 這兩條命令等價于git rebase master feature
git checkout feature
git rebase master
下圖為變基后的提交節點圖，解釋一下其工作原理：
feature：待變基分支、當前分支
master：基分支、目標分支
當在feature分支上執行git rebase master時，git會從master和featuer的共同祖先B開始提取feature分支上的修改，也就是C和D兩個提交，先提取到。然后將feature分支指向master分支的最新提交上，也就是M。最后把提取的C和D接到M后面，注意這里的接法，官方沒說清楚，實際是會依次拿M和C、D內容分別比較，處理沖突后生成新的C’和D’。一定注意，這里新C’、D’和之前的C、D已經不一樣了，是我們處理沖突后的新內容，feature指針自然最后也是指向D’
rebase，變基，可以直接理解為改變基底。feature分支是基于master分支的B拉出來的分支，feature的基底是B。而master在B之后有新的提交，就相當于此時要用master上新的提交來作為feature分支的新基底。實際操作為把B之后feature的提交先暫存下來，然后刪掉原來這些提交，再找到master的最新提交位置，把存下來的提交再接上去（接上去是逐個和新基底處理沖突的過程），如此feature分支的基底就相當于變成了M而不是原來的B了。（注意，如果master上在B以后沒有新提交，那么就還是用原來的B作為基，rebase操作相當于無效，此時和git merge就基本沒區別了，差異只在于git merge會多一條記錄Merge操作的提交記錄）
上面的例子可抽象為如下實際工作場景：張三從B拉了代碼進行開發，目前提交了兩次，開發到D了；李四也從B拉出來開發了并且開發完畢，他提交到了M，然后合到主干上了。此時張三想拉下最新代碼，于是他在feature分支上執行了git rebase master，即把master分支給rebase過來，由于李四更早開發完并合了主干，如此就相當于張三是基于李四的最新提交M進行的開發了。
如果在rebase的時候提示有沖突，則處理沖突之后執行
git rebase --continue
