Git 将请求从develop拉到master导致冲突

我和我的同事正在开发不同的功能，完成后，我们会在提出拉取请求之前重新设置开发的基础

当我们达到一个稳定的开发版本，我们的过程，使公关从发展到掌握；问题是，有时我们会遇到冲突，即使master只从develop更新

这些冲突是如何产生的？一些公关从发展到掌握如何可能有两个父母

这是当前情况的git图：

更新

我非常确定，冲突是由以下流程产生的：

我们处理一个特性，完成后压缩它的所有提交并将其合并到开发中 开发并发布给master developer在有人继续处理F时获取更新，并从步骤1开始重复挤压和合并过程 开发发布给master，我们有潜在的问题 我希望我说得够清楚，但简单地说，在步骤3中，我们似乎为功能分支创建了第二个父级，这在从“开发”合并到“主”时会导致合并冲突。

---

对一个PR使用相同的功能是否正确？在它再次获得批准后，挤压它的所有提交，重新设置基础，然后使用它进行另一个PR？

只要两个分支的代码基础不同，就会有冲突。。。这就意味着大师的变化并不在发展中。让我们根据你的问题做两个快速的心理练习

场景一：分支开发从master开始。主人永远不会得到承诺。Master只会使用develope提供的-no-ff进行合并。如果不使用-no commit，将永远不会对master上的任何内容进行任何编辑。。。所以，不要耍花招。在这种情况下，每次您在master上合并开发时，都不会有任何冲突。作为测试，master上的每个合并版本都可以与develop合并的版本进行比较，不会有任何差异

场景二：开发从master开始。。。。但与场景一不同的是，无论出于何种原因，master上有一个不在开发中的更改：在文件上有一个修改的重写版本，一个不在开发中的版本。。。。任何事情都会产生差异。。。其他一切都像场景一。。。。在这种情况下，在处理与分支之间的差异相关的代码时，您会偶尔遇到冲突。这可以通过将master中的合并修订与develop中合并的修订进行区分来测试。只要存在差异，就会出现涉及差异上显示的代码片段的冲突

---

让我们知道。

您的问题是什么？@Encrypted西瓜我希望现在能更清楚。

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

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