其实上一篇《开发中关于Git那些事》写的内容仅仅是Git的冰山一角，如果你认为Git就是简简单单的几行命令，那只能说明你还没有真正了解Git这个强大的内容寻址文件系统。这篇文章，还是接着介绍一些实用但是很少有人知晓的一些命令，好比说具有魔性的Git变基(git rebase)以及常用的GUI。
我之前询问过一些人，讨论到Git这块，他们当中有的直接使用GUI，说简单省事。其实，每一个GUI都有它的侧重点，并不是所有的GUI都适合用。我倒是建议大家使用命令行。何况有些功能GUI不一定支持，而且有时候一行命令的事，还要点来点去，也不省事。之前看到过一篇文章，是关于如何使用Vim编辑器的，对，大家平时开发习惯了IDE，爱上了IDE。但是好的程序员怎么会因为简单省事而放弃学习呢。这样说可能更好提现，学习任意一款IDE，你都需要耗时很久，但是如果你平时习惯了使用Vim编辑器，爱上用Vim编辑器写代码，那么任意一款集成Vim编辑器的IDE，一上来就会非常顺手。同样的道理，如果你了解了Git内部原理，平时习惯使用命令处理，那么给你任意一款GitGUI，相信你一看就会用，而且很快就上手。所以，学习顺序有时候很重要，基础扎实了，才不会被问题难倒，地基决定高度。
1.客户端配置
1.1 修改默认编辑器
默认使用Vim编辑器，当然可以使用core.editor修改
git config --global core.editor emacs
1.2 修改log分页
默认使用less，可以使用core.pager来设置为more或则其他，也可以使用空字符串，关闭分页，一次性加载所有内容
git config --global core.pager ''
1.3 Git 中的着色
使用到color.ui，默认auto，如果你不喜欢可以使用false关闭。
git config --global color.ui false
其实如果想具体到某些特定命令，都是有true、false 或 always可以设置的，比如以下
color.branch
color.diff
color.interactive
color.status
以上每个配置项都有子选项，它们可以被用来覆盖其父设置，以达到为输出的各个部分着色的目的。例如，为了让 diff 的输出信息以蓝色前景、黑色背景和粗体显示，你可以运行
git config --global color.diff.meta "blue black bold"
你能设置的颜色有:normal、black、red、green、yellow、blue、magenta、cyan 或 white。正如以 上例子设置的粗体属性，想要设置字体属性的话，可以选择包括:bold、dim、ul(下划线)、blink 、reverse(交换前景色和背景色)。
2.实用命令
git branch -v 该命令显示本地分支最后一次提交说明
* dev cdc7241a fixbug
master f586f6b5 ****
如果需要显示本地和远程，加上-a即git branch -v -a
* dev cdc7241a fixbug
master f586f6b5 ****
remotes/origin/HEAD -> origin/master
remotes/origin/dev cdc7241a fixbug
remotes/origin/master f586f6b5 ****
remotes/origin/oldIm 97d131bb 2.5.1 封版
git branch -vv 除了具有git branch -v命令的作用，还可以显示出每一个分支正在跟踪哪个远程分支，以及本地分支与远程分支是否是领先、落后。同样，如果想看远程加上-a，也就是all(所有)，反正我就是这么记忆的
* dev 6512ef90 [origin/dev: ahead 1] test
master 78b4b30a [origin/master] 171227122 2.12.2 封版
3.Git变基(Rebasing)
实用举例1
其实在Git当中整合两个分支的方式除了**merge**，还有一种方式，那就是**rebase**。如上图，现在要合并C3和C4，如果使用**merge**合并是这样子的。它会把两个分支的最新快照(C3 和 C4)以及二者最近的共同祖先(C2)进行三方合并，合并的结果是生成一个新的快照(并提交)。
但是如果使用**rebase**:你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上再应用一次。在 Git 中，这种操作就叫做**变基**。你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。
执行步骤就是，首先切换的experiment分支`git checkout experiment`，然后运行`git rebase master`，此时准备“重演”，接下来就是看你要在哪个分支重演，就切换到哪个分支，这边在主分支重演，切换到主分支`git checkout master`，然后整合即可`git merge experiment`。其实此时的**merge**和之前的**merge**不一样，这边的**merge**只需要进行一次**fast-forward**，就是快速合并，head快速前进到C4'。
它的原理是首先找到这两个分支(即当前分支 experiment、变基操作的目标基底分支 master)的最近共同祖 先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底C3, 最后以此将之前另存为临时文件的修改依序应用。
```git
git checkout experiment
git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
```
```git
git checkout master
git merge experiment
```
此时，C4' 指向的快照就和上面使用**merge**命令的例子中 C5 指向的快照一模一样了。这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是先后串行的一样，提交历史是一条直线没有分叉。
实用举例2
直接看下图，现在我有这样的需求，就是将C8，C9提交到主分支，但是不要C3，你如何做？
其实办法总是有的，在前篇文章中，有讲到git stash命令，其实，我们可以在client分支找到C3的哈希值直接执行git reset 哈希值(C3) 然后把C8，C9的修改直接git stash 贮存起来，切换到master分支，来个git stash pop搞定。现在我们使用变基来操作，感受下变基的魔性。
git rebase --onto master server client
以上命令含义：取出 client 分支，找出处于 client 分支和 server 分支的共同祖先之后的修改，然后把它们在 master 分支上重演一遍。
现在可以快进合并 master 分支了。
git checkout master
git merge client
实用举例3
再举一个例子，也是关于git rebase --onto的使用
H---I---J topicB
/
E---F---G topicA
/
A---B---C---D master
git rebase --onto master topicA topicB
H'--I'--J' topicB
/
| E---F---G topicA
|/
A---B---C---D master
This is useful when topicB does not depend on topicA.
这样的例子好多，感兴趣可以使用git rebase --help查看。
注意事项
这点一定要看，不要对在你的仓库外还有副本的分支执行变基。也就是说，一个人开发随便搞，多人开发有原则的搞。如果你不遵循这个原则，多人开发出现问题别来找我。
为什么呢？假如有个人在本地使用了merge合并分支后，push到了远程服务器，后来他感觉不爽，想通过变基处理，恰是这个时候你pull了服务器的代码，那就会出现问题。问题就是，以后看记录会出现相同的提交，本来张三想丢弃的东西被你保留了。如果想看详细举例，推荐查看Pro Git这本书中关于Git变基一节。
总之，只要是你的代码和你建立的分支，还没有执行push之前，随意搞，push后就不要再想着使用变基了，避免出问题。如果你更喜欢merge，喜欢看Git实际发生的事，那就使用merge吧。反之，你更喜欢流水线一样的记录，从前到后，没有一堆堆复杂的合并，那就用rebase。
4.GitGUI
十几款GUI，点开查看即可。
SourceTree
GitHub Desktop
TortoiseGit
GitUp
......
我比较喜欢GitUp，简洁些。但是我仍旧在使用命令行，就当为了给电脑省空间吧。