当前位置:   article > 正文

git pull时产生'Merge branch 'master' of...问题

merge branch 'master' of

一、问题

在使用 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 'git@github.com: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.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

这个时候我们会选择,先 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内容是一致的。

该方法的优点:把分支的提交历史“整理”成一条直线,看上去更直观
该方法的缺点:本地的分叉提交已经被修改过了

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/很楠不爱3/article/detail/688666
推荐阅读
相关标签
  

闽ICP备14008679号