Git 解决不同分支之间的合并冲突

我的公司有这样的规定：

要素分支是从主分支创建的

一旦功能分支完成，我们将进行PR以开发分支

PR批准后，合并以开发

在QA测试之后，特性分支将合并回master

这个流程在尝试创建PR时产生了很多不必要的合并冲突（尽管如果与master的PR没有问题），我们如何改善这种情况

---

编辑：似乎我的公司使用基于主干的开发，而使用开发分支仅用于新功能的测试场（有时功能由不同的开发人员与多个分支一起开发）

我们公司遵循以下步骤。这可能会有帮助：

从主节点创建要素分支

完成要素分支中的工作

将主分支合并到要素分支，解决所有冲突。为了尽量减少冲突，您可以每天一次将master合并到分支

解决冲突后，检查是否一切正常。然后将其推到分支的遥控器上

然后结帐给主人

合并从要素分支到主要素的所有内容。由于我们已经合并了从特性分支到主分支的所有内容，所以将特性合并到主分支不会引起任何冲突

这样，主分支将始终保持干净。冲突将在功能分支中解决。另外，如果您想将请求拉到master，请首先将master分支的最新内容合并到您的feature分支

---

总之，为了尽量减少冲突，让您的功能分支尽可能频繁地与主分支保持最新。并解决功能分支中的所有冲突，以保持master干净。

您可以通过以下方式改善这种情况：

• 应从“开发”分支创建要素分支
• 合并开发分支中的任何PR后，每个人都应在本地重新定位其开发分支以及各自的特色分支
• 通过以上两个步骤，只有在QA测试和开发合并到Master分支后，Master才会被更改

如果我需要进一步解释，请告诉我

---

.

git代码中最大的部分是冲突解决。您的提交和同事的提交越小，git自动解决冲突的可能性就越大。非常大的提交主要是冲突的原因

---

工作流程在我看来很好，不应该成为您不断冲突的根本原因。即使我同意功能分支应该从develop分支。

#1不应该产生任何冲突！您如何进行qa/测试？你用master吗？如果bug发生了呢？不，我们也有一个开发分支，我们只有在测试完成后才使用master！因此，主版本只包含发布版本。那么您是否对功能到开发进行PR？第1点不适用，因为做出该决定的人是我的领导基于什么原因，他/她决定这么做？我对公司还是新手，但我认为他决定每个功能都应该基于稳定的代码（已经通过QA）master是您的生产分支吗？显然它使用基于主干的开发，具有短寿命的特性分支和长寿命的master分支，PR-to-develope仅用于测试与功能交付相关的多个功能分支。这是由于QA部门的滞后，开发中的大量提交没有按照我们的要求快速提交给master，因此较新的功能分支可能基于master的旧代码，而不是develop中较新的代码