從0開(kāi)始學(xué)習 GitHub 系列之「05.Git 進(jìn)階」

　　關(guān)于 Git 相信大家看了之前一系列的文章已經(jīng)初步會(huì )使用了， 但是關(guān)于Git還有很多知識與技巧是你不知道的，今天就來(lái)給大家介紹下一些 Git 進(jìn)階的知識。

　　1. 用戶(hù)名和郵箱

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

　　git config --global user.name "stormzhang"

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

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

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

　　2. alias

　　我們知道我們執行的一些 Git 命令其實(shí)操作很頻繁的類(lèi)似有：

　　git commit

　　git checkout

　　git branch

　　git status

　　...

　　這些操作非常頻繁，每次都要輸入完全是不是有點(diǎn)麻煩，有沒(méi)有一種簡(jiǎn)單的縮寫(xiě)輸入呢?比如我想直接輸入以下命令代替：

　　git c

　　git co

　　git br

　　git s

　　...

　　是不是很簡(jiǎn)單快捷啊?這個(gè)時(shí)候就用到了 alias 了，翻譯過(guò)來(lái)就是別名的意思，輸入以下命令就可以直接滿(mǎn)足以上的需求。

　　git config --global http://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'

　　之后經(jīng)常用到的 git push origin master 和 git pull origin master 直接就用 git psm 和 git plm 代替了，是不是很方便?

　　另外這里給大家推薦一個(gè)很強大的 alias 命令，我們知道我們輸入 git log 查看日志的時(shí)候是類(lèi)似這樣的：

　　告訴大家一個(gè)比較屌的命令，輸入

　　git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)然后日志這樣了：

　　是不是比較清晰，整個(gè)分支的走向也很明確，但是每次都要輸這么一大串是不是也很煩?這時(shí)候你就該想到 alias ?。?/p>

　　git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)

　　3. 其他配置

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

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

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

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

　　git config --global color.ui true

　　還有些其他的配置如：

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

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

　　4. diff

　　diff 命令算是很常用的，使用場(chǎng)景是我們經(jīng)常在做代碼改動(dòng)，但是有的時(shí)候2天前的代碼了，做了哪些改動(dòng)都忘記了，在提交之前需要確認下，這個(gè)時(shí)候就可以用diff來(lái)查看你到底做了哪些改動(dòng)，舉個(gè)例子，比如我有一個(gè) a.md 的文件，我現在做了一些改動(dòng)，然后輸入 git diff 就會(huì )看到如下：

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

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

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

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

　　git diff .. # 在兩個(gè)分支之間比較

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

　　5. checkout

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

　　git checkout develop

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

　　git checkout v1.0

　　git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7

　　# 后面的一長(cháng)串是commit_id，是每次commit的SHA1值，可以根據 git log 看到。

　　除了有“切換”的意思，checkout 還有一個(gè)撤銷(xiāo)的作用，舉個(gè)例子，假設我們在一個(gè)分支開(kāi)發(fā)一個(gè)小功能，剛寫(xiě)完一半，這時(shí)候需求變了，而且是大變化，之前寫(xiě)的代碼完全用不了了，好在你剛寫(xiě)，甚至都沒(méi)有 git add 進(jìn)暫存區，這個(gè)時(shí)候很簡(jiǎn)單的一個(gè)操作就直接把原文件還原：

　　git checkout a.md

　　這里稍微提下，checkout 命令只能撤銷(xiāo)還沒(méi)有 add 進(jìn)暫存區的文件。

　　6. stash

　　設想一個(gè)場(chǎng)景，假設我們正在一個(gè)新的分支做新的功能，這個(gè)時(shí)候突然有一個(gè)緊急的bug需要修復，而且修復完之后需要立即發(fā)布。當然你說(shuō)我先把剛寫(xiě)的一點(diǎn)代碼進(jìn)行提交不就行了么?這樣理論上當然是ok的，但是這會(huì )產(chǎn)品垃圾commit，原則上我們每次的commit都要有實(shí)際的意義，你的代碼只是剛寫(xiě)了一半，還沒(méi)有什么實(shí)際的意義是不建議就這樣commit的，那么有沒(méi)有一種比較好的辦法，可以讓我暫時(shí)切到別的分支，修復完bug再切回來(lái)，而且代碼也能保留的呢?

　　這個(gè)時(shí)候 stash 命令就大有用處了，前提是我們的代碼沒(méi)有進(jìn)行 commit ，哪怕你執行了 add 也沒(méi)關(guān)系，我們先執行

　　git stash

　　什么意思呢?就是把當前分支所有沒(méi)有 commit 的代碼先暫存起來(lái)，這個(gè)時(shí)候你再執行 git status 你會(huì )發(fā)現當前分支很干凈，幾乎看不到任何改動(dòng)，你的代碼改動(dòng)也看不見(jiàn)了，但其實(shí)是暫存起來(lái)了。執行

　　git stash list

　　你會(huì )發(fā)現此時(shí)暫存區已經(jīng)有了一條記錄。

　　這個(gè)時(shí)候你可以切換回其他分支，趕緊把bug修復好，然后發(fā)布。之后一切都解決了，你再切換回來(lái)繼續做你之前沒(méi)做完的功能，但是之前的代碼怎么還原呢?

　　git stash apply

　　你會(huì )發(fā)現你之前的代碼全部又回來(lái)了，就好像一切都沒(méi)發(fā)生過(guò)一樣，緊接著(zhù)你最好需要把暫存區的這次 stash 記錄刪除，執行：

　　git stash drop

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

　　git stash pop

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

　　最后還有一個(gè)命令介紹下：

　　git stash clear

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

　　7. merge & rebase

　　我們知道 merge 分支是合并的意思，我們在一個(gè) featureA 分支開(kāi)發(fā)完了一個(gè)功能，這個(gè)時(shí)候需要合并到主分支 master 上去，我們只需要進(jìn)行如下操作：

　　git checkout master

　　git merge featureA

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

　　git checkout master

　　git rebase featureA

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

　　只能說(shuō)各有好處，不同的團隊根據不同的需要以及不同的習慣來(lái)選擇就好。

　　8. 解決沖突

　　假設這樣一個(gè)場(chǎng)景，A和B兩位同學(xué)各自開(kāi)了兩個(gè)分支來(lái)開(kāi)發(fā)不同的功能，大部分情況下都會(huì )盡量互不干擾的，但是有一個(gè)需求A需要改動(dòng)一個(gè)基礎庫中的一個(gè)類(lèi)的方法，不巧B這個(gè)時(shí)候由于業(yè)務(wù)需要也改動(dòng)了基礎庫的這個(gè)方法，因為這種情況比較特殊，A和B都認為不會(huì )對別人造成影響，等兩人各自把功能做完了，需要合并的到主分支 master 的時(shí)候，我們假設先合并A的分支，這個(gè)時(shí)候沒(méi)問(wèn)題的，之后再繼續合并B的分支，這個(gè)時(shí)候想想也知道會(huì )有沖突了，因為A和B兩個(gè)人同時(shí)更改了同一個(gè)地方，Git 本身他沒(méi)法判斷你們兩個(gè)誰(shuí)更改的對，但是這個(gè)時(shí)候他會(huì )智能的提示有 conflicts ，需要手動(dòng)解決這個(gè)沖突之后再重新進(jìn)行一次 commit 提交。我隨便在項目搞了一個(gè)沖突做下示例：

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

　　我們在開(kāi)發(fā)的過(guò)程中一般都會(huì )約定盡量大家寫(xiě)的代碼不要彼此影響，以減少出現沖突的可能，但是沖突總歸無(wú)法避免的，我們需要了解并掌握解決沖突的方法。