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

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

　　1. 用戶名和郵箱

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

　　git config --global user.name "stormzhang"

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

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

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

　　2. alias

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

　　git commit

　　git checkout

　　git branch

　　git status

　　...

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

　　git c

　　git co

　　git br

　　git s

　　...

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

　　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

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

　　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 代替了，是不是很方便?

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

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

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

　　是不是比較清晰，整個分支的走向也很明確，但是每次都要輸這么一大串是不是也很煩?這時候你就該想到 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

　　你們?nèi)绻矚g其他編輯器可自行搜索配置，前提是本機有安裝。

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

　　git config --global color.ui true

　　還有些其他的配置如：

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

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

　　4. diff

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

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

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

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

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

　　git diff .. # 在兩個分支之間比較

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

　　5. checkout

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

　　git checkout develop

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

　　git checkout v1.0

　　git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7

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

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

　　git checkout a.md

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

　　6. stash

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

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

　　git stash

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

　　git stash list

　　你會發(fā)現(xiàn)此時暫存區(qū)已經(jīng)有了一條記錄。

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

　　git stash apply

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

　　git stash drop

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

　　git stash pop

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

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

　　git stash clear

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

　　7. merge & rebase

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

　　git checkout master

　　git merge featureA

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

　　git checkout master

　　git rebase featureA

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

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

　　8. 解決沖突

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

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

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