GIT将现有文件合并为“新”答案

【问题标题】：GIT Merging Existing File as "New"GIT将现有文件合并为“新”
【发布时间】：2019-04-29 15:04:24
【问题描述】：

我有两个分支，master 和 DevMaster。

假设我们在 master 中有一个文件，其引用为：src/AppFiles/Submissions/CompleteSubmission.java

DevMaster 中存在相同的文件。

当从 master 合并到 DevMaster 时，它会将上面的文件检测为一个新文件，即使它与 master 中的文件相同。这对我或我的团队来说毫无意义。

编辑：此外，我在该分支上进行了合并，但即使在我刚刚合并之后，所有内容仍然被检测为新的。

【问题讨论】：

如果 git 认为它是新的，那么文件已被删除。
在合并前更新分支。使用git fetch。
从命令行执行并复制控制台的粘贴内容。您的命令和 git 响应。以git status 开头和结尾。
Windows？我敢打赌文件的名称在大小写中是不同的......所以对于 git 这将是两个不同的文件。

标签： git merge git-merge

【解决方案1】：

所有的合并工作都来自一个合并基础。合并基础是被合并的两个¹ 提交的“最佳”共同祖先提交。我认为，理解这一点的最简单方法是视觉。画出两个提示提交，以及标识它们的分支名称（或使用git log --decorate --oneline --graph branch1 branch2 让 Git 垂直执行此操作）：

     J  <-- branch1



     L  <-- branch2

按照J（代表一些丑陋的提交哈希）返回其父级I，并对L 执行相同操作至其父级K：

  I--J  <-- branch1



  K--L  <-- branch2

重复直到你找到一个在两个分支上的提交：

  I--J  <-- branch1
 /
H
 \
  K--L  <-- branch2

您找到的提交是合并基础。（并不是所有的合并基础都会像这样简洁明了地显示出来！大多数图表都非常混乱。）

您可以让 Git 为您识别合并基础：

git merge-base --all branch1 branch2

会告诉你合并基础是什么，只要你在运行git merge 之前运行它之前。（之后，两个分支名称之一指向新的 merge commit，合并基础只是另一个分支/提交。）如果您想查看什么，请在合并后使用原始提交哈希合并基础是。

一旦你有了合并基础，合并过程就变得容易理解了。 Git 运行两个 git diff 命令：一个将合并基本提交与branch1 的提示进行比较，另一个将（相同的）合并基本提交与branch2 的提示进行比较。这些差异指导 Git 将每组更改组合到每个文件。

如果合并基础提交没有两个分支提示中都存在某个文件，则该文件存在add/add 冲突：它在两个分支中都是全新的，Git 不知道如何合并这两个文件，除非它们完全匹配。

默认自动合并的结果（一个没有选项且没有停止编辑结果的结果）完全由三个输入提交决定。您不能只将两个分支提示提交相互比较！您必须将每个分支提示提交与（公共）合并基础进行比较。

¹在 octopus 合并的情况下 - 两个以上提交的合并 - 合并基础的计算方式略有不同。

【讨论】：

【解决方案2】：

@marcel 首先检查文件是否被推送到远程。在 bitbucket 浏览器客户端上验证它。

【讨论】：

我对此完全不熟悉。

【解决方案3】：

因此，分支的远程版本发生了一些有趣的事情。我通过@Angelo Mendes 和@Marek R 的建议在本地进行了合并（为什么标签在此页面上不起作用？）并且我本地的合并仅检测到单个文件更改，这是我们预期的。为了解决这个问题，我将远程分支中的所有文件拉到本地，删除远程，然后将本地推送到远程。现在新的 PR 不会读取所有已经存在的文件。

【讨论】：