我们即将开始将我们的 Web 应用程序拆分为多个服务，每个服务都有自己的存储库。我们使用 git 作为我们的 scm，我想知道是否有人对我们的 scm（在本例中为 git）的工作流程有任何建议。
现在我们使用与此处所示类似的工作流程：http://nvie.com/posts/a-successful-git-branching-model/。
我想转向一个更简单的模型，例如 Github 的工作原理：http://scottchacon.com/2011/08/31/github-flow.html。这对于开发 SOA 是否可行？
很好奇是否有人对此有意见。谢谢。
【问题讨论】：
标签： git version-control workflow soa
Github flow 将功能分支与单个产品相关联，但没有理由无法实现。您的工作流程选项取决于您部署应用程序的方式。考虑“MyApp”，它具有三个组件服务：
MyApp
|- ServiceA
|- ServiceB
|- ServiceC
如果您可以独立于 ServiceB 和 ServiceC 部署 ServiceA，更重要的是部署所有这些独立于 MyApp 包含但不存在于任何 Service* 存储库中的代码，那么只需应用 Github 流，您首选的工作流程，适用于每个存储库和团队。
如果服务紧密交织在一起，并且部署 ServiceA 必然需要部署 ServiceB 或更重要的是，MyApp 代表了大量的脚手架或路由代码，每次 @987654332 之一都必须推进@repos 做，那么你可能想要submodules 或subtree 之类的东西。在该模型中，您将拥有一个 Github 流程，以及 #4 和 #5 之间的额外步骤，即在部署之前收集服务的子模块（或子树）更新。我会避免没有子树或子模块的存储库嵌套，除非您（和您的团队）非常了解 git。
写完所有这些，我建议您深入了解拆分应用程序的动机。它有其优点和成功的工作流程，但它们是有代价的：获得历史的“全貌”更加困难；在某些情况下，使用git bisect 之类的工具可能会更难调试；每个新开发人员都必须先了解您的 git 基础架构，然后才能熟练使用您的代码库。这些不是放弃计划的理由，只是值得深思。
【讨论】：
您希望每个服务的存储库都有指向您的消息或合同存储库的子模块。这个 repo 将强制执行仅添加模型。这意味着您一旦发布了消息或合同，就无法删除它。您可以简单地添加新版本的按摩并停止使用旧版本。这使您可以进行增量部署。
【讨论】：