我目前正在将 Subversions 存储库迁移到 Git。我遇到的问题是管理特定项目正在进行的大量更改。可以放弃一些更改，这会导致 Subversion 分支损坏。
鉴于 Git 在分支方面的灵 active ，我建议采用以下工作流程:
核心布局:
- master 分支 - 仅限 pull 请求。高级开发人员签字。
- develop 分支 - 所有开发人员都可以使用。前沿功能 merge 到这里。可能并不总是有效
- uat 分支 - 所有开发人员都可以使用。已准备好供客户测试的测试功能
- staging 分支 - 所有开发人员都可以使用。仅填充生产就绪、已签署的功能
- feature/* - 项目启动后要完成的所有工作。功能可以是一些文本更改或网站功能的重大发展
典型工作场景:
- 客户要求在网站上添加新功能
- 开发人员从 master 创建一个新的功能分支并对新功能进行编码。功能定期 merge 到开发中
- 一旦该功能准备好进行测试，该功能就会 merge 到 uat 分支
- 任何进一步的调整都在功能中进行并 merge 到 uat 分支
- 一旦客户对新特性感到满意，它就会被 merge 到 staging 中，它是 master 的副本
- 完成 merge 到暂存后，将生成 pull 请求以讨论从暂存到主准备好部署到生产服务器的代码 merge
- pull 请求中请求的进一步更改被纳入功能并 merge 到暂存中
- pull request 完成后，master merge 到 develop 和 uat
- 功能将在一段时间后删除
通过以上我试图消除
- 清理废弃功能的问题。上述设置的最坏情况是，开发分支可以被删除，从 uat 或 master 克隆，并将正在进行的功能 merge 回其中。
- Cherry picking 已完成的开发功能以放入 uat 或 master，这是 Subversion 目前正在做的事情
- 未经授权篡改生产代码。通过以上内容，开发人员可以证明代码可以在暂存环境中工作，并请求在 merge 到 master 之前对代码进行审查。我们的 Subversion 解决方案允许开发人员 merge 到“主干”但他们无法部署，当发现错误代码时这会变得困惑
最佳答案
通常这是一个有效的工作流程，我不知道有什么可以改进的(在这里使用类似的)。如果你想要正式验证(我想你已经看过这些)，它在这个 page 的功能分支工作流中有很多描述。 .还描述了毕业(staging->uat->master)工作流程 in the manual .
鉴于 gits 的灵 active ，你也不会永远坚持这个工作流程，所以如果你发现某些事情不可行，你可以随时调整它(并且由于分布式的性质，任何人都可以使用他自己的微工作流程而不会把事情搞砸) .
所以是的，有效的工作流应该消除您想要消除的东西，并且应该适应您描述的工作流。
细节仍然总是取决于具体情况，但就像我说的那样，如果需要的话，这是一个很好的迭代开始。
关于git - 使用 Git 时此功能工作流程是否存在问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25380166/