推荐的git工作流程，允许独立部署功能 [英] Recommended git workflow that allows features to be deployed independently

问题描述

在我们的组织中，我们当前正在使用以下流程.

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

该功能已由登台服务器上的用户测试，并且如果企业确定该功能良好并且是时候将该功能部署到实时服务器上，则第二次合并功能分支，这一次将其合并到 production 分支，然后将其部署在生产服务器上.

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

这意味着 develop 分支与 production 分支的分歧越来越大.请注意， develop 不会永远合并到 production (在规范的git流中， develop 会合并到使用 release 分支进行生产.

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

我还感觉到，每一项新功能都会使工作变得越来越复杂，因为 develop 和 production 之间的差异不可避免地会越来越大. develop 和 production 不存在流程协调的问题，因此，恐怕一年之后，也许超过10,000次提交，合并将变得太复杂而无法处理.即使现在，我们也有合并错误.有些很明显，有些很微妙，很难找到.

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

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

我有两个问题:

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

解决方案

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

gitworflow (最初于2017年以"处理git分支以进行测试和生产)

它是用于 repo Git本身的一个.
其特点:

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

In our organization we're currently using the following flow.

Feature branch is forked from the production branch. Feature is implemented in the feature branch on the developer machine. Then feature branch is merged into develop branch which is automatically deployed on staging server.

The feature is tested by users on the staging server and if the business decides that it is good and that it is time to deploy it on live server, feature branch is merged second time, this time into the production branch which is deployed on the production server then.

But some features are abandoned for various reasons. For example, business decides that it's not yet time to deploy the feature to the live server. Or maybe it's no longer required. Or maybe we'll return to it one year later. On my picture the feature/1 is never merged into production branch but is merged into develop branch.

This means that develop branch diverge more and more from the production branch. Note that develop is never merged to production (in the canonical git flow, develop is merged to production by using release branches).

In my opinion this workflow requires a lot of manual labor. Because production and develop are different, manual merge is required when the feature branch is merged to develop for testing. This is also error-prone because we have old unused code from feature branches in develop that is never going away. Not only it makes merges complicated, but it also means that feature branch code may work differently in the develop and production branches because the old unmerged code can affect the feature code.

Also, I have a feeling that with every new feature this will make the work more and more complicated because amount of differences between develop and production will inevitably grow. There's no point in flow where develop and production are reconciled, so I'm afraid that one year later and maybe 10,000+ commits later the merges will become simply too complex to handle. Even now we have merge bugs. Some are evident, some are subtle and very hard to find.

I've raised the question several times to CTO that this flow is inherently inefficient and error-prone. But he insists that this flow is optimal because it allows business to choose when features are deployed to production. Also, he claims that he had used exactly the same flow at previous jobs in big companies.

I also have a lot of experience but I never had seen such flow and I never read about such flow in a book or blog article.

I have two questions:

1. Is such flow (where develop and production are constantly diverging) indeed used in big teams?
2. If I'm right that it is suboptimal at best, what is the best way to persuade the CTO to migrate to a better flow (for example, canonical git flow)?

解决方案

The best workflow to integrate or remove feature branches at will in an integration and then master branch is:

gitworflow (presented originally in 2017 with "Handle git branching for test and production")

It is the one used for the repo Git itself.
Its characteristics:

• It resets the staging/dev/testing branches at each new release cycle, making those branches ephemeral (ie destroyed/recreated)
• it merges the feature branches to those branches (instead of merging from dev to test to staging)

这篇关于推荐的git工作流程，允许独立部署功能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！