我们即将开始将我们的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是否可行？
好奇是否有人对此有意见。感谢。
答案 0 :(得分：1)
Github flow将功能分支与单个产品相关联，但没有理由无法实现。您的工作流程选项取决于您部署应用程序的方式。考虑“MyApp”，它有三个组件服务：
MyApp
|- ServiceA
|- ServiceB
|- ServiceC
如果您可以独立于ServiceA和ServiceB部署ServiceC，更重要的是，可以独立于MyApp包含的代码部署所有这些代码，但不存在Service*然后只需将Github流程（您的首选工作流程）应用于每个存储库和团队。
如果服务交织在一起，并且部署ServiceA必然需要部署ServiceB或更重要的是，MyApp代表了一大块脚手架或路由代码，必须推进每个时间Services* repos之一，那么您可能需要submodules或subtree之类的内容。在该模型中，您将拥有一个Github流，以及＃4和＃5之间的额外步骤，即在部署之前收集服务的子模块（或子树）更新。我会避免使用没有子树或子模块的存储库嵌套，除非你（和你的团队）非常了解git。
所有这些都写了，我建议你深入了解你分割应用程序的动机。它有优势和成功的工作流程，但它们需要付出代价：获得历史的“全貌”更加困难;在某些情况下，使用git bisect等工具进行调试可能会更困难;每个新开发人员都必须先学习您的git基础架构，然后才能熟悉您的代码库。这些都不是放弃你的计划的理由，只是值得深思。
答案 1 :(得分：0)
您希望每个服务的存储库都有子模块，指向您的邮件或合同存储库。该回购将强制执行仅添加剂模型。这意味着您一旦发布了消息或合同，就无法删除它。您只需添加新版本的按摩并停止使用旧按摩即可。这允许您进行逐步推出。