我们才刚刚开始使用git，并且已经使用工作流实现了预先测试的提交（我今天才完成测试）。

基本上每个开发人员都有一个个人存储库，他们具有读/写访问权限。在我们的案例中，构建服务器TeamCity使用这些个人存储库进行构建，如果成功，则将更改推送到“绿色”存储库。开发人员没有对“绿色”的写入权限，只有TeamCity构建代理可以对此进行写入，但是开发人员从“绿色”中提取常见更新。

因此，开发人员从“绿色”开始，走向个人，TeamCity从个人开始，走向绿色。

这篇博客文章显示了我们正在使用的基本模型，以及针对个人存储库的GitHub分支（使用分支意味着存储库的数量不会一发不可收拾，最终会花费更多，并且意味着开发人员可以管理个人构建，因为他们可以分叉，然后创建团队城市构建工作，以将其代码推送到“绿色”）：

由于每个开发人员都必须拥有自己的构建配置，因此在TeamCity中进行设置需要做更多的工作。实际上，它实际上必须是2种配置，因为TeamCity似乎执行了所有构建步骤（包括最后的“推向绿色”步骤），即使先前的构建步骤失败了（如测试:)），这意味着我们必须有个人的为开发人员构建，然后是另一个依赖于该构建的构建配置，只要构建成功，该配置便会进行推送。