Git + SoA，一个仓库还是多个仓库？

Question

通常，当我启动一个新应用程序时，我会为其创建一个新的 git 存储库。当我想分享我的代码时，这被广泛接受并且与 Github 配合得很好。

在工作中，我在面向服务的架构中工作。一个非常常见的模式是同时向两个不同的应用程序添加一些代码——也许向一个应用程序添加一个具有 RESTful 接口(interface)的模型，并在另一个应用程序中添加一个用于管理它的 Web 前端。在这种情况下，使用单独的 git 存储库有一些缺陷。

以下是我认为使用独立存储库的缺点:

1. 我必须提交两次
2. 我不能很好地关联相关的提交
3. 没有一个地方可以回溯和追溯历史 - 我希望能够在一个地方提出当天的所有提交
4. 忘记提取一个或另一个 repo 是一个陷阱

另一方面，我经常使用 perforce，它的一个巨大的存储库模型也有很多缺点。 Perforce 具有旨在帮助您解决这些问题的功能，而 git 没有。

有没有人遇到过这种情况？你是怎么处理的呢？什么效果好，什么效果不好？

Answer 1

如果您的不同存储库是同一个全局应用程序的一部分，您可以将它们 merge 为 submodules within a main project .
从那里您可以:

• 在项目 P1 中只提交一次子模块(如果一个子模块需要在另一个项目 P2 中重用，你进入另一个项目 P2，在引用你刚刚在 P1 中提交的子模块的子目录中，检查提交，返回上一级并提交另一个项目 P2，因为 P2 必须引用与 P1 相同的提交)

• 所有相关提交都被主项目引用

• “ super 主”项目可以引用所有您的子模块，以便您拥有“返回并跟踪历史的单一位置”

• 您只需 pull 主项目，这将 pull 正确的子模块引用。