场景如下，我将用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：虽然开发的Feature_002 Clair在生产中运行，但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。
4条答案
按热度按时间3qpi33ja1#
如果Feature_001的变更不打算发布到生产中，则不应将其合并到DEV中。变更应留在Feature_001分支中。如果在合并到开发中后决定不发布Feature_001，则应恢复变更。只要其存在于DEV中，其他从DEV中拉取的用户将在其分支中具有更改。
uklbhaso2#
我看到了一些问题。如果特性001不再被开发......甚至被丢弃，比如说，它应该被从dev分支中取出。如果它没有被取出，当你（通过特性002）将dev合并到master分支时（另一个问题，我猜这不应该发生），因为特性001没有被取出，它落在master分支中。
那么......如何避免呢？每个人都会说不同的话。我的看法呢？当你收到通知说0001特性将被停止时，它应该已经从开发分支中取出了（通过重写开发历史以避免合并或者通过恢复0001修订）。然后，我想你不应该从开发合并到主...但这只是一个猜测，因为它真的取决于你的工作流程。
h9vpoimq3#
分支Feature_001在Feature_001完成且拉取请求获得批准之前不应合并到DEV。一旦Feature_001合并到DEV，则必须解决冲突，这将避免您遇到的问题。其中Feature_002分支具有来自Feature_001的一些提交代码。理想情况下，001应该很小或者分解成更小的功能，例如Feature-001-S-xxxxxx-MyStoryDescription，以便于跟踪。另外，由于分支Feature-001可能有很多提交，建议在拉取请求之前压缩提交，并在合并冲突发生时重定分支的基。2编码愉快！
dgjrabp24#
我知道您没有使用GitFlow，因为您在master之后创建了特性分支（在Gitflow中应该是develop），并且您正在推送尚未准备好在develop中发布的更改（在GitFlow中，release分支是在develop之后创建的）。
因此，在您的实际流程中，为了避免这些问题，我们可以：
1.避免将尚未准备好的更改推送到生产环境中进行开发。在本地机器上测试您的代码。如果您确实需要在某个特定环境中测试您的代码，请“借用”该环境并仅部署您的特性分支。
1.创建仅在激活某个标志时才有效的特性，例如db中的标志FEATURE_ACTIVE。它在qa中的值应为Y（用于测试），在生产中的值应为N（用于避免问题）。
1.不推荐。如果由于某种原因，您仍然需要将尚未准备好用于生产的更改推送到开发阶段。当您面临冲突时，可以创建一个临时分支来解决两个分支之间的冲突，然后将其合并以进行开发。这使您可以独立维护分支。稍后将部署的分支的作者，应该知道另一个分支合并到主分支，然后他可以从主分支中提取更改，并将临时分支合并到主分支中以保持分支干净。例如，在本例中，您的朋友应该已经创建了一个新分支，因为Feature_002称为Feature_001_002_temp，然后将分支Feature_001合并到其中，解决冲突并将其合并以进行开发。对Feature_002的任何其他更改都应通过此临时分支，直到Feature_002进入生产阶段。要非常小心的变化，一些冲突，如删除，常量的值可能会打破你的应用程序。