本文分享了我在開發工作中實踐過的實用命令。這些可以大大提高工作效率，解決很多困難場景。下面將對命令進行介紹，列出應用場景，用於手觸式教學，讓學生看完就能學會。
官方解釋:當妳想記錄工作目錄和索引的當前狀態，但又想返回壹個幹凈的工作目錄時，請使用git stash。該命令將保存本地修改並恢復工作目錄以匹配提交的文件頭。
Stash命令可以保存未提交的代碼，並使您的工作目錄幹凈。
我猜妳壹定在想:為什麽要幹凈？
應用場景:有壹天妳正在特性分支開發新的需求，突然產品經理過來說線上有bug，必須馬上修復。此時，您的函數已經開發了壹半，所以您想匆忙切到主分支，然後您會看到以下錯誤:
因為目前有文件被更改，所以在拆分分支之前，您需要提交commit以保持工作區的整潔。因為情況緊急，要匆忙提交，提交信息也是用“臨時代碼”寫的，所以分行提交記錄留下了黑歷史……(真人真事，我看過這個提交)
學了stash就不會這麽尷尬了。妳只需要:
就這麽簡單，代碼就保存了。
當您修復了在線問題並切換回特性分支時，您只需要恢復代碼:
當有多個存儲時，您可以指定操作存儲。首先，使用stash list列出所有記錄:
應用第二條記錄:
流行和下降是壹樣的。
隱藏代碼
填備註，或者不填直接輸入。
您可以在“貯藏”菜單中看到保存的貯藏。
首先單擊stash記錄旁邊的小箭頭，然後單擊apply或pop以恢復stash。
根本不要接觸索引文件或工作樹(但在所有模式下都要將標題重置為)。這會將您所有更改的文件更改為“要提交的更改”。
回滾您提交的提交，並將提交的修改內容放回臨時存儲區域。
壹般我們在使用reset命令的時候，會更多的提到git reset - hard，它可以強制提交記錄追溯到某個節點。而git reset - soft的功能也是顧名思義。-Soft(軟)不僅會回溯節點，還會保留節點的修改內容。
回溯節點，為什麽要保留修改過的內容？
應用場景1:有時候不小心提交了不該提交的內容。這時候想改回來，只能再犯，再加壹條“黑歷史”。
應用場景二:標準化的團隊壹般要求提交的內容職責明確、粒度細，便於後續的問題調查。將兩個具有不同功能的修改壹起提交是不規則的。這壹次，我的手又滑了壹下，壹次就犯了。
學習reset - soft後，您只需:
重置軟相當於後悔藥，給妳壹個改過自新的機會。對於上面的場景，您可以再次修改並重新提交以保持壹個幹凈的提交記錄。
上面是壹個還沒有被推送提交。也可以對已經推送的committed使用這個命令，但是再次推送的時候，因為遠程分支和本地分支有區別，所以需要強行推送git push -f來覆蓋reset committed。
還有壹點需要註意的是，當reset - soft指定提交號時，從提交到最近壹次提交的所有修改都將被恢復，而不僅僅是提交。
例如:
提交記錄是c、b和a。
重置為a。
這時頭部到了A，B和C的修改都回到了暫存區。
給定壹個或多個現有提交，應用每個提交引入的更改，並為每個提交記錄壹個新的提交。這要求妳的工作樹是幹凈的(沒有從頭提交任何更改)。
復制提交的提交，並將新的提交應用到分支。
提交已提交，為什麽需要復制新的？
應用場景1:有時候，版本的壹些優化需求正在開發中，開發的某個需求可能會臨時放上，或者要開發的需求因為某些原因卡在線上。這時候就需要把commit拿出來單獨處理了。
應用場景2:有時開發分支中的代碼記錄被汙染，導致開發分支合並到上線分支時出現問題。這時候就需要拉壹個幹凈的開發分支，然後把commit從舊的開發分支復制到新的分支。
復制單個
現在有壹個功能分支，提交記錄如下:
妳需要把B復制到另壹個分支，先復制commitHash，然後切到master分支。
當前主節點的最新記錄是a。使用cherry-pick將B應用於當前分支。
完成後看最新日誌。b已作為最新提交應用於主服務器。可以看到commitHash和之前的不壹樣，但是提交時間還是之前的。微信搜索微信官方賬號:java後端編程，回復:Java獲取信息。
重復倍數
以上是單次提交的副本。讓我們來看看如何挑選多個提交操作。
上述命令將commit1和commit2應用於當前分支。
上述命令將commit1到commit2範圍內的所有提交應用到當前分支(包括commit1和commit2)，commit1是最早的提交。
當cherry-pick有多個提交時，可能會遇到代碼沖突，然後cherry-pick會停止，讓用戶決定如何進行。讓我們看看如何解決這種情況。
仍然是特征分支，現在需要把C、D、E復制到主分支。先寫下起點c和終點e的commitHash。
切到主枝，用中間的櫻桃核。可以看到C復制成功。到D的時候發現代碼沖突，cherry-pick中斷。這時需要解決代碼沖突，重新提交到臨時存儲區。
然後使用cherry-pick - continue讓cherry-pick繼續。最後把e復制進去，整個過程就完成了。
以上是壹個完整的過程，但有時可能需要在代碼沖突後放棄或退出該過程:
回到手術前的樣子，若無其事。
不要回到手術前的樣子。也就是說，保留已經成功挑選的提交，並退出挑選過程。
給定壹個或多個現有提交，恢復由相關提交引入的更改，並記錄這些更改的壹些新提交。這要求妳的工作樹是幹凈的(從頭開始沒有變化)。
還原已有提交，還原已提交的內容，生成還原記錄。
應用場景:某天測試突然告訴妳，妳在網上開發的功能有問題，需要妳馬上撤銷，否則會影響系統的使用。這時候妳可能會想到用reset回滾，但是妳看分支上的最新提交和其他同事的代碼，用reset也會撤回這部分代碼。因為情況緊急，又想不出好辦法，妳還是任性的用reset，然後讓同事再結合他的代碼(同事壹聽就想打人)，所以妳的技術形象在同事眼中壹落千丈。
回復普通提交
學會revert後，可以立刻挽回這種尷尬的局面。
現在主記錄如下:
Revert放棄他自己提交的提交。
因為revert將生成新的提交記錄，所以此時會要求您編輯提交信息。編輯完成後，wq會保存並退出。
讓我們看看最新的日誌，並生成壹個恢復記錄。雖然您之前的提交記錄仍會保留，但您修改的代碼內容已被撤回。
在git的提交記錄中，還有另壹種類型的合並提交。如果您想要恢復到合並提交，使用起來會有些不同。
現在主分支中有壹個合並提交。
使用剛才相同的revert方法，您會發現命令行報告了壹個錯誤。為什麽會這樣？在官方文件中有解釋。
通常無法還原合並，因為妳不知道合並的哪壹方應該被視為主線。此選項指定主線的父編號(從1開始),並允許revert反轉相對於指定父編號的更改。
我的理解是，合並提交是兩個分支的交集，git不知道需要撤銷哪個分支。它需要添加參數-m來指定主分支，保留主分支的代碼，另壹個分支將被撤銷。
-m後面應該跟壹個母號來標識“主線”。壹般用1預留主支行代碼。
還是上面的場景，主分支revert合並提交後，然後在feature分支中修復bug，再合並到主分支中，妳會發現之前revert修改的內容並沒有再次合並。
因為在使用revert之後，特性分支的提交仍然會保留在主分支的記錄中。當您再次合並它時，git判斷有相同的commitHash，並忽略相關提交的修改內容。
這時候就需要先還原合並提交再還原，有點尷尬。接下來我們來看操作。
現在大師的戰績是這樣的。
如果您再次使用revert，以前通過revert修改的內容將會恢復。
該命令管理重錄中記錄的信息。
如果說reset - soft是後悔藥，那麽reflog就是強效後悔藥。它記錄了所有的提交操作記錄，方便在錯誤操作後檢索記錄。
應用場景:有壹天，妳眼花繚亂，發現自己已經在別人的分支裏提交了代碼，推送到遠程分支。這時候因為分支只有妳最新提交的，妳就想著用reset - hard，結果不小心記錯了commitHash，重置太多，同事的commit丟失了。沒辦法，reset - hard被逼退，找不到commitHash，只能讓同事從本地分公司再推壹次(同事拳頭瞬間硬了，又是妳)。結果妳的技術形象壹落千丈。
分支記錄如上，妳想重置為b。
復位誤操作太多，B沒了，最新的只有a。
此時，使用git reflog檢查歷史記錄，並記下提交錯誤的commitHash。
再次重置，妳會發現B又回來了。
對於我這個喜歡輸入命令而不是圖形工具的粉絲來說，設置短命令可以提高效率。以下是設置短命令的兩種方法。
打開全局配置文件
寫內容
本文主要分享五個在開發中比較實用的Git命令，以及設置短命令的方法。
文中列舉的壹些應用場景並不恰當，只是為了便於學生理解。最重要的是明白命令是什麽，這樣學習和使用才能發揮最大的效果。
好了，今天的分享就到這裏。下次見~