在座的各位應該都知道，Git 作為居家必備、團隊協作之利器，打從 Linus Torvalds 發佈這款工具時起，便一直受到各路開發者的喜愛。
不過，儘管如此， Git 裡面太多幹巴巴，看起來非常枯燥無味的命令行，一旦幾天沒用，就很容易就忘得一乾二淨，希望 能出一些與 Git 相關的輔助教程，或者比較有趣、對小白比較友好的學習方式。
emmm.. 儘可能滿足大家的一切要求啦。
幾天前，偶然在 Twitter 看到一篇文章：《CS Visualized: Useful Git Commands》。
作者是來自英屬哥倫比亞的小姐姐 Lydia Hallie，在這篇文章裡面，她通過生動形象的動畫，以更加直觀的方式，向開發者展示 Git 命令中的 merge、rebase、reset、revert、cherry-pick 等常用騷操作的具體原理。
接下來，小 G 會挑選幾個最簡單的例子，讓你們看看這位小姐姐是如何用動畫來進行展示的。
在開始之前，還是得先跟大家簡單說一下，這篇文章不算是針對小白萌新的 Git 初級入門文章，而是希望幫助有一定 Git 實操基礎的用戶，加深對具體 Git 命令的操作理解。
對 Git 不太熟悉的小夥伴，可看我們此前在公眾號上分享的這幾篇文章：
- 強烈推薦下 GitHub 官方的這個教程
- 收好這份 Git 命令應急手冊，關鍵時刻可保你一命
- 寓教於樂，用玩遊戲的方式學習 Git！
嗯，下面開始進入正題。
合併（Merge）
我們都知道，在使用 Git 做日常開發項目的時候，都會選擇將項目切換成多個分支，在不同分支上處理不同事務。最簡單的，就是開發、測試、生產等幾個不同環境來回切換，使得項目管理與產品迭代更為輕鬆，亦可最大化避免項目出現嚴重漏洞時所帶來的傷害。
當我們在不同分支開發完代碼後，會選擇將分支進行合併（merge）。平時常用的 git merge 操作，又可分為這兩種類型：fast-forwar 和no-fast-forward。
fast-forward
一般情況下，Git 會默認使用 fast-forward 這種類型來處理分支合併，當我們成功合併後，不會產生任何提交記錄，且當舊分支被移除後，其分支信息也會被一併刪除。
通過動畫的方式展示，就像下面這樣：
no-fast-forward
而當我們使用 no-fast-forward 模式，即在合併分支命令加入 --no-ff 後綴的方式運行時，便會生成一個新的提交記錄，就像下面這樣：
合併衝突
在我們日常進行團隊協作開發的時候，總會出現同個文件在不同分支上被同時編輯的情況。
這樣，當我們提交代碼的時候，比較晚提交的另一方，在運行 Git 命令時就會報衝突錯誤。在正常情況下，只要我們手動處理下衝突文件，然後再重新提交即可。
打個比方，現在代碼倉庫有個 README 文件，在同一行的位置，在不同分支上被編輯了，如下所示：
那麼，使用合併命令，及修復衝突的過程，用動畫的形式展示，看起來就像下面這樣：
可以看到，在移除多餘的提示代碼後，會重新產生一條新的提交記錄。
Rebase
在進行分支合併前，我們一般會先使用pull命令拉取線上的最新代碼，在保證無任何衝突發生的前提下，再進行分支合併。
但是，這種代碼拉取方式是最為簡單粗暴的，通過這種方式合併，會使得整個提交記錄看起來特別亂，不太直觀與優雅。
因此，對 Git 使用比較規範、追求比較高的程序員，都會先使用rebase整理下提交記錄，再提交代碼，經過這樣處理後的 Git 提交記錄，看著就比直男還直了。
以動畫的方式呈現，就像下面這樣：
可以清晰的看到，原本對接在 master 分支第二處的 dev 分支，被對接到頂部了。
Hard Reset
日常開發中，我們可能會因為提交了某些無用代碼而進行回滾操作。通常在只有一個人獨立開發的項目情況下，會選用--hard命令來進行回滾處理。
不過，這種操作方式有個不好的地方，在多人協作的時候，這麼搞很容易使分支出現衝突，或直接毀掉別人的提交記錄。
hard reset以動畫的形式表現，看起來就像下面這樣：
除此之外，小姐姐還提到了 Reverting、Cherry-picking、Fetch 等一系列操作，這裡限於篇幅，就不跟大家一一講解啦。
--
以上，就是今天跟大家的分享啦，最近也發現了幾個比較有意思的項目
