推荐的git工作流程，允许独立部署功能

Question

我们组织中目前正在使用以下流程。

功能分支是生产分支的分支。功能是在开发人员计算机上的功能分支中实现的。然后，功能分支合并到develop分支中，该分支会自动部署在登台服务器上。

该功能已由登台服务器上的用户进行了测试，并且如果企业认为该功能不错并且是时候将该功能部署到实时服务器上，则第二次合并功能分支，这次是合并到production中分支，然后将其部署在生产服务器上。

但是由于各种原因而放弃了某些功能。例如，企业认为尚不该将功能部署到实时服务器上。或者也许不再需要。或者，也许一年后我们会回到它。在我的图片中，feature/1从未合并到production分支中，而是合并到了develop分支中。

这意味着develop分支与production分支的分歧越来越大。请注意，develop从未合并到production（在规范的git流中，develop通过使用production合并到了release分支）。

我认为此工作流程需要大量的体力劳动。由于production和develop不同，因此，在将功能分支合并到develop进行测试时，需要手动合并。这也是容易出错的，因为我们有develop中功能分支的旧未使用代码，这些代码永远不会消失。这不仅使合并变得复杂，而且还意味着功能分支代码在develop和production分支中的工作方式可能不同，因为旧的未合并代码会影响功能代码。

我还感觉到，每一项新功能都会使工作变得越来越复杂，因为develop和production之间的差异将不可避免地增加。 develop和production的对账是没有意义的，因此，恐怕一年之后，也许再超过10,000次提交，合并将变得太复杂而无法处理。甚至现在我们还有合并错误。有些很明显，有些很微妙，很难找到。

我已经多次向CTO提出问题，该流程本质上效率低下且容易出错。但是他坚持认为这种流程是最佳的，因为它允许企业选择何时将功能部署到生产中。此外，他声称自己在大公司以前的工作中使用的流程完全相同。

我也有很多经验，但是我从未见过这样的流程，也从未在书或博客文章中了解过这种流程。

我有两个问题：

1. 在大团队中确实使用了这样的流程（develop和production在不断地分散）吗？
2. 如果我没错说这是次优的，那么说服CTO迁移到更好的流程（例如规范的git flow）的最佳方法是什么？

Answer 1

在集成中随意集成或删除功能分支，然后主分支的最佳工作流程是：

gitworflow （最初于2017年以“ Handle git branching for test and production”形式出现）

它是用于repo Git itself的那个。
其特点：

• 它会在每个新的发布周期重置暂存/开发/测试分支，从而使那些临时分支（即已销毁/重新创建）
• 它将功能分支合并到那些分支中（而不是从开发到测试再到阶段合并）

Answer 2

我遇到了完全相同的问题，在某些时候，处理如此分散的开发/生产分支会一团糟。

问题出在业务上，突然决定某个功能不会进入下一个版本，或者业务只是没有花时间测试该功能。而且这不是任何 git flow 都应该解决的问题。

gitworkflow 可能会尝试解决这个问题，但它非常复杂，as they also say by them self：

<块引用>

Gitworkfow 比大多数（可能是所有）其他流更复杂，更难理解。它需要对 git 概念和功能有更多的了解。它为开发团队的复杂多维产品提供了强大的功能，但在跟踪和理解多种事物的意义上确实有更多的“开销”。

所以我建议简单地使用 git-flow 强制从开发分支发布所有代码，而不是仅从开发分支发布特定功能。如果某个功能不应该在生产中使用，只需实现一个 feature toggle。