问多平台项目库设计策略

EN

这似乎是一个规模扩大的问题。存储库通常包含一个项目。一个项目的几个部分可能共享一个实用模块，但对于小型项目，规模不足以考虑将实用程序模块作为自己的实体分离。但是，一旦实用程序模块变得“大”，或者如果共享它的几个独立实体需要分离，它就需要成为自己的(版本)模块。

我的方法是使用单独的存储库，这取决于涉及的代码数量。我不知道你所说的增加任务是什么意思，尽管它是一个主要的重构。我要做的第一件事是将共享资源变成一个独立的存储库，并在每个平台构建中将该资源的发行版合并为(特定版本的)依赖。这使每个平台上的开发与单个共享资源版本脱钩。对共享项目的每一个更改都需要测试每个平台，现在您有了一个清晰的分界线。然后，您可以使每个项目都有自己的存储库一次。

如果您想要一个跨多个平台的项目的“共享版本”，您需要一个“项目”，它是该平台的构建代码的根。您也可以考虑使用该代码的共享存储库，但是将共享代码的发布与项目的版本结合起来。如果您的代码已经达到了这样的复杂程度，那么您可能想要的是另一个存储库，用于存放构建代码的“元项目”。除非您有大量的项目需要处理，否则多个项目的构建都可以驻留在一个存储库中，从而允许它们共享公共代码。同样的问题，但对于小规模，一个存储库工作。注意，所有这些假设一定程度的自动化测试:)

我对多模块项目的经验来自于使用perl和java。在perl中，使用来自CPAN的许多独立共享模块是惯例。在java中，可以使用Apache或Maven来处理模块依赖关系。我在一个环境中使用了Maven，这个环境为公司提供了一个顶级的元项目，对于每个产品(依赖于公司的元项目)，我使用了单独的项目。每个项目都可以自由地做它所需要的事情。从一个项目升级到两个或多个项目之间共享的代码将成为自己的项目。一个特别大的项目最终被分成几个项目，这些项目都继承了自己的“元项目”。处理这种层次依赖关系是构建Maven和Ivy的目的。我们使用Jenkins/Hudson作为集成服务器，每晚自动检查交叉项目构建(假设没有人逃避编写测试.)。一旦我们需要改变整个公司的网站。没问题，在公司的元项目中修改过一次，它在每个项目的新版本中都会自动被选中！

可能还有另一种解决办法：

分为三个(或更多)存储库：

platform1 specific
platform2 specific
common for all platforms

然后，您可以通过子模将公共回购添加到其他存储库中。

此外，谷歌还开发了一个定制工具：存储库，从而解决了安卓存储库中的类似问题。Repo使用一个定制的git存储库(清单)，其中包含一个XML文件(manifest.xml或default.xml，请参阅.Repo/舱单内部)，其中列出了哪些Git存储库应该签出。这样，您还可以像上面一样创建三个存储库，另一个存储XML文件来一起使用它们，甚至可以为这个清单git中的每个平台创建分支。

尽管我应该警告回购是非常专注于格瑞特。