Git pull会覆盖同一分支（主分支）上的内容，而不是合并或确认冲突。

Question

Git pull会覆盖同一分支（主分支）上的内容，而不是合并或确认冲突。

gitmergeversion-controlgit-mergegit-merge-conflict

9

背景：

我认为这是一个简单的场景。我已经在本地提交了更改，现在我想将远程分支（领先于我）上的内容合并到本地的工作目录中。

git branch -vv --list --all 的输出如下：

  master                79d9d4e [origin/master: behind 7] Footprint UI working
  remotes/origin/HEAD   -> origin/master
  remotes/origin/master a86a1a9 Added sample data to webpage

我希望合并其中的一个文件。以下是差异：

git diff --stat a86a1a9 79d9d4e views/footprint.handlebars

views/footprint.handlebars | 65 +++++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 33 insertions(+), 32 deletions(-)

但是当我运行 git pull 命令时，本地提交的文件版本被远程覆盖了。更详细地说：

$ git fetch -v origin  

From github.com:githubusername/foo
 = [up to date]      master     -> origin/master

$ git merge origin  
Updating 79d9d4e..a86a1a9
Fast-forward
...
 views/footprint.handlebars    | 65 ++++++++++++++++++++++++++++++++---------------------------------
...
 6 files changed, 220 insertions(+), 59 deletions(-)
 create mode 100644 static/search.js
 create mode 100644 views/search.handlebars

我已阅读以下帖子：

我尝试了以下命令：

git pull --rebase 会覆盖文件的本地版本
git merge -s recursive -X ours 会覆盖本地文件的版本
git merge -s ours 提示输入提交信息，然后覆盖远程更改
git rebase remotes/origin/master 表示将在“head”上“重放我的工作”，但仍会覆盖它
git merge --no-ff --no-commit当覆盖文件时，字面上报告“自动合并进行得很好；根据要求停止提交”

（在运行上述每个命令后，我检查了相关文件，并注意到它被覆盖，然后运行了 git reset --hard master@{"5 minutes ago"}）

$ git config --list  

redential.helper=osxkeychain
user.name=My Name
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.precomposeunicode=true
remote.origin.url=git@github.com:githubusername/foo.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
user.email=email@address.com
remote.heroku.url=https://git.heroku.com/foo.git
remote.heroku.fetch=+refs/heads/*:refs/remotes/heroku/*

$ git log --oneline --decorate --simplify-by-decoration --all -10  

a86a1a9 (origin/master, origin/HEAD) Added sample data to webpage
79d9d4e (HEAD -> master) Footprint UI working
c53160d Initial commit

$git log --format="%h %ci %cn" views/footprint.handlebars

79d9d4e 2019-03-12 19:04:08 -0400 chb
fada3fa 2019-03-10 13:59:41 -0700 JA
9641499 2019-03-08 16:48:14 -0800 JA
1759509 2019-03-08 12:32:08 -0800 GitHub
bfe443e 2019-03-07 16:41:18 -0800 JA

git version 2.17.2 (Apple Git-113)

问题:

为什么git没有将此冲突标记为冲突并在相关文件中添加适当的标记(<<<<<<< HEAD, =======, >>>>>>>)？

- chb

1

你可以发布git config --list的输出吗？就像你所链接的第二个问题的答案所指出的那样，这可能会受到你的 git 配置的影响（请注意，仅查看 .git 是不够的，那不是 git 使用的唯一位置）。 - Michail

1

git merge origin/whatever。其实应该说“手动合并调用”，或者干脆不提。我通常做什么在这里有点不相关。 - Michail

1

“快进” - 很确定你的更改已经在远程master上了（如果文件内容有误，则可能已被其他提交覆盖），或者不在本地master上（不幸的是 git reset，或者可能是你不小心在其他分支上工作，或者类似的情况）。抱歉，我无法继续了，这里已经是凌晨3点了。祝你好运！ - Michail

2

根据您的 git merge 输出，您的同事在合并时犯了一个错误。 - Ferrybig

1

运行以下命令并在此处发布您的输出：git log --graph --full-history --all --date=format:'%Y-%m-%d %H:%M:%S, %a' --format='%h %d%n%x09%x09 %C(blue bold)%an%Creset, %C(magenta)%ad (%ar)%Creset:%n%x09%x09 %Cgreen"%s"' $(git reflog show --format=%h stash 2>/dev/null || :) 我的理论与 @RomainValeri 相同。我假设 git 只是进行了快进，因为历史记录中有一些合并会显示为什么会发生这种情况。 - Julian

显示剩余11条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Romain Valeri · Accepted Answer

我怀疑关于合并的一些误解。(注意强调，稍等片刻)

如果有的话，我们需要澄清一下。

我们最好关注文件 views/footprint.handlebars。在初始提交和您的本地提交之间是否更改了它？在初始提交和 origin/master 之间是否更改了它？还是都有更改？

如果您没有更改它，那么合并后您的文件反映其更改是预期的。

如果他们没有更改它，但是在合并后您的更改版本被来自初始提交的“旧”版本覆盖，这就是一个需要调查的奇怪行为。

如果您和他们都对文件进行了更改，但在不冲突的不同点上进行了更改，则最终结果应包含双方的更改，而没有冲突。我不会称其为“被覆盖”。

最后，如果您确实想要保留此文件与您最近的本地提交完全相同的状态，您必须（像您所暗示的那样）使合并产生冲突，但这并不是什么大不了的事:

git checkout master
git fetch
git merge --no-commit origin/master
git checkout HEAD -- views/footprint.handlebars
git commit -am "Kept file views/footprint.handlebars as per commit 79d9d4e"

请给我们更多反馈，我会进行编辑以进行调整。（可能要等到明天才能完成;-)）

评论后的添加：

我基本上同意Useless在下面的评论。我没有从你最初的问题中得知你和你的同事提交的“同一文件”之间存在来回交流（如你在这里所补充的）。

现在恢复你所需的更改和他们的解决方案可能是检查文件历史记录，然后仔细从初始共享状态重新构建内容，但根据你的上下文很难建议最佳公式。如果同事能够与你一起解决，你很可能会避免很多麻烦。

结语添加：

对于这个有些苦涩的结局，我表示抱歉，我完全理解你希望得到更具智力满足感的答案/解决方案。感谢你的慷慨奖励，也感谢所有人的建设性评论。