Question

我和我的同事们正在开发单独的功能，完成后，我们会在提出拉取请求之前以开发为基础。

当我们达到稳定的开发版本时，我们将PR从开发转变为正式版；问题是，有时即使master仅从development进行更新，我们也会发生冲突。

这些冲突是如何产生的？从发展到掌握的某些Pr如何有2个父母？

这是当前情况的git图： master branch graph

更新

我很确定冲突是由以下流程引起的：

我们正在研究一项功能，完成后压缩所有提交并将其合并到开发中

D: a-b-c-d-e-                                                    F
F:    \__b1-b2-b3 -> squash creates F -> rebase on develop -> __/

开发它已发布给大师

M: a-b-c-d-e-F
D: a-b-c-d-e-F
F:           F

在有人继续研究F的同时，Develop获得更新，并重复步骤1中的压缩和合并过程。

M: a-b-c-d-e-F
D: a-b-c-d-e-F-g-h-i-                                                  J
F:           F -> f1-f2-f3 -> squash creates J -> rebase on develop __/

开发版已发布并掌握，我们有潜在问题

M: a-b-c-d-e-F - conflicts?
D: a-b-c-d-e-F-g-h-i-J
F:                   J

我希望我足够清楚，但是总之，似乎在步骤3中，我们为功能分支创建了第二个父级，这在从开发到母版合并时会导致合并冲突。在PR中使用相同的功能是否正确，并在再次批准它的工作之后，压缩其所有提交，重新设置基准，然后使用它进行另一个PR？

Answer 1

只要两个分支的代码库都不同，就会存在冲突……这意味着master上的某个更改尚未开发。让我们根据您的问题进行两次快速的心理锻炼

方案1：分支开发是从master开始的。主人永远不会得到承诺。 Master只会从development获得合并（例如，使用--no-ff）。不会对母版上的任何内容进行任何编辑（通过不使用--no-commit）……因此，绝无技巧。在这种情况下，每次您合并在master上进行开发时，永远不会发生任何冲突。作为测试，可以将master上的每个合并修订版本与从development合并的修订版本进行比较，并且不会有任何差异。

方案二：开发是从母版开始的...。但是与方案一不同，母版上的更改不在开发中（出于某种原因：用文件上的修订改写了修订，而不是修订）在开发中……。任何事情都会产生差异）……其他一切都与方案一类似。……在这种情况下，您偶尔会遇到冲突（当处理与分支之间的差异相关的代码时））。可以通过将master中的合并修订版与开发中合并的修订版进行比较来进行测试。只要那里存在差异，您就会遇到冲突（涉及差异中显示的那些代码段）。

让我们知道。

将请求从开发拉到主导致冲突

1 个答案: