GitHub 系列之「Git 進階」
1.用戶名和郵箱
我們知道我們進行的每一次 commit 都會產生一條 log，這條 log 標記了提交人的姓名與郵箱，以便其他人方便的查看與聯系提交人，所以我們在進行提交代碼的第一步就是要設置自己的用戶名與郵箱。執行以下代碼：
git config --global user.name "stormzhang" git config --global user.email "[email protected]"
以上進行了全局配置，當然有些時候我們的某一個項目想要用特定的郵箱，這個時候只需切換到你的項目目錄，以上代碼把 --global 參數去除，再重新執行一遍就ok了。
PS：我們在 GitHub 的每次提交理論上都會在主頁的下面產生一條綠色小方塊的記錄，如果你確認你提交了，但是沒有綠色方塊顯示，那肯定是你提交代碼配置的郵箱跟你 GitHub 上的郵箱不一致，GitHub 上的郵箱可以到 Setting -> Emails 裏查看。
2.alias
我們知道我們執行的一些 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 就行了。
3.其他配置
當然還有一些其他有用的配置，默認情況下 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 命令查看。
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 # 比較暫存區和版本庫差異
5.checkout
我們知道 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 進暫存區的文件。
6.stash
設想一個場景，假設我們正在一個新的分支做新的功能，這個時候突然有一個緊急的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 是清空。
7.merge & rebase
我們知道 merge 分支是合並的意思，我們在一個 featureA 分支開發完了一個功能，這個時候需要合並到主分支 master 上去，我們只需要進行如下操作：
git checkout master
git merge featureA
其實 rebase 命令也是合並的意思，上面的需求我們一樣可以如下操作：
git checkout master
git rebase featureA
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了。
GitHub 系列之「Git 進階」