Git - 功能分支之间的冲突 - 如何避免功能分支包含另一个功能分支中的更改答案

【问题标题】：Git - conflicts between feature branches - how to avoid a feature branch contains changes in another feature branchGit - 功能分支之间的冲突 - 如何避免功能分支包含另一个功能分支中的更改
【发布时间】：2019-02-28 09:51:46
【问题描述】：

场景如下。我将使用 t1,t2,t3 等来表示不同的时间：

我有两个分支来代表我的环境 DEV 分支，MASTER 分支。

t1：我从 MASTER 创建了一个 Feature_001 分支

t2：我在 Feature_001 分支中添加了提交，并将我的代码合并到 DEV 中并推送它。

t3：由于某种原因，我的经理告诉我停止 Feature_001 分支的开发

t4：一个月过去了。我的同事 Clair 从 MASTER 创建了一个 Feature_002 分支。

t5：Clair 在 Feature_002 分支中添加了提交，并试图将她的代码合并到 DEV 分支中并推送它。然而，当她推动时，冲突出现了。

t6：然后 Clair 将 DEV 分支中的更改合并到她的 Feature_002 分支中（我的问题发生在这一刻）。她做了一个新的提交来解决 Feature_002 分支中的冲突。之后，Clair 将她的代码合并到 DEV 中并推送。

t7：经过测试，Clair 的经理说现在可以合并到 MASTER 分支。因此，Clair 将 Feature_002 分支合并到 MASTER 分支中。

t8：虽然 Clair 开发的 Feature_002 在生产中运行，但 Feature_001 也无意中出现在生产中，因为 Feature_002 分支曾经将 DEV 的代码合并到自身以解决冲突。我们的经理吓了一跳，开始质疑谁敢让Feature_001投产！？

t9：永远开会讨论发生的事情......

如果你对场景把握得好，你会发现由于特性分支之间的冲突，在Clair从DEV拉取代码后，Feature_002分支会包含Feature_001分支的变化。

我的问题是如何保持两个功能分支独立，同时使我们能够解决它们之间的冲突？

非常感谢任何反馈和讨论。

编辑 20180925：

我想稍微调整一下情况。 Feature_001 分支可能是不需要的，或者只是长期处于开发状态。让我们让它在很长一段时间内处于开发状态，而 Feature_002 首先经过测试并快速合并到 MASTER 中。但是，现在，当我们不希望 Feature_001 投入生产时，MASTER 分支再次具有 Feature_001 和 Feature_002 更改。

【问题讨论】：

标签： git branching-and-merging git-flow feature-branch

【解决方案1】：

如果 Feature_001 中的更改不打算发布到生产环境，则不应将其合并到 DEV。更改应该留在 Feature_001 分支上。如果在 Feature_001 合并到开发后做出不发布的决定，则应该还原更改。只要它存在于 DEV 上，从 DEV 中提取的其他用户将在其分支中进行更改。

【讨论】：

假设现在我们决定恢复来自 DEV 中 Feature_001 的所有内容。我们应该怎么做？不建议直接在 DEV 分支中提交。但是，我们仍然希望将来保留 Feature_001 分支。您对此有何看法？
您可以根据开发创建新的分支来恢复更改。或者，如果您使用 gitlab 之类的东西，它会提供此选项以将其还原为单独的合并请求（这是我们在此类场景中所做的工作）
感谢 AJC，这是在 Gitlab 中还原代码的一种非常有用的方法。另外，我想调整上面的场景。假设不需要 Feature_001，它已经开发了很长时间。我们仍然想要 DEV 中的代码。但是，Feature_002 首先经过测试并合并回 MASTER。然而，同样，在 MASTER 中，Feature_001 和 Feature_002 都在那里。我该如何解决这种情况？
我不太明白你的问题。您是说，Feature_001 不是想要的，但在 DEV 中？我的理解是 DEV 在任何时候都应该只有准备好发布的代码。至少我们这里的流程是，master 将始终拥有与 PRO 中相同的代码。 DEV 应该只测试、签名和可部署的代码。任何未经产品团队测试或未经批准的东西根本不应该在开发中。如果我误解了您的问题，请纠正我。
Feature_001 是需要的，现在在 DEV 中。我将提供一个场景来更多地描述这个例子。我是 Feature_001 的开发者。不过，我请了一周的病假。当我在医院时，我的同事 Clair 将她的代码合并到 DEV，然后合并到 MASTER。在这种情况下，Feature_001 的更改保留在 DEV 中是有效的。但是，我们仍将面临我原来帖子中提到的问题。

【解决方案2】：

我发现那里有很多问题。如果功能 001 不再被开发......甚至被丢弃，比如说，它应该被从开发分支中取出。鉴于它不是，当您将 dev（通过功能 002）合并到 master（又一个问题，我的猜测是这不应该发生）然后，因为功能 001 没有被取出，它降落在 master。

那么....如何避免呢？每个人都会说不同的话。我的看法？当您收到要停止功能 0001 的通知时，它应该已从开发分支中取出（通过重写开发历史记录以避免合并或通过恢复 0001 修订）。然后，我猜你不应该从 dev 合并到 master ......但这只是一个猜测，因为它真的取决于你的工作流程。

【讨论】：

您可能误解了一些观点。从来没有人从 DEV 合并到 MASTER。 Clair 将 Feature_002 合并到 DEV 中。然后，Clair 将 Feature_002 合并到 MASTER 中。
t6 完全相反：dev 被合并（通过拉）到她的功能 002 分支中。然后在 t7 功能 002（包括在 dev 上的更改）被合并到 master。
仍然，这两个方向是： 1. DEV -> Feature_002 2. Feature_002 -> MASTER DEV -> MASTER 没有直接合并
当然.... 对 git 来说仍然没有什么区别，因为当您合并功能 002 时，您将 dev 的修订版登陆到 master 中。检查 的历史记录大师，让我们知道是否有针对功能 001 开发的更改...让我用我的预言能力告诉您...让我闭上眼睛几秒钟...。是的，有。
这是你解决的冲突在 dev 上，不是在功能 002 分支上。功能 002 分支保持原样，没有合并分支中的任何内容，如 dev 那样具有爆炸性（显然）。这样你就可以确保你保持分支“原始”。然后，当您在开发功能 002 上进行了测试并开始使用时，您可以将其合并到 master 中，然后生活继续其快乐和悲伤的时光。

【解决方案3】：

在 Feature_001 完成并且拉取请求获得批准之前，分支 Feature_001 不应合并到 DEV。一旦将 Feature_001 合并到 DEV 中，就必须解决冲突，这将避免您遇到的问题，其中 Feature_002 分支有一些来自 Feature_001 的提交代码。理想情况下，Feature_001 应该很小或分解为更小的特征，例如 Feature-001-S-xxxxxx-MyStoryDescription 以便于跟踪。此外，由于您的分支 Feature-001 可能有许多提交，因此建议在执行拉取请求之前压缩您的提交，并在发生合并冲突时重新设置您的分支。编码愉快！

【讨论】：