农民入党申请书gitpull时产⽣问题
⼀、问题
在使⽤ Git 的进⾏代码版本控制的时候，往往会发现在 log 中出现 “Merge branch ‘master’ of …” 这句话，如下图所⽰。⽇志中记录的⼀般为开发过程中对代码的改动信息，如果出现过多例如上述描述的信息会造成⽇志的污染。
⼆、产⽣的原因
当多⼈合作开发⼀个项⽬时，本地仓库落后于远程仓库是⼀个⾮常正常的事情，可参考下图
具体情境如下：
我当前拉取的远端版本为 B，此时修改了代码，并在本地仓库 commit ⼀次，但并未 push 到远端仓库。
睛怎么组词另⼀位开发者在 B 的基础上，同样 commit 了⼀次并 push 到远端仓库。那么这个时候，我再 push ⾃⼰的代码就会发⽣错误
:xxx/xxx.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to ':xxx/xxx.git'
师字组词
hint: Updates were rejected becau the remote contains work that you do
hint: not have locally. This is usually caud by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
1976年属龙是什么命
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的时候加上–reba参数。这参数的意思就是在合并代码之前，先执⾏变基操作，成功后在进⾏真正的merge 操作。(如果有冲突需要⼿动解决)
⽅法⼆：在你的git bash⾥执⾏git config --ba true。这个配置就是告诉git在每次pull前先进⾏reba操作。这种⽅法和⽅法1原理⼀样，只不过⽅法1是每次pull前都要⼿动操作。
绿色校园绘画四、git ba原理错的
以下图为例⼦：
现在我们本地库分⽀⽐远程库分⽀要超前3个提交。我们看到上图中git log是⼀条有分⽀线，如果我们直接push，整个代码是不会有任何问题的，但是会不好看！那么reba操作就是修正这个log线，使得整个log变成⼀条直线。 现在我们已经把超前远程库3个commit了，这时候我们执⾏⼀下【git reba】命令后，我们再把log打出来是下⾯这个样⼦的：
原本分叉的提交现在变成⼀条直线了。这样在log中的merge也没有了，清爽了许多reba的原理⾮常
下字成语
简单。观察上图，发现git把我们本地的提交挪动了位置，放到了f005ed4 (origin/master) t exit=1之后，这样，整个提交历史就成了⼀条直线。reba操作前后，最终的提交内容是⼀致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于d1be385 init hello，⽽是基于f005ed4 (origin/master) t exit=1，但最后的提交7e61ed4内容是⼀致的。
该⽅法的优点：把分⽀的提交历史“整理”成⼀条直线，看上去更直观
该⽅法的缺点：本地的分叉提交已经被修改过了
