【问题标题】:Git pull overwrites and does not merge or acknowledge conflict on same branch (master)Git pull 覆盖并且不合并或确认同一分支(主)上的冲突
【发布时间】:2019-08-04 17:59:47
【问题描述】:

背景:

我有一个我认为很简单的场景。我已经在本地提交了更改,现在我想将远程、同一个分支(在我前面)中的内容合并到本地工作目录中。

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

我已阅读以下帖子:

  1. git merge overwrites contents
  2. Git merge master into development branch is overwriting, not merging

并尝试过这些命令:

  1. git pull --rebase 覆盖文件的本地版本
  2. git merge -s recursive -X ours 覆盖文件的本地版本
  3. git merge -s ours 提示提交消息,然后覆盖远程更改
  4. git rebase remotes/origin/master 说它将“重播我的工作”,但仍会覆盖它
  5. 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=======>>>>>>>)添加到相关文件中?

【问题讨论】:

  • 你能发布git config --list的输出吗?作为您链接笔记的第二个问题的答案,这可能会受到您的 git 配置的影响(请注意,仅查看 .git 是不够的,这不是 git 使用的唯一地方)。
  • 您究竟如何称呼覆盖?您能否编写一个非常小的模型更改,显示覆盖后得到的结果以及您期望的更好结果?
  • git merge origin/whatever。应该说“手动合并调用”,真的,或者根本没有提到它。 平时做什么在这里有点无关紧要
  • "fast forward" - 很确定您的更改已经在远程 master 上(如果文件内容错误,可能随后在其他提交中被覆盖),或者不在本地 master (一个不幸的git reset,或者你可能偶然在其他分支上工作,或者类似的东西)。抱歉,不能再继续了,现在是凌晨 3 点。这边。祝你好运!
  • 根据你git merge的输出,你的同事在合并东西时出错了

标签: git merge version-control git-merge git-merge-conflict


【解决方案1】:

怀疑对合并应该做什么有误解。 (注意重点,请耐心等待)

如果有的话,让我们清理一下。

我们最好专注于文件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"

请给我们更多反馈,我会进行修改以进行调整。 (不过可能是明天;-)

在 cmets 之后添加:

我非常同意无用的评论 below。我没有从您最初的问题中得知您和您同事的提交之间存在来回文件(正如您添加的here)。

现在恢复所需更改及其更改的解决方案可能是检查文件历史记录,然后从初始共享状态仔细重建内容,但根据您的上下文,很难就最佳公式提出建议。如果同事有空与您一起解决问题,您可能会避免很多麻烦。

尾声补充:

抱歉,结局有点苦涩,我完全理解你会更喜欢一个更能满足智力要求的答案/解决方案。我感谢您的赏金和所有有见地的 cmets 的其他人。

【讨论】:

  • 如果没有合并冲突,--ours 将没有要复制的第 2 阶段条目 - 您需要 git checkout HEAD -- views/footprint.handlebars
  • 让我尝试解决您的问题:该文件最初是由一位同事创作和推送的。然后我重写了大部分内容(文件特定日志输出中列出的最新提交)并推送。他继续修改他的版本,并在我修改后将其推送到服务器。文件中双方修改的点是直接冲突的——他的修改完全消除了我的。这就是我所说的“覆盖”。
  • @torek 感谢您的关注,我昨天写的有点晚了,我猜是匆忙写了 :-) 已编辑!
  • 如果你的同事在你重写后推送到服务器,问题可能在于他们如何解决that合并。也就是说,从 git 的角度来看,他们故意告诉它采用他们的版本。
  • 您一直声称存在冲突,但根本不清楚是否应该存在冲突。我强烈建议阅读 git 如何实际解决合并,因为它与您描述的期望完全不同。在同一个文件中进行更改并不自动意味着冲突。您需要知道自最后一个共同祖先以来每条路径上发生了什么变化,而您无法从目前所展示的线性历史中看出这一点。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-04-02
  • 2016-11-09
  • 1970-01-01
  • 2018-08-04
  • 1970-01-01
  • 1970-01-01
  • 2017-12-25
相关资源
最近更新 更多