gitflow符合我们的需求,而giverflow似乎适合gitflow.但有一点我不完全理解.让我解释一下困扰我的是什么.

>我们在开发分支上开展一些功能 – 所有软件包都标记为1.3.0-unstable.1,1.3.0-unstable.2等等.
>每个包都通过管道 – 开发,测试,uat,prod.
>所以当dev准备好并且一切都很好时,根据gitflow我们启动发布分支.
>在发布时不需要进行任何更改,我们马上就完成了 – 发布分支合并到主服务器并进入开发.
>构建服务器再创建一个包1.3.0,这是一种准备好的产品.

如何实现构建一次,在这里部署多个？根据所有规则,我们需要向prod env推广1.3.0-unstable.x,因为这个包在dev和test中测试过,但是对于prod来说版本看起来有点奇怪,不是吗？来自master分支的1.3.0从未在任何地方部署过.

问题类似于：In the git flow model should I build from the merge commit in master to release?

答案并不令人满意：

>我们在与主人合并时做了-no-ff
>它仍然是一个不同的包

最佳答案 我自己回答这个问题.我们已经意识到使用gitflow支持多个版本/几个环境是一个巨大的负担.因此,我们正在寻找更简单的东西,即
github flow.当然,它并没有完全解决原始问题(构建一次 – 部署许多),但这是我们部分解决它的方式.

我们的管道变了

来自：dev – >测试 – > uat – >刺

to：dev – >测试然后uat – >刺

就像我之前说过的那样,我们正在使用github流程.每当我们处理新功能时,首先 – 我们从最新的master创建一个分支featurename.此分支的每个构建版本都是这样的1.3.0-featurename.1,1.3.0-featurename.2,依此类推.

一旦开发人员完成了他的实现并完成了所有的开发检查,这些精确的二进制文件就会进入QA的测试环境.在质量保证人签署此版本后,我们很高兴通过我们的第二个管道uat推动这一点 – >刺.我们合并了featurename分支的pull请求和之后得到的构建版本,让我们说：1.3.1进入uat环境.一旦它在那里签名,我们将完全相同的二进制文件推送到prod环境.

如果同时开发了多个功能分支,那么我们推送到测试环境的下一个版本应该在最新的主服务器上再次通过管道进行重新设置.