0

我们目前有多个针对不同项目的 Git 存储库。

目前我们有以下工作流程： Master - 这里的所有提交 Deploy - 在实时服务器上使用的生产代码

我们让 Hudson ci 在每次新提交时检查 master。每分钟轮询更改。我们还有一个登台服务器，用于在从我们的主分支部署之前签署测试物理功能的工作请求

我们现在看到的主要问题是我们在工单/工作请求的基础上工作，我们可能并不总是希望在发布的基础上部署所有更改，但如果工单是由高级员工签署的。

我看过 Git flow 和 github flow 之类的东西。两者都有其优势，但是我无法找到包含登台服务器和 ci 的策略。

任何帮助或阅读建议将不胜感激！

更新 1

我们的工作流程应遵循以下内容：

Production:  -------------I-----------O----
                         /           /
             B---E---F---G    J---K---L
Master:  A--/--C---D---H--\--/---M---N-\---
          \-1-/-2-/-3-/     \-1-/-2-/

Ci 和 Staging 区域都从 Master 运行，所有工作都在一个分支上进行并合并到 staging。然后将功能/票证分支的签核工作合并到生产中，仅在特定分支中进行更改。

如果这是错误的或者如果有人对此有更好的解决方案，请纠正我

4

1 回答 1

1

所以你有一个主分支，那里的任何提交都去 prod 和一个登台分支，那里的任何提交都去一个登台服务器，我接受它..

所以这对我来说很有意义..每张票都应该是它自己的主分支。从那里，开发人员可以合并到登台进行测试。一旦它通过测试并被签署，该分支就可以开始了。从那里您可以决定将哪些分支合并到您的“发布”分支中，并将该分支合并到主分支中进行部署。

您甚至可以将发布分支合并到 staging 以再次测试发布，以确保每个分支与其他分支配合得很好。

或者..如果您使用 github.. 只需根据票证让每个 dev 分支离开一个新分支.. 然后将 PR 发送给 master

于 2012-07-22T15:42:50.483 回答