公眾號關注 「GitHubDaily」
設為 「星標」，每天帶你逛 GitHub！
大家好，我是小 G。
在座的各位應該都知道，Git 作為居家必備、團隊協作之利器，自從 Linus Torvalds 發布這款工具後，便一直受到各路開發者的喜愛。
不過，儘管如此，小 G 還是經常能在公眾號後臺，看到有不少水友留言反饋，說 Git 裡面太多乾巴巴，看起來非常枯燥無味的命令行，一旦幾天沒用，就很容易就忘得一乾二淨，希望 GitHubDaily 能出一些與 Git 相關的輔助教程，或者比較有趣、對小白比較友好的學習方式。
emmm.. 作為有求必應的小 G，當然是選擇儘可能滿足大家的一切要求啦。
幾天前，小 G 偶然在 Twitter 看到一篇文章：《CS Visualized: Useful Git Commands》。
作者是來自英屬哥倫比亞的小姐姐 Lydia Hallie，在這篇文章裡面，她通過生動形象的動畫，以更加直觀的方式，向開發者展示 Git 命令中的 merge、rebase、reset、revert、cherry-pick 等常用騷操作的具體原理。
接下來，小 G 會挑選幾個最簡單的例子，讓你們看看這位小姐姐是如何用動畫來進行展示的。
在開始之前，還是得先跟大家簡單說一下，這篇文章不算是針對小白萌新的 Git 初級入門文章，而是希望幫助有一定 Git 實操基礎的用戶，加深對具體 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 等一系列操作，這裡限於篇幅，就不跟大家一一講解啦。https://dev.to/lydiahallie/cs-visualized-useful-git-commands-37p1以上，就是今天跟大家的分享啦，最近也發現了幾個比較有意思的項目，小 G 正在把玩中，回頭玩的比較溜了，會在公眾號這邊撰文跟大家分享哈。擔心走丟的小夥伴，可以將 GitHubDaily 公眾號設為星標，我們下期再會。