关于 Git 信任咱们看了之前一系列的文章现已开始会运用了， 可是关于Git还有许多常识与技巧是你不知道的，今日就来给咱们介绍下一些 Git 进阶的常识。
1. 用户名和邮箱
咱们知道咱们进行的每一次 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 里检查。
2. alias
咱们知道咱们履行的一些 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
当然以上别号不是固定的，你彻底能够依据自己的习气去定制，除此之外还能够设置组合，比方：
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)然后日志这样了：
是不是比较明晰，整个分支的走向也很明晰，可是每次都要输这么一大串是不是也很烦?这时分你就该想到 alias 啊：
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
你们假如喜爱其他编辑器可自行查找装备，条件是本机有装置。
有些人疑惑我的终端怎样有各种色彩显现，自己却不是这样的，那是由于你们没有敞开给 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 .. # 在两个分支之间比较
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了。
咱们在开发的过程中一般都会约好尽量咱们写的代码不要互相影响，以削减呈现抵触的或许，可是抵触总之无法防止的，咱们需求了解并把握处理抵触的办法。
