如何避免git pull时产生Merge branch master of等类似操作
2019年 10月 15 日

如默

介绍

如题,在使用 Git 的进行代码版本控制的时候,往往会发现在 log 中出现 “Merge branch ‘master’ of …” 这句话,如下图所示。日志中记录的一般为开发过程中对代码的改动信息,如果出现过多例如上述描述的信息会造成日志的污染。

如图,此图为VS code中git history插件图

git history

git history

可以看到主分支不干净,节点很多、很乱

产生的原因

当多人合作开发一个项目时,本地仓库落后于远程仓库是一个非常正常的事情,可参考下图。

A-B-C(master)
\
D(origin/master)

具体情境如下:

我当前拉取的远端版本为 B,此时修改了代码,并在本地仓库 commit 一次,但并未 push 到远端仓库。 另一位开发者在 B 的基础上,同样 commit 了一次并 push 到远端仓库。那么这个时候,我再 push 自己的代码就会发生错误

这个时候我们会选择,先 pull,再 push。Ok,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 信息。这两种状态分别如下所示:

# fast-forword 
A-B-D(origin/master)
     \
      C(master)
# merge
A-B-C-E(master)
   \ /
    D(origin/master)

如何解决

通过百度,包括自己的实践,有三种方法

方法1

在执行git pull的时候加上--rebase参数,成功后在进行真正的merge操作。(如果有冲突需要手动解决)

方法2

这个方法操作以后可以一劳永逸。在你的 git bash 里执行git config --global pull.rebase true,这个配置就是告诉 git 在每次 pull 前先进行 rebase 操作。这种方法和方法1原理一样,只不过方法1是每次pull前都要手动操作。

方法3

不建议直接pull操作,建议在commit之后,先fetch一下,然后merge合并,最后执行 push命令

总结

rebase 使用不好会在 git bash 顶部出现(master|REBASE 1/1),此时执行git rebase --abort即可恢复
rebase 操作的的好处是你们团队的 commit message 时间线会成一条笔直的直线

如何避免git pull时产生Merge branch master of等类似操作

温馨提示:

本文最后更新于2019年10月15日,已超过1512天没有更新,若内容或图片失效,请留言反馈。

介绍

如题,在使用 Git 的进行代码版本控制的时候,往往会发现在 log 中出现 “Merge branch ‘master’ of …” 这句话,如下图所示。日志中记录的一般为开发过程中对代码的改动信息,如果出现过多例如上述描述的信息会造成日志的污染。

如图,此图为VS code中git history插件图

git history

git history

可以看到主分支不干净,节点很多、很乱

产生的原因

当多人合作开发一个项目时,本地仓库落后于远程仓库是一个非常正常的事情,可参考下图。

A-B-C(master)
\
D(origin/master)

具体情境如下:

我当前拉取的远端版本为 B,此时修改了代码,并在本地仓库 commit 一次,但并未 push 到远端仓库。 另一位开发者在 B 的基础上,同样 commit 了一次并 push 到远端仓库。那么这个时候,我再 push 自己的代码就会发生错误

这个时候我们会选择,先 pull,再 push。Ok,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 信息。这两种状态分别如下所示:

# fast-forword 
A-B-D(origin/master)
     \
      C(master)
# merge
A-B-C-E(master)
   \ /
    D(origin/master)

如何解决

通过百度,包括自己的实践,有三种方法

方法1

在执行git pull的时候加上--rebase参数,成功后在进行真正的merge操作。(如果有冲突需要手动解决)

方法2

这个方法操作以后可以一劳永逸。在你的 git bash 里执行git config --global pull.rebase true,这个配置就是告诉 git 在每次 pull 前先进行 rebase 操作。这种方法和方法1原理一样,只不过方法1是每次pull前都要手动操作。

方法3

不建议直接pull操作,建议在commit之后,先fetch一下,然后merge合并,最后执行 push命令

总结

rebase 使用不好会在 git bash 顶部出现(master|REBASE 1/1),此时执行git rebase --abort即可恢复
rebase 操作的的好处是你们团队的 commit message 时间线会成一条笔直的直线


赞 (0)

猜您想看

爱之初体验:phpstudy-linux面板(小皮面板)首次使用感受

前一阵子看到phpstudy发布了Linux面板,类似于宝塔,遂想体验一番。

01

铭瑄 RTX3060Ti iCraft OC 8G 独立显卡

前两天买了一个技嘉小雕 RX 6750XT ELITE 12G独立显卡,结果各种掉驱动,黑屏,打游戏听风扇狂转,虽然温度不高,但总感觉不踏实。趁还没过七天无理由,赶紧退了,换了N卡。

02

科普:如何才能享受200M光纤的网速?

平时家里的宽带都是几百兆,但是为什么网速不够呢,现在就来一探究竟

03

AWS亚马逊云入坑记录

作为云服务的老大,想来品质应该是可以的,听说有一年的免费主机,所以试试。

04

mindoc接口文档在线管理系统(使用宝塔面板安装配置教程)

本文以centOS7为例,介绍如何配置安装mindoc并使用宝塔面板配置

05

添加cmd和powershell到右键菜单的一键脚本

为了方便起见,将cmd或powershell添加到右键菜单,管理员和非管理员权限,特记录于此。

06

评论区(暂无评论)

这里空空如也,快来评论吧~

我要评论

Vaptcha 初始化中...