一、问题
在使用 Git 的进行代码版本控制的时候，往往会发现在 log 中出现 “Merge branch ‘master’ of …” 这句话，如下图所示。日志中记录的一般为开发过程中对代码的改动信息，如果出现过多例如上述描述的信息会造成日志的污染。
二、产生的原因
当多人合作开发一个项目时，本地仓库落后于远程仓库是一个非常正常的事情，可参考下图
具体情境如下：
我当前拉取的远端版本为 B，此时修改了代码，并在本地仓库 commit 一次，但并未 push 到远端仓库。
另一位开发者在 B 的基础上，同样 commit 了一次并 push 到远端仓库。那么这个时候，我再 push 自己的代码就会发生错误
To github.com:xxx/xxx.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to '[email protected]:xxx/xxx.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
这个时候我们会选择，先 pull（如果有冲突需要先解决冲突，再 push。push 成功，但是此时我们查看 log 就会发现除了我们自己提交的那条日志之外，会多出一条 “Merge branch ‘master’ of …”。
那么，为什么会出现这种现象呢？其实是与 Git 的工作原理有关，对 Git 比较了解的人应该会知道，无论是 pull、push 亦或是 merge 操作，其实背后都是有很多的不同的模式的。
在进行 pull 操作的同时，其实就是 fetch+merge 的一个过程。我们从 remote 分支中拉取新的更新，然后再合并到本地分支中去。
如果 remote 分支超前于本地分支，并且本地分支没有任何 commit 的，直接从 remote 进行 pull 操作，默认会采用 fast-forward 模式，这种模式下，并不会产生合并节点，也就是说不会产生多余的那条 log 信息
如果想之前那样，本地先 commit 后再去 pull，那么此时，remote 分支和本地会分支会出现分叉，这个时候使用 pull 操作拉取更新时，就会进行分支合并，产生合并节点和 log 信息。这两种状态分别如下图所示：
三、解决方法
- 方法一: 在执行git pull的时候加上–rebase参数。这参数的意思就是在合并代码之前，先执行变基操作，成功后在进行真正的merge操作。(如果有冲突需要手动解决)
- 方法二：在你的git bash里执行
git config --global pull.rebase true。这个配置就是告诉git在每次pull前先进行rebase操作。这种方法和方法1原理一样，只不过方法1是每次pull前都要手动操作。
四、git base 原理
以下图为例子：
现在我们本地库分支比远程库分支要超前3个提交。我们看到上图中git log是一条有分支线，如果我们直接push，整个代码是不会有任何问题的，但是会不好看！那么rebase操作就是修正这个log线，使得整个log变成一条直线。 现在我们已经把超前远程库3个commit了，这时候我们执行一下【git rebase】命令后，我们再把log打出来是下面这个样子的：
原本分叉的提交现在变成一条直线了。这样在log中的merge也没有了，清爽了许多！！！rebase的原理非常简单。观察上图，发现git把我们本地的提交挪动了位置，放到了f005ed4 (origin/master) set exit=1之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4内容是一致的。
该方法的优点：把分支的提交历史“整理”成一条直线，看上去更直观
该方法的缺点：本地的分叉提交已经被修改过了
