Git合并冲突仅由一个分支更改的文件 [英] Git merge conflicts on files that are changed by one branch only

查看:191
本文介绍了Git合并冲突仅由一个分支更改的文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在 http://github.com/ohcibi/prezto 上有zprezto的分支

I have a fork of zprezto at http://github.com/ohcibi/prezto

重现我的问题:

  1. git clone http://github.com/ohcibi/prezto
  2. cd prezto
  3. git checkout ohcibi(我有一个具有该名称的分支,这里没有错字!)
  4. git merge master
  5. 显示了很多冲突
  1. git clone http://github.com/ohcibi/prezto
  2. cd prezto
  3. git checkout ohcibi (i have a branch with that name, no typo here!)
  4. git merge master
  5. A bunch of conflicts are shown

提交日志显示,在ohcibi中只有3个提交是自4月26日左右的上一次合并提交以来的新提交.所有这3个提交都不会碰到任何冲突的文件(一个冲突的文件除外).

The commit log shows that there are only 3 commits in ohcibi that are new since the last merge commit which is around april 26th. All 3 of the commits do not touch any of the files that conflict (except one file where the confict is to be expected).

但是为什么合并会在其他文件上甚至在.gitmodules上发生冲突?

But why is that merge conflicting on the other files and even .gitmodules as well?

注意:我不需要解决合并冲突的帮助!我知道该怎么做,因此我故意没有在问题中添加git-merge-conflict-resolution-tag,因为这将是一个错误的标签(因此它不会丢失,请不要添加它!).我想知道为什么这些冲突会首先发生(鉴于冲突的文件在两个分支中都没有更改,这是我所知道的合并冲突的常见原因).

Note: I don't need help solving that merge conflict! I know how to do that and I deliberately did not add the git-merge-conflict-resolution-tag to that question as it would be a wrong tag (so it is not missing, don't add it!). I want to know why those conflicts happen in the first place (given that the conflicting files are *not* changed in both branches, which is the usual reason for a merge conflict, that I am aware of).

推荐答案

Git使用树上的三个点进行合并,分支的头部,要合并的分支的头部以及最近的共同祖先在两个中.如有疑问,可以运行merge-base plumbing命令以找出git在最新的共同祖先身上看到的内容.

Git uses three points on the tree in order to merge, your branch's head, the head of the branch you're merging in, and the most recent common ancestor of the two. When in doubt you can run the merge-base plumbing command to find out what commit git sees at the most recent common ancestor.

git merge-base <branch1> <branch2>

运行该命令,我发现合并库为4f87376b5

Running that command I find the mergebase to be 4f87376b5

自您上次将master合并到分支机构以来,已经不到5个月了.合并时,master指向2017年4月24日的提交. (现在是您当前合并的合并基础.)

It's been just shy of 5 months since you last merged master into your branch. When you merged, master was pointing to a commit made on 2017-04-24. (Which is now the merge-base for your current merge.)

自那时以来,在master分支上已经进行了123次提交,最近一次是在2017-09-19进行的.这123次提交可能与分支上137次提交中的任何更改(从master无法访问)发生冲突.

There have been 123 commits made on the master branch since that time, the most recent being made on 2017-09-19. These 123 commits can conflict with the changes in any of the 137 commits on your branch that are unreachable from master.

Git不在关注提交次数"或它们发生的时间和地点.它所要查看的是每个分支头与合并基数之间的累积差.您可以运行git diff 4f87376b5 ohcibigit diff 4f87376b5 origin/master来查看从合并的各个方面集成的更改范围.

Git isn't looking at the "number of commits" or when and where they happened. All it's looking at is the cumulative difference between each branch head and the merge base. You can run git diff 4f87376b5 ohcibi and git diff 4f87376b5 origin/master to see the scope of changes being integrated from each side of the merge.

这篇关于Git合并冲突仅由一个分支更改的文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆