根据文件,它应该模拟一个合并,这将发生在你合并公关。。。
这不是一个
模拟的
合并相反,GitHub实际上
合并了
.
我本以为这会模拟与main的HEAD合并,但如果与历史上一个奇怪的commit合并的话。
合并,在Git中(因此也在GitHub中)
1.
),而不是
树枝
.这是因为从重要的意义上说,分支甚至
存在
用吉特。
合并提交
肯定
做
存在,所以如果我们绕过这个困惑
"what exactly is a branch anyway"
提问并直接进入合并提交,我们可以很容易地讨论:
-
A.
合并
提交与常规提交非常相似。常规提交有一个快照,即您(或任何人)提交时出现的每个文件的完整副本,以及元数据,用于说明提交人、提交时间等。
-
数据库的元数据
典型的
commit有一个
单亲提交哈希ID
储存在里面。这将提交链接在一起,形成一个向后看的链。这一连串的承诺
是
Git存储库中的历史:提交就是历史;历史不过是一系列的承诺。
-
数据库的元数据
合并
commit使提交成为合并提交:它列出
二
父母
3.
这两个家长的承诺是
二者都
GitHub用作
第一
父母是承诺
是
在您(或任何人)发布拉取请求时,“基本分支”(GitHub特有的术语)的提示。GitHub将用作
第二
在你(或任何人的)公关的顶端,父母是提交人。从那时起,其他人有可能向“基本分支”添加新的提交。测试合并是对的
古老的
分支提示提交。任何承诺,一旦做出,都可以
,所以这个测试合并永远是这样的。你的未来
真实的
合并,如果你这样做,
可能不同:
不同的提交,具有不同的哈希ID和不同的父级。未来实际合并的第一个父级将是GitHub进行最终合并时的分支尖端;未来实际合并的第二个父级将是拉取请求的提示,您可以从现在到那时更新它。
您是否以及何时应该使用此测试合并,或者进行自己的合并,这只是一个问题
你
我能回答。你控制着这里:
你
选择你可以用
refs/pull/534/head
参考PR本身的提示提交(测试合并中的父级#2),如果存在,可以使用
refs/pull/534/merge
参考GitHub测试合并。如果GitHub测试
合并冲突
,
参考/拉动/534/合并
不存在,除非有人使用GitHub接口解决合并冲突。
1.
GitHub实际上并不直接使用Git。相反,他们使用了一种Git的增广子集。但是,如果合并没有冲突,合并结果是相同的。当合并发生冲突时,GitHub最初根本无法进行合并;现在,通过它们的扩展,它们提供了一种解决冲突的方法,而这不是Git的一部分。这种非Git GitHub特定的冲突解决方法仅在GitHub上可用,因为它们是GitHub自己创建的。
2.
当然,在其他意义上,分支确实存在。诀窍在于准确定义我们所说的
树枝
.另见
this SO question
,它深入到
做
存在,我们
呼叫
以及人们如何将它们相互混淆。另见
this Wikipedia article
,涉及命名的形而上学。
3.
所谓的
章鱼合并
有两个以上的父母。不过,它们并没有做任何普通合并所不能做的事情,所以我们将直接跳过它们来获得这个答案。
