使用Git有这个功能工作流程有问题吗？

Question

我目前正在将Subversions存储库迁移到Git。我遇到的问题是管理特定项目正在进行的大量更改。可以放弃一些更改，这会使Subversion分支断开。

鉴于Git在分支方面的灵活性，我建议采用以下工作流程：

核心布局：

• master 分支 - 仅限于提取请求。签约的高级开发人员。
• 开发分支 - 适用于所有开发人员。出血边缘功能合并到此处。可能并不总是有效
• uat 分支 - 适用于所有开发人员。经过测试的功能，供客户端测试
• 暂存分支 - 适用于所有开发人员。仅填充生产就绪，已签名的功能
• 功能/ * - 适用于项目启动后完成的所有工作。功能可能是一些文本更改或网站功能的重大发展

典型工作方案：

• 客户已在网站上提出新功能
• Developer从master创建一个新功能分支并对新功能进行编码。功能定期合并到开发
• 该功能准备好进行测试后，该功能将合并到uat分支
中
• 在功能中进行任何进一步调整并合并到uat分支
• 一旦客户对新功能感到满意，它就会合并到分段中，这是主人的副本
• 完成合并到分段后，会生成一个拉取请求，以讨论从分段合并到主分区的代码，以便部署到生产服务器
• 拉取请求中请求的进一步更改将进入该功能并合并到暂存
中
• 完成拉取请求后，master将合并到develop和uat
中
• 一段时间后删除功能

以上我试图消除

• 清理已弃用功能的问题。在上述设置的最坏情况下，可以删除开发分支，从uat或master克隆，并将正在进行的功能合并回其中。
• Cherry pick完成了开发中的功能，将其放入uat或master中，这是Subversion目前正在发生的事情。
• 未经授权篡改生产代码。通过上述内容，开发人员可以证明代码与登台环境一起工作，并请求在合并到master之前检查代码。我们的Subversion解决方案允许开发人员合并到“trunk”但是他们无法部署，这可能会在发现错误代码时变得混乱

Answer 1

通常它是一个有效的工作流程，我不知道有什么需要改进的（在这里使用类似的）。如果你想要正式的验证（我猜你已经看过这些），它在page的功能 - 分支工作流中已经有了很多描述。毕业（staging-＆gt; uat-＆gt; master）工作流程也被描述为in the manual。

鉴于gits的灵活性，你也不会永远停留在这个工作流程上，所以如果你发现某些东西无法解决，你可以一直调整它（并且由于分布式的性质，任何人都可以使用他自己的微工作流程而不用搞砸了）

所以是有效的工作流程，应该消除你想要消除的东西，并且应该适应你描述的工作流程。

细节仍然总是取决于具体情况，但就像我说如果需要的话，这是一个很好的开始。