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

时间:2019-04-29 15:04:25

标签: git merge git-merge

我有两个分支masterDevMaster

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

DevMaster中存在相同的文件。

从母版合并到DevMaster时,即使上面的文件与母版中的文件存在相同,它也会将上述文件检测为新文件。这对我或我的团队都毫无意义。

编辑: 此外,我在该分支上进行了合并,即使我刚刚合并它,也仍然将所有内容检测为新的。

3 个答案:

答案 0 :(得分:1)

所有合并工作均来自合并基础。合并基础是被合并的两个 1 提交中的“最佳”公共祖先提交。我认为,最简单的了解方法是在视觉上。绘制两个提示提交,以及标识它们的分支名称(或使用git log --decorate --oneline --graph branch1 branch2使Git垂直执行此操作)

     J  <-- branch1



     L  <-- branch2

跟随J(代表某种大的丑陋的提交哈希)回到其父节点I,并用L对其父节点K进行同样的操作:< / p>

  I--J  <-- branch1



  K--L  <-- branch2

重复执行,直到找到两个分支上的提交:

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

您找到的提交是合并基础。 (并非所有合并基准都像这样整齐而简单地显示!大多数图形都被缠结在一起。)

您可以让Git为您标识合并基础:

git merge-base --all branch1 branch2

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

一旦有了合并基础本身,合并过程就可以理解了。 Git运行两个 git diff命令:一个将合并基础提交与branch1的尖端进行比较,另一个将(相同)合并基础提交与{{ 1}}。这些差异指导Git将每个文件的每组更改组合在一起。

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

默认自动合并的结果(一个没有选项并且不停止编辑结果的操作)完全由三个输入提交决定。您不能仅将两个分支提示的提交与另一个彼此比较!您必须将每个分支提示的提交与(公共)合并基础进行比较。


1 如果是章鱼合并(两个以上提交的合并),则合并基数的计算会有所不同。

答案 1 :(得分:0)

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

答案 2 :(得分:0)

因此分支的远程版本正在进行一些有趣的业务。我通过@Angelo Mendes和@Marek R的建议在本地进行了合并(为什么标记在此页面上不起作用?),而在本地进行的合并仅检测到单个文件更改,这正是我们所期望的。为了解决这个问题,我将所有文件从远程分支拉到本地,删除了远程,然后将本地推到了远程。现在,新的PR不会读取所有已经存在的文件。