要想使git产生整洁的提交历史有以下几种方法：
- 在你commit之前，先拉取远程仓库的代码，然后再commit你自己的代码，最后推送到远程仓库。
-
如果你没有创建自己的新分支，即在跟远程仓库相同的分支上做改动，并且commit了，那么当你从远程仓库拉取代码时，可以使用SourceTree的衍合（rebase）选项。
9.png - 如果你在本地创建了自己的新分支，做了改动，并且commit了，可以使用衍合（rebase）。假设远程仓库的分支是
master，你在本地又开了个新分支experiment，并在这个分支上做改动，commit改动。可以运行下面的命令。
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
$ git checkout master
$ git merge experiment
通过以上几种方法，可以使你提交的代码历史记录是一条线性且没有分叉的直线。
不过也要注意下衍合的风险。
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。
下面是我做的一些试验。如果你理解git的合并（merge）和衍合(rebase)，下面的试验就不用看了，我是之前不太理解这些概念，动手做了一下，才理解了一些的。
把远程仓库的项目拷贝到不同的目录（A和B），来模拟两个程序员对代码的改动。
- B做改动，推送到远程仓库；然后，A做改动，commit，然后从远程仓库拉取,推送到远程仓库。（这次有分叉）
1.png
- B做改动，推送到远程仓库；然后，A做改动, 从远程仓库拉取，然后commit，推送到远程仓库。(这次是直线的)
2.png
- B做改动，推送到远程仓库；然后，A做改动，commit，然后从远程仓库拉取。在master分支上做
git rebase master，推送到远程仓库。（这次有分叉）
3.png
- B做改动，推送到远程仓库；然后，在A的test0分支做改动，commit， A的master分支从远程仓库拉取，在A的test0分支执行
git rebase master;再在A的master分支执行git rebase test0。推送到远程仓库。(这次是直线的)
4.png
5.png
- B做改动，推送到远程仓库；然后，在A的test0分支做改动，commit， A的master分支从远程仓库拉取，A合并test0分支。推送到远程仓库。(这次有分叉)
6.png
- B做改动，推送到远程仓库；然后，在A的test0分支做改动，commit， A的master分支从远程仓库拉取，在A的master分支执行
git rebase test0。推送到远程仓库。(这次情况有点复杂)
7.png
- B做改动，推送到远程仓库；然后，在A的test0分支做改动，commit， A的master分支从远程仓库拉取，在A的test0分支执行
git rebase master;再在A的master分支执行git rebase test0。推送到远程仓库。(这次是直线的, 跟上面某一步是完全一样的，只不过是在之前所有的操作基础上做的)
8.png
- B做改动，推送到远程仓库；然后，A做改动，commit，然后从远程仓库拉取时用sourceTree的rebase选项,推送到远程仓库。（这次是直线的）
9.png
10.png
- A做改动，commit;B做改动，推送到远程仓库；然后，A从远程仓库拉取时用sourceTree的rebase选项,推送到远程仓库。（这次是直线的）
11.png
参考：
- Git 分支 - 分支的衍合
-
git-Merge-Rebase
这个是我自己建的博客，不过因为不懂前端，页面不好看，以后博客就写在简书了。
