处理测试和生产的git分支

Question

在使用 git(flow) 进行开发并拥有一个阶段/测试环境，客户对所开发内容进行审核时，如何处理未被批准的功能与已批准的功能呢？

考虑到多个开发人员在冲刺或连续工作流中处理不同功能的情况。需要客户审核这些功能，并将它们合并到 dev 分支并部署以便在阶段环境下进行审查。

假设有两个功能已经完成开发，由开发团队认为已完成并推送到 dev 分支上。客户审核后只批准其中一个功能。但现在客户想要将已批准的功能发布到生产环境中。dev 分支现在被一份未被批准的功能代码所"污染"，无法推送到生产环境。

如何处理此类情况？当然现实中更为复杂。是挑选一个解决方案还是应重新考虑分支的整个处理过程？

- Hyzac

---

如果dev分支包含将要推广到生产环境的所有内容，那么新功能就不能被推送到dev进行客户审查。客户需要在功能分支上仍然存在时进行审查，以防止“污染”的dev分支。 - BJ Myers

但是如果客户没有处理功能分支的方法，那么需要逐个功能地手动放置要审核的内容到测试环境中。而且，在当前功能未经审核之前，新的功能无法进行审核，这使得整个过程非常缓慢。 - Hyzac

Answer 1

那个问题（dev分支被“未经批准但已经集成”的功能分支污染）正是Raman Gupta在“Git创建者如何进行分支”中所描述的。
（此工作流的GitHub repo：rocketraman/gitworkflow）

在您的情况下（gitflow），您需要在合并dev到release之前撤销非批准功能的合并提交。

但是，“gitworkflow”使用临时分支，与gitflow相反：

GitFlow主张有两个永久分支-master和develop

无论是gitflow还是gitworkflow，都使用“feature”或“topic”分支：

“主题分支是当前所有工作都在进行的地方——每个问题、错误或特性都有一个分支，可以同时进行多个主题分支的开发。”

“在gitworkflow中，主题最终会合并到“next”分支中。然而，一个关键的区别是“next”分支从未合并到“master”（与永恒分支“develop”相反，后者旨在合并到gitflow的“master/release”分支）。”

现在，topic已经升级到next，可以成为beta版或验收版的一部分。因此，next上的每个主题现在都可以进行第二轮稳定，这正是beta版/验收测试环境的目的。

但是，请注意，使用gitworkflow时，我们仍然没有承诺将此topic作为下一个生产发布的一部分 - 它仍未合并到master中。
这类似于GitFlow的release分支的概念，但更加灵活和强大，因为master完全不依赖于next，也从不将next整体合并到master（与相应的GitFlow分支develop和release不同）。 如果next未合并到master，那么如何将功能升级到生产环境？

一旦一个主题被认为足够稳定发布，该主题再次毕业并与master（或者也许是maint）合并，再次使用--no-ff以保留主题分支的完整历史记录。

为什么这样做更好：

请注意，在gitworkflow中，不会在同一分支上混合不稳定和稳定的开发工作。相比之下，使用GitFlow有两个选择：

1.我可以在自己的分支上孤立地测试我的主题，或者

2.我可以将其合并到develop以进行测试。

两种选择都不理想。

前者不能真正测试主题在与其他正在进行的工作一起部署时的稳定性，而后者可能在主题稳定之前就将其提交到develop。

含义：

简而言之，在GitFlow中，始终存在一种无法解决的紧张关系，即在主题分支上保持开发工作的清洁和隔离的愿望与将主题分支与其他工作集成以将它们合并到develop分支以使其可见和可测试并检查冲突之间的平衡。Gitworkflow可以实现两个目标而不牺牲任何一个。

- VonC

---

是的，这看起来像是解决问题的方式。我会尝试一下并尝试理解其工作流程，但它肯定可以解决gitflow工作流中的问题。 - Hyzac

@Hyzac 是的：主要的点是：将你的主题/功能合并到一个开发/集成分支中，然后再将同样的主题/功能合并到一个发布分支中。不要试图直接将你的集成分支合并到发布分支中。 - VonC

感谢你的提醒！ - Raman

@Raman，感谢你在Gitworfklow方面所做的一切工作！这些年来我已经多次参考过它。 - VonC

@VonC 感谢您的工作。我正在参考您的Git工作流程。但我有一个问题，希望您能回答我。 这是否意味着，如果在合并/PR功能/主题分支时发生冲突，我需要两次解决冲突？一次是将功能分支合并到Develop分支时，另一次是将其合并到Master分支时。如果是这样的话，有没有办法减少这些冲突？ - undefined

Answer 2

我认为这里的正确方式是：

• 生产环境（...）
• 主分支（开发分支）
• 特性123
• 特性234
• 特性345
• 特性[数字]

如果可以，为客户提供一个特性[数字].example.com 域名。这样你就可以在合并到主分支之前展示所有的特性。如果一个特性被拒绝，它就不应该被合并到主分支中。如果特性被接受，它必须被合并。

另一个好的选择是一个“staging”域，用于在需要时部署代码。假设您的客户需要查看特性42，只需将特性42 部署到 customer.example.com 域即可。

新特性开发应该在哪里进行？

feature[number] branch

新功能应该在哪里展示？

feature[number].example.com

在哪里可以看到下一个迭代的代码（主干）在工作中的情况？

next.example.com

或者

master.example.com

在哪里查看生产代码？

www.example.com

- sensorario