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

1. 使用者名稱和郵箱

我們知道我們進行的每一次commit都會產生一條log，這條log標記了提交人的姓名與郵箱，以便其他人方便的檢視與聯絡提交人，所以我們在進行提交程式碼的第一步就是要設定自己的使用者名稱與郵箱。執行以下程式碼：

git config --global user.name "stormzhang"
git config --global user.email "[email protected]"

• 1
• 2
• 3

以上進行了全域性配置，當然有些時候我們的某一個專案想要用特定的郵箱，這個時候只需切換到你的專案，以上程式碼把 –global

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

2. alias

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

git commit
git checkout
git branch
git status
...

• 1
• 2
• 3
• 4
• 5
• 6

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

git c
git co
git br
git s
...

• 1
• 2
• 3
• 4
• 5
• 6

是不是很簡單快捷啊？這個時候就用到了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

• 1
• 2
• 3
• 4
• 5

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

git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'
 

• 1
• 2
• 3

之後經常用到的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"

• 1
• 2

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

3. 其他配置

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

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

• 1
• 2

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

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

git config --global color.ui true

• 1
• 2

還有些其他的配置如：

git config --global core.quotepath false # 設定顯示中文檔名

• 1
• 2

以上基本所有的配置就差不多了，預設這些配置都在 ~/.gitconfig 檔案下的，你可以找到這個檔案檢視自己的配置，也可以輸入 git config -l 命令檢視。

4. diff

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

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

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

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

git diff <$id1> <$id2>   # 比較兩次提交之間的差異
git diff <branch1>..<branch2> # 在兩個分支之間比較 
git diff --staged   # 比較暫存區和版本庫差異

• 1
• 2
• 3
• 4

5. checkout

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

git checkout develop

• 1
• 2

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

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

• 1
• 2
• 3

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

git checkout a.md

• 1
• 2

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

6. stash

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

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

git stash

• 1
• 2

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

git stash list

• 1
• 2

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

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

git stash apply

• 1
• 2

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

git stash drop

• 1
• 2

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

git stash pop

• 1
• 2

來代替 apply 命令，pop 跟 apply 的唯一區別就是 pop 不但會幫你把程式碼還原，還自動幫你把這條 stash 記錄刪除，省的自己再 drop 一次了，為了驗證你可以緊接著執行 git stash list 命令來確認是不是已經沒有記錄了。

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

git stash clear

• 1
• 2

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

7. merge & rebase

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

git checkout master
git merge featureA

• 1
• 2
• 3

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

git checkout master
git rebase featureA

• 1
• 2
• 3

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

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

8. 解決衝突

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

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

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