允许独立部署功能的推荐 git 工作流程
Recommended git workflow that allows features to be deployed independently
在我们的组织中，我们目前使用以下流程。
功能分支是从生产分支派生出来的。特性在开发者机器的特性分支中实现。然后将功能分支合并到 develop 分支，自动部署到登台服务器上。
该功能由用户在临时服务器上测试，如果业务认为它很好并且是时候将其部署到实时服务器上，则第二次合并功能分支，这次合并到 production 然后部署在生产服务器上的分支。
但有些功能由于各种原因被放弃了。例如，企业决定还没有到将功能部署到实时服务器的时候。或者也许不再需要它。或者一年后我们会 return。在我的图片上，feature/1 从未合并到 production 分支中，而是合并到 develop 分支中。
这意味着 develop 分支越来越偏离 production 分支。请注意 develop 从未 合并到 production（在规范的 git 流程中，develop 合并到 production通过使用 release 个分支）。
在我看来，这个工作流程需要大量的体力劳动。因为production和develop不一样，所以在合并feature分支到develop进行测试时需要手动合并。这也很容易出错，因为我们在 develop 中的功能分支中有旧的未使用代码，这些代码永远不会消失。它不仅使合并变得复杂，而且还意味着功能分支代码在 develop 和 production 分支中的工作方式可能不同，因为旧的未合并代码会影响功能代码。
此外，我有一种感觉，随着每个新功能的出现，这会使工作变得越来越复杂，因为 develop 和 production 之间的差异不可避免地会增加。在 develop 和 production 协调的流程中没有意义，所以我担心一年后，也许 10,000 多个提交之后，合并将变得太复杂而无法处理。即使现在我们也有合并错误。有些很明显，有些很微妙，很难找到。
我已经多次向 CTO 提出这个问题，这个流程本质上是低效且容易出错的。但他坚持认为这种流程是最佳的，因为它允许企业选择何时将功能部署到生产中。此外，他声称他在以前的大公司工作中使用的流程完全相同。
我也有很多经验，但我从未见过这样的流程，也从未在书籍或博客文章中读到过这样的流程。
我有两个问题：
- 这样的流程（其中
develop 和 production 不断发散）确实在大团队中使用吗？
- 如果我是对的，它充其量是次优的，那么说服 CTO 迁移到更好的流程（例如，规范 git 流程）的最佳方法是什么？
在集成中随意集成或删除 功能分支，然后是主分支的最佳工作流是：
gitworflow (presented originally in 2017 with "")
用于repo Git itself的那个。
其特点：
- 它会在每个新的发布周期重置 staging/dev/testing 分支，使这些 分支变得短暂 （即 destroyed/recreated）
- 它将功能分支合并到那些分支（而不是从开发合并到测试再到暂存）
我 运行 遇到了完全相同的问题，在某些时候处理这种分歧的问题很麻烦 develop/production b运行ches.
问题出在业务上，它突然决定某个功能不会出现在下一个版本中，或者业务只是没有花时间测试该功能。这不是任何 git 流程应该解决的问题。
gitworkflow may try to solve this problem, but its very complicated, as they also say by them self:
Gitworkfow is more complicated, and harder to understand than most (probably all) other flows. It requires more understanding of git concepts and capabilities. It offers significant powerful capabilities to complex multi-dimensional products with a team of developers, but does have more "overhead" in the sense of multiple things to track and understand.
所以我建议简单地使用 git-flow which forces to release all code from the develop branch, instead of only specific features from the develop branch. If a feature then should not yet be used in production, just implement a feature toggle。
在我们的组织中，我们目前使用以下流程。
功能分支是从生产分支派生出来的。特性在开发者机器的特性分支中实现。然后将功能分支合并到 develop 分支，自动部署到登台服务器上。
该功能由用户在临时服务器上测试，如果业务认为它很好并且是时候将其部署到实时服务器上，则第二次合并功能分支，这次合并到 production 然后部署在生产服务器上的分支。
但有些功能由于各种原因被放弃了。例如，企业决定还没有到将功能部署到实时服务器的时候。或者也许不再需要它。或者一年后我们会 return。在我的图片上，feature/1 从未合并到 production 分支中，而是合并到 develop 分支中。
这意味着 develop 分支越来越偏离 production 分支。请注意 develop 从未 合并到 production（在规范的 git 流程中，develop 合并到 production通过使用 release 个分支）。
在我看来，这个工作流程需要大量的体力劳动。因为production和develop不一样，所以在合并feature分支到develop进行测试时需要手动合并。这也很容易出错，因为我们在 develop 中的功能分支中有旧的未使用代码，这些代码永远不会消失。它不仅使合并变得复杂，而且还意味着功能分支代码在 develop 和 production 分支中的工作方式可能不同，因为旧的未合并代码会影响功能代码。
此外，我有一种感觉，随着每个新功能的出现，这会使工作变得越来越复杂，因为 develop 和 production 之间的差异不可避免地会增加。在 develop 和 production 协调的流程中没有意义，所以我担心一年后，也许 10,000 多个提交之后，合并将变得太复杂而无法处理。即使现在我们也有合并错误。有些很明显，有些很微妙，很难找到。
我已经多次向 CTO 提出这个问题，这个流程本质上是低效且容易出错的。但他坚持认为这种流程是最佳的，因为它允许企业选择何时将功能部署到生产中。此外，他声称他在以前的大公司工作中使用的流程完全相同。
我也有很多经验，但我从未见过这样的流程，也从未在书籍或博客文章中读到过这样的流程。
我有两个问题：
- 这样的流程（其中
develop和production不断发散）确实在大团队中使用吗？ - 如果我是对的，它充其量是次优的，那么说服 CTO 迁移到更好的流程（例如，规范 git 流程）的最佳方法是什么？
在集成中随意集成或删除 功能分支，然后是主分支的最佳工作流是：
gitworflow (presented originally in 2017 with "
用于repo Git itself的那个。
其特点：
- 它会在每个新的发布周期重置 staging/dev/testing 分支，使这些 分支变得短暂 （即 destroyed/recreated）
- 它将功能分支合并到那些分支（而不是从开发合并到测试再到暂存）
我 运行 遇到了完全相同的问题，在某些时候处理这种分歧的问题很麻烦 develop/production b运行ches.
问题出在业务上，它突然决定某个功能不会出现在下一个版本中，或者业务只是没有花时间测试该功能。这不是任何 git 流程应该解决的问题。
gitworkflow may try to solve this problem, but its very complicated, as they also say by them self:
Gitworkfow is more complicated, and harder to understand than most (probably all) other flows. It requires more understanding of git concepts and capabilities. It offers significant powerful capabilities to complex multi-dimensional products with a team of developers, but does have more "overhead" in the sense of multiple things to track and understand.
所以我建议简单地使用 git-flow which forces to release all code from the develop branch, instead of only specific features from the develop branch. If a feature then should not yet be used in production, just implement a feature toggle。