從0開始學習 GitHub 系列之「Git 進階」

閱讀本文大概需要 5 分鐘。

關於 Git 相信大家看了之前一系列的文章已經初步會使用了， 但是關於Git還有很多知識與技巧是你不知道的，今天就來給大家介紹下一些 Git 進階的知識。

我們知道我們進行的每一次 commit 都會產生一條 log，這條 log 標記了提交人的姓名與郵箱，以便其他人方便的查看與聯繫提交人，所以我們在進行提交代碼的第一步就是要設置自己的用戶名與郵箱。執行以下代碼：

git config --global user.name "stormzhang"

git config --global user.email "stormzhang.dev@gmail.com"

以上進行了全局配置，當然有些時候我們的某一個項目想要用特定的郵箱，這個時候只需切換到你的項目目錄，以上代碼把 --global 參數去除，再重新執行一遍就ok了。

PS：我們在 GitHub 的每次提交理論上都會在主頁的下面產生一條綠色小方塊的記錄，如果你確認你提交了，但是沒有綠色方塊顯示，那肯定是你提交代碼配置的郵箱跟你 GitHub 上的郵箱不一致，GitHub 上的郵箱可以到 Setting -> Emails 里查看。

我們知道我們執行的一些 Git 命令其實操作很頻繁的類似有：

git commit

git checkout

git branch

git status

...

這些操作非常頻繁，每次都要輸入完全是不是有點麻煩，有沒有一種簡單的縮寫輸入呢？比如我想直接輸入以下命令代替：

git c

git co

git br

git s

...

是不是很簡單快捷啊？這個時候就用到了 alias 了，翻譯過來就是別名的意思，輸入以下命令就可以直接滿足以上的需求。

git config --global alias.co checkout # 別名

git config --global alias.ci commit

git config --global alias.st status

git config --global alias.br branch

當然以上別名不是固定的，你完全可以根據自己的習慣去定製，除此之外還可以設置組合，比如：

git config --global alias.psm "push origin master"

git config --global alias.plm "pull origin master"

之後經常用到的 git push origin master 和 git pull origin master 直接就用 git psm 和 git plm 代替了，是不是很方便？

另外這裡給大家推薦一個很強大的 alias 命令，我們知道我們輸入 git log 查看日誌的時候是類似這樣的：

告訴大家一個比較屌的命令，輸入

git log --graph --pretty=format:"%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset" --abbrev-commit --date=relative

然後日誌這樣了：

是不是比較清晰，整個分支的走向也很明確，但是每次都要輸這麼一大串是不是也很煩？這時候你就該想到 alias 啊：

git config --global alias.lg "log --graph --pretty=format:"%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset" --abbrev-commit --date=relative"

這樣以後直接輸入 git lg 就行了。

當然還有一些其他有用的配置，默認情況下 git 用的編輯器是 vi ，如果不喜歡可以改成其他編輯器，比如我習慣 vim 。

git config --global core.editor "vim" # 設置Editor使用vim

你們如果喜歡其他編輯器可自行搜索配置，前提是本機有安裝。

有些人納悶我的終端怎麼有各種顏色顯示，自己卻不是這樣的，那是因為你們沒有開啟給 Git 輸出著色，輸入如下命令即可：

git config --global color.ui true

還有些其他的配置如：

git config --global core.quotepath false # 設置顯示中文文件名

以上的配置基本就差不多了，默認這些配置都在 ~/.gitconfig 文件下的，你可以找到這個文件查看自己的配置，也可以輸入 git config -l 命令查看。

diff 命令算是很常用的，使用場景是我們經常在做代碼改動，但是有的時候2天前的代碼了，做了哪些改動都忘記了，在提交之前需要確認下，這個時候就可以用diff來查看你到底做了哪些改動，舉個例子，比如我有一個 a.md 的文件，我現在做了一些改動，然後輸入 git diff 就會看到如下：

紅色的部分前面有個 - 代表我刪除的，綠色的部分前面有個 + 代表我增加的，所以從這裡你們能一目了然的知道我到底對這個文件做了哪些改動。

值得一提的是直接輸入 git diff 只能比較當前文件和緩存區文件差異，什麼是緩存區？就是你還沒有執行 git add 的文件。

當然跟暫存區做比較之外，他還可以有其他用法，如比較兩次 commit 之間的差異，比較兩個分支之間的差異，比較緩存區和版本庫之間的差異等，具體用法如下：

git diff <$id1> <$id2> # 比較兩次提交之間的差異

git diff <branch1>..<branch2> # 在兩個分支之間比較

git diff --staged # 比較暫存區和版本庫差異

我們知道 checkout 一般用作切換分支使用，比如切換到 develop 分支，可以執行：

git checkout develop

但是 checkout 不只用作切換分支，他可以用來切換 tag，切換到某次 commit，如：

git checkout v1.0

git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7

# 後面的一長串是commit_id，是每次commit的SHA1值，可以根據 git log 看到。

除了有「切換」的意思，checkout 還有一個撤銷的作用，舉個例子，假設我們在一個分支開發一個小功能，剛寫完一半，這時候需求變了，而且是大變化，之前寫的代碼完全用不了了，好在你剛寫，甚至都沒有 git add 進暫存區，這個時候很簡單的一個操作就直接把原文件還原：

git checkout a.md

這裡稍微提下，checkout 命令只能撤銷還沒有 add 進暫存區的文件。

設想一個場景，假設我們正在一個新的分支做新的功能，這個時候突然有一個緊急的bug需要修復，而且修復完之後需要立即發布。當然你說我先把剛寫的一點代碼進行提交不就行了么？這樣理論上當然是ok的，但是這會產品垃圾commit，原則上我們每次的commit都要有實際的意義，你的代碼只是剛寫了一半，還沒有什麼實際的意義是不建議就這樣commit的，那麼有沒有一種比較好的辦法，可以讓我暫時切到別的分支，修復完bug再切回來，而且代碼也能保留的呢？

這個時候 stash 命令就大有用處了，前提是我們的代碼沒有進行 commit ，哪怕你執行了 add 也沒關係，我們先執行

git stash

什麼意思呢？就是把當前分支所有沒有 commit 的代碼先暫存起來，這個時候你再執行 git status 你會發現當前分支很乾凈，幾乎看不到任何改動，你的代碼改動也看不見了，但其實是暫存起來了。執行

git stash list

你會發現此時暫存區已經有了一條記錄。

這個時候你可以切換回其他分支，趕緊把bug修復好，然後發布。之後一切都解決了，你再切換回來繼續做你之前沒做完的功能，但是之前的代碼怎麼還原呢？

git stash apply

你會發現你之前的代碼全部又回來了，就好像一切都沒發生過一樣，緊接著你最好需要把暫存區的這次 stash 記錄刪除，執行：

git stash drop

就把最近一條的 stash 記錄刪除了，是不是很方便？其實還有更方便的，你可以使用：

git stash pop

來代替 apply 命令，pop 跟 apply 的唯一區別就是 pop 不但會幫你把代碼還原，還自動幫你把這條 stash 記錄刪除，省的自己再 drop 一次了，雖然更方便，但是使用起來也需要更加謹慎，為了驗證你可以緊接著執行 git stash list 命令來確認是不是已經沒有該記錄了。

最後還有一個命令介紹下：

git stash clear

就是清空所有暫存區的記錄，drop 是只刪除一條，當然後面可以跟 stash_id 參數來刪除指定的某條記錄，不跟參數就是刪除最近的，而 clear 是清空。

我們知道 merge 分支是合併的意思，我們在一個 featureA 分支開發完了一個功能，這個時候需要合併到主分支 master 上去，我們只需要進行如下操作：

git checkout master

git merge featureA

其實 rebase 命令也是合併的意思，上面的需求我們一樣可以如下操作：

git checkout master

git rebase featureA

rebase 跟 merge 的區別你們可以理解成有兩個書架，你需要把兩個書架的書整理到一起去，第一種做法是 merge ，比較粗魯暴力，就直接騰出一塊地方把另一個書架的書全部放進去，雖然暴力，但是這種做法你可以知道哪些書是來自另一個書架的；第二種做法就是 rebase ，他會把兩個書架的書先進行比較，按照購書的時間來給他重新排序，然後重新放置好，這樣做的好處就是合併之後的書架看起來很有邏輯，但是你很難清晰的知道哪些書來自哪個書架。

只能說各有好處，不同的團隊根據不同的需要以及不同的習慣來選擇就好。

假設這樣一個場景，A和B兩位同學各自開了兩個分支來開發不同的功能，大部分情況下都會盡量互不干擾的，但是有一個需求A需要改動一個基礎庫中的一個類的方法，不巧B這個時候由於業務需要也改動了基礎庫的這個方法，因為這種情況比較特殊，A和B都認為不會對別人造成影響，等兩人各自把功能做完了，需要合併的到主分支 master 的時候，我們假設先合併A的分支，這個時候沒問題的，之後再繼續合併B的分支，這個時候想想也知道會有衝突了，因為A和B兩個人同時更改了同一個地方，Git 本身他沒法判斷你們兩個誰更改的對，但是這個時候他會智能的提示有 conflicts ，需要手動解決這個衝突之後再重新進行一次 commit 提交。我隨便在項目搞了一個衝突做下示例：

以上截圖裡就是衝突的示例，衝突的地方由 ==== 分出了上下兩個部分，上部分一個有 HEAD 的字樣代表是我當前所在分支的代碼，下半部分是一個叫 baidu_activity 分支的代碼，可以看到 HEAD 對 gradle 插件進行了升級，同時新增了一個插件，所以我們很容易判斷哪些代碼該保留，哪些代碼該刪除，我們只需要移除掉那些老舊代碼，而且同時也要把那些 <<< HEAD、==== 以及 >>>>>>baidu_activity 這些標記符號也一併刪除，最後進行一次 commit 就ok了。

我們在開發的過程中一般都會約定盡量大家寫的代碼不要彼此影響，以減少出現衝突的可能，但是衝突總歸無法避免的，我們需要了解並掌握解決衝突的方法。

點擊閱讀原文報名野狗技術沙龍

PS：昨天的文章是軟文，因為客戶要求不讓開評論，今天這裡說一下，雖然是軟文，但是極客學院絕對是正規的，相信不少人也看過他們網站的視頻，大家自己根據自身情況以及需要去判斷選擇就好。

相關文章：

「從0開始學習 GitHub 系列之「向GitHub 提交代碼」」

「從0開始學習 GitHub 系列之「Git速成」」

「從0開始學習 GitHub 系列之「加入 GitHub」」

「從0開始學習 GitHub 系列之「初識 GitHub」」