Git拉取覆盖并且不合并或确认同一分支（主节点）上的冲突

Question

背景：

我有一个简单的场景。我已经在本地提交了更改，现在我想将远程（在我前面的一个分支）中的内容合并到本地工作目录中。

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覆盖内容
2. Git将主合并到开发分支是覆盖，而不是合并

并尝试了以下命令：

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，=======，>>>>>>>）被添加到相关的文件？

Answer 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"

给我们更多反馈，我将进行调整。（不过可能是明天；-）

评论后加法：

我几乎无用下调评论同意以下。我从您最初的问题中得到的答案是，您和您的同事的提交之间确实存在往返文件（正如您在此处添加的那样）。

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

结语加法：

对不起，我的结局很痛苦，我完全理解您会更喜欢在智力上更令人满意的答案/解决方案。我感谢您的悬赏，也感谢所有其他人的深刻见解。