1.說明

git merge、git rebase、git reset、git revert、git fetch、git pull、git reflog……
你知道這些 git 命令執(zhí)行的究竟是什么任務嗎？
如果你還有些分不清楚，那千萬不能錯過這篇文章。
在本文中，熟知JavaScript、TypeScript、GraphQL、Serverless、AWS、Docker和Golang的
21歲年輕軟件顧問Lydia Hallie通過動圖形式直觀地介紹了這些常用git命令的工作過程，
包你過目不忘。

盡管Git是一款非常強大的工具，但如果我說 Git 用起來簡直是噩夢，
大多數(shù)人也會認同我的說法。
我發(fā)現(xiàn)在使用Git時，在頭腦里可視化地想象它會非常有用：
當我執(zhí)行一個特定命令時，這些分支會如何交互，又會怎樣影響歷史記錄？
為什么當我在master上執(zhí)行硬重啟，
force push到原分支以及rimraf我們的.git文件夾時我的同事哭了？

我覺得創(chuàng)建一些最常用且最有用的Git命令的可視化示例會是一個完美的用例！
下面我將介紹的很多命令都有可選參數(shù)——你可以使用這些參數(shù)來改變對應命令的行為。
而我的示例只會涵蓋命令的默認行為，而不會添加（或添加太多）可選配置！

2.Merging合并

擁有多個分支是很方便的，這樣可以將不同的新修改互相隔離開，
而且還能確保你不會意外地向生產代碼推送未經許可或破損的代碼修改。
但一旦這些修改得到了批準許可，我們就需要將其部署到我們的生產分支中！

可將一個分支的修改融入到另一個分支的一種方式是執(zhí)行git merge。
Git可執(zhí)行兩種類型的合并：fast-forward 和 no-fast-forward。
現(xiàn)在你可能分不清，但我們馬上就來看看它們的差異所在。

2.1.Fast-forward (—ff)

在當前分支相比于我們要合并的分支沒有額外的提交（commit）時，
可以執(zhí)行 fast-forward 合并。
Git 很懶，首先會嘗試執(zhí)行最簡單的選項：fast-forward！
這類合并不會創(chuàng)建新的提交，
而是會將我們正在合并的分支上的提交直接合并到當前分支。

完美！現(xiàn)在，我們在dev分支上所做的所有改變都合并到了master分支上。
那么 no-fast-forward 又是什么意思呢？

2.2.No-fast-foward (—no-ff)

如果你的當前分支相比于你想要合并的分支沒有任何提交，
那當然很好，但很遺憾現(xiàn)實情況很少如此！
如果我們在當前分支上提交我們想要合并的分支不具備的改變，
那么git將會執(zhí)行no-fast-forward合并。

使用no-fast-forward合并時，
Git會在當前活動分支上創(chuàng)建新的merging commit。
這個提交的父提交（parent commit）即指向這個活動分支，
也指向我們想要合并的分支！

沒什么大不了的，完美的合并！
現(xiàn)在，我們在dev分支上所做的所有改變都合并到了master分支上。

3.Merge Conflicts合并沖突

盡管Git能夠很好地決定如何合并分支以及如何向文件添加修改，
但它并不總是能完全自己做決定。
當我們想要合并的兩個分支的同一文件中的同一行代碼上有不同的修改，
或者一個分支刪除了一個文件而另一個分支修改了這個文件時，
Git 就不知道如何取舍了。

在這樣的情況下，Git 會詢問你想要保留哪種選擇？
假設在這兩個分支中，我們都編輯了 README.md 的第一行。

如果我們想把dev合并到master，就會出現(xiàn)一個合并沖突：
你想要標題是 Hello! 還是 Hey!？

當嘗試合并這些分支時，Git 會向你展示沖突出現(xiàn)的位置。
我們可以手動移除我們不想保留的修改，保存這些修改，
再次添加這個已修改的文件，然后提交這些修改。

完成！盡管合并沖突往往很讓人厭煩，但這是合理的：
Git 不應該瞎猜我們想要保留哪些修改。

4.Rebasing變基

我們剛看到可通過執(zhí)行git merge將一個分支的修改應用到另一個分支。
另一種可將一個分支的修改融入到另一個分支的方式是執(zhí)行git rebase。

git rebase會將當前分支的提交復制到指定的分支之上。

完美，現(xiàn)在我們在 dev 分支上獲取了 master 分支上的所有修改。

變基與合并有一個重大的區(qū)別：
Git 不會嘗試確定要保留或不保留哪些文件。
我們執(zhí)行 rebase 的分支總是含有我們想要保留的最新近的修改！
這樣我們不會遇到任何合并沖突，
而且可以保留一個漂亮的、線性的 Git 歷史記錄。

上面這個例子展示了在 master 分支上的變基。
但是，在更大型的項目中，你通常不需要這樣的操作。
git rebase在為復制的提交創(chuàng)建新的hash時會修改項目的歷史記錄。

如果你在開發(fā)一個feature分支并且master分支已經更新過，那么變基就很好用。
你可以在你的分支上獲取所有更新，這能防止未來出現(xiàn)合并沖突。

5.Interactive Rebase交互式變基

在為提交執(zhí)行變基之前，我們可以修改它們！
我們可以使用交互式變基來完成這一任務。
交互式變基在你當前開發(fā)的分支上以及想要修改某些提交時會很有用。

在我們正在 rebase 的提交上，我們可以執(zhí)行以下 6 個動作：
reword：修改提交信息；
edit：修改此提交；
squash：將提交融合到前一個提交中；
fixup：將提交融合到前一個提交中，不保留該提交的日志消息；
exec：在每個提交上運行我們想要 rebase 的命令；
drop：移除該提交。

很棒！這樣我們就能完全控制我們的提交了。

如果你想要移除一個提交，只需 drop 即可。

如果你想把多個提交融合到一起以便得到清晰的提交歷史，那也沒有問題！
交互式變基能為你在 rebase 時提供大量控制，甚至可以控制當前的活動分支。

6.Resetting重置

當我們不想要之前提交的修改時，就會用到這個命令。
也許這是一個 WIP 提交或者可能是引入了 bug 的提交，
這時候就要執(zhí)行 git reset。

git reset能讓我們不再使用當前臺面上的文件，
讓我們可以控制 HEAD 應該指向的位置。

6.1.軟重置

軟重置會將HEAD移至指定的提交（或與 HEAD 相比的提交的索引），
而不會移除該提交之后加入的修改！

假設我們不想保留添加了一個style.css文件的提交9e78i，
而且我們也不想保留添加了一個index.js文件的提交035cc。
但是，我們確實又想要保留新添加的style.css和index.js文件！
這是軟重置的一個完美用例。

輸入git status后，
你會看到我們仍然可以訪問在之前的提交上做過的所有修改。
這很好，這意味著我們可以修復這些文件的內容，之后再重新提交它們！

6.2.硬重置

有時候我們并不想保留特定提交引入的修改。
不同于軟重置，我們應該再也無需訪問它們。
Git 應該直接將整體狀態(tài)直接重置到特定提交之前的狀態(tài)：
這甚至包括你在工作目錄中和暫存文件上的修改。

Git丟棄了9e78i和035cc引入的修改，
并將狀態(tài)重置到了ec5be的狀態(tài)。

7.Reverting還原

另一種撤銷修改的方法是執(zhí)行git revert。
通過對特定的提交執(zhí)行還原操作，
我們會創(chuàng)建一個包含已還原修改的新提交。

假設ec5be添加了一個index.js文件。
但之后我們發(fā)現(xiàn)其實我們再也不需要由這個提交引入的修改了。
那就還原ec5be提交吧！

完美！提交9e78i還原了由提交ec5be引入的修改。
在撤銷特定的提交時，git revert 非常有用，
同時也不會修改分支的歷史。

8.Cherry-picking揀選

當一個特定分支包含我們的活動分支需要的某個提交時，
我們對那個提交執(zhí)行 cherry-pick！
對一個提交執(zhí)行 cherry-pick 時，
我們會在活動分支上創(chuàng)建一個新的提交，
其中包含由揀選出來的提交所引入的修改。

假設dev分支上的提交76d12為index.js文件添加了一項修改，
而我們希望將其整合到master分支中。
我們并不想要整個dev分支，而只需要這個提交！

現(xiàn)在master分支包含76d12引入的修改了。

9.Fetching取回

如果你有一個遠程 Git 分支，比如在 GitHub 上的分支，
當遠程分支上包含當前分支沒有的提交時，可以使用取回。
比如當合并了另一個分支或你的同事推送了一個快速修復時。

通過在這個遠程分支上執(zhí)行git fetch，
我們就可在本地獲取這些修改。
這不會以任何方式影響你的本地分支：
fetch 只是單純地下載新的數(shù)據(jù)而已。

現(xiàn)在我們可以看到自上次推送以來的所有修改了。
這些新數(shù)據(jù)也已經在本地了，
我們可以決定用這些新數(shù)據(jù)做什么了。

10.Pulling拉取

盡管git fetch可用于獲取某個分支的遠程信息，
但我們也可以執(zhí)行 git pull。
git pull 實際上是兩個命令合成了一個：
git fetch 和 git merge。
當我們從來源拉取修改時，
我們首先是像 git fetch 那樣取回所有數(shù)據(jù)，
然后最新的修改會自動合并到本地分支中。

很好，我們現(xiàn)在與遠程分支完美同步了，
并且也有了所有最新的修改！

11.Reflog操作日志

每個人都會犯錯，但犯錯其實沒啥！
有時候你可能感覺你把git repo完全搞壞了，
讓你想完全刪了了事。

git reflog是一個非常有用的命令，
可以展示已經執(zhí)行過的所有動作的日志。
包括合并、重置、還原，基本上包含你對你的分支所做的任何修改。

如果你犯了錯，你可以根據(jù)reflog 提供的信息通過重置HEAD來輕松地重做！

假設我們實際上并不需要合并原有分支。
當我們執(zhí)行 git reflog 命令時，
我們可以看到這個 repo 的狀態(tài)在合并前位于 HEAD@{1}。
那我們就執(zhí)行一次git reset，將 HEAD 重新指向在 HEAD@{1} 的位置。

我們可以看到最新的動作已被推送給reflog。

12.原文鏈接：

工作流一目了然，看小姐姐用動圖展示10大Git命令
CS Visualized: Useful Git Commands