有一种场景是经常发生的。
大家都基于develop拉出分支进行并行开发，这里的分支可能是多到数十个。然后彼此在进行自己的逻辑编写，时间可能需要几天或者几周。在这期间你可能需要时不时的需要pull下远程develop分支上的同事的提交。这是个好的习惯，这样下去就可以避免你在一个无用的代码上进行长期的开发，回头来看这些代码不是新的代码。甚至是会面临很多冲突需要解决，而这个时候你可能还需要对冲突的部分代码进行测试回归，这就很麻烦了。
那么我们来看一下你在pull时候需要习惯性的加上—rebase参数，这样可以避免很多问题。
--rebase的本意是想让事情的发展看起来很连续和优美，而不是多出很多无用的merge commit 。
我们来看一个场景，在有些时候pull代码的时候会有如下图所示的提示：
这个时候往往会习惯性地去”esc ：wq“，直接默认commit注释。
这种情况下，如果没有在最后release的时候合并掉这些无意义的commit，那么最后的release分支就会以非常丑陋的姿态示人。
这个问题的出现是正常的，我们来看下为什么会出现这个问题。
首先是正常情况下的分支commit路线：
当前develop分支上有三个commit。现在我们两个项目开始启动，需要分别拉出两个分支独立开发。
我们分别checkout –b 出来两个分支，独立开发互不干扰。正常情况下，如果这两个分支的改动都没有重贴或者冲突的时候，一切都很顺利的。（重贴 ? 指可以被系统自动合并的修改，冲突 ? 指需要你手动解决的出入。要重现这个现象还是有点小麻烦的，你要修改刚好可以重贴的位置，而不是直接导致冲突的地方）
但如果在develop_newfeature_authorcheck（D）里修改了点东西，push到develop。然后checkout 到develop_newfeature_apiwrapper（E），随后
git pull
这将会把develop_newfeature_authorcheck分支的修改直接拉下来于本地代码merge，且产生一个commit，也就是merge commit。
产生的merge commit前文已表，不美观的commit会随着每次git pull而在commit log中如期而至。但如果此时执行的是
git pull -- rebase
那么事情就不一样了。
--rebase 并不会产生一个commit提交，而是会将你的E commit附加到D commit的结尾处。在看commit log时，不会多出你所不知道的commit出来。
其实此处的F commmit是无意义的，它只是一个merge commit。而且这里面的message里面的branch日后也不存了，这些分支都会被清除掉。
