我有两个分支master
和DevMaster
。
假设我们在master中有一个文件,其引用为:src/AppFiles/Submissions/CompleteSubmission.java
DevMaster
中存在相同的文件。
从母版合并到DevMaster
时,即使上面的文件与母版中的文件存在相同,它也会将上述文件检测为新文件。这对我或我的团队都毫无意义。
编辑: 此外,我在该分支上进行了合并,即使我刚刚合并它,也仍然将所有内容检测为新的。
答案 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不会读取所有已经存在的文件。