我们在不同的开发团队中使用git工作流进行工作，如下所示：
- 接收票证
- git提取/检出
- 创建功能/错误修复分支
- 进行更改
- 提交到分支
- 合并到测试分支，git pull到测试环境
- 在与现场相同的环境中进行测试
- 如果测试成功，则合并到proof，git pull到proof
- 客户签字
- 合并到live
- git pull on live
然而，我无法决定开发人员将更改拉到实时服务器的最佳方式。
目前，开发人员通过SSH连接到实时服务器（使用单独的用户帐户）并执行git pull，但他们需要对服务器上的代码库具有读/写访问权限。
我不喜欢这样，因为只有一个人（或系统管理员）需要执行部署。
另一种选择是创建一个可在网络上访问的git pull脚本，因此当开发人员想要执行pull时，该脚本会在服务器上执行git pul并输出到浏览器。
在我看来，最好的选择是在推送repo时触发挂钩-我们使用gitlab，所以我认为这个实现相对来说比较简单，web服务器上的脚本接收到一个包含有关存储库信息的POST对象，所以它可以被编写脚本，只在接收挂钩的分支已经更新（如果这有意义的话）的情况下触发pull。还可以向进行推送的用户发送一封电子邮件，并输出git pull消息，以确保一切按计划进行。然而，我感到不舒服的是，开发人员可能会意外地推到错误的分支，提交过早地生效——理想情况下应该有某种github风格的合并请求功能。
有人有其他建议吗？
在工作中，我们使用capistrano+webistrano。尽管它是基于ruby的，并且许多特性都是特定于ruby的，但它非常适合我们的需要。
以下是我们的工作流程：
1-5:与您的相同
6:转到dev-webistrano->选择分支->部署
7:客户签字等
8:转到实时webistrano->选择分支->部署
它还支持部署脚本和其他一些东西。对于部署脚本，我们使用shared文件夹和current文件夹。部署脚本创建到共享文件夹的符号链接，该文件夹包含库和其他不在git存储库中的东西。
下面是一个用于magento的示例部署脚本。
Jenkins是持续集成的另一个选择。与capistrano（自动测试执行）相比，它支持一些额外的东西，因此可能值得一试。
我们喜欢使用Gerrit进行代码审查。Gerrit实例位于中央Git存储库的顶部，让项目负责人查看内容。一旦提交被审查并接受，JenkinsCI就会启动，进行自动代码样式检查、单元测试、自动生成API文档等，并最终使用ApacheAnt脚本进行部署（如果所有测试都通过）。这是一个相当复杂的设置，但我们已经爱上了它
这些很棒的教程详细介绍了设置。
除了您在流程中发现的问题外，我还担心并行更改在您的"Proof"环境中发生冲突并造成无效测试。
假设Bob将变更#1拉到Proof，然后Dave将变更#2拉到Proofing，然后客户端测试变更#1（针对具有#1和#2的代码库），当您将变更#1拖到Live时，您实际上是在拉未经测试的代码。
我建议您考虑不可变的构建和构建工件。我的一位同事就这个话题写了一篇很好的文章。您的流程的主要变化是：
- 1-5：（相同）
- 6：从测试分支检索；捕获构建工件；将构建工件部署到测试
- 7：（相同）
- 8：将构建提升为Proof；部署构建工件
- 9（相同）
- 10推广build-to-Live；部署构建工件
您还应该考虑使用部署/交付自动化工具，如Inedo的BuildMaster。免费版本应该比你需要的更多，它将帮助你从"登录并运行脚本"到"在适当的批准后单击按钮"。
免责声明：我为Inedo