git - 多平台项目存储库设计策略

Question

在处理多平台项目时，我正在寻找有关存储库布局/设计的策略。通常依赖项是:

• 项目有单一名称/品牌
• 每个平台都有独立的源代码
• 平台代码共享公共(public)资源
• 设计文档和其他文档在平台之间共享

我已经尝试(使用 git)如下:

解决方案 A:

• 每个平台项目都位于自己的目录中
• 提交到所有平台的 master

优点:

• 干净的代码开发
• 不 merge

缺点:

• 日志乱七八糟，你通常需要在所有提交日志前加上平台前缀
• 有时逆转提交是..不可能的或非常困难/困惑

解决方案 B:

• 每个平台都有自己的分支
• 发布时对每个分支执行rebase，然后 merge 到master + tag

优点:

• 清理日志 :)
• 清洁分离以促进发展
• 减少冲突

缺点:

• 需要 merge 到master
• 当所有平台同时 rebase 时 - merge 到 master 是 hell

我对创建每个平台的存储库犹豫不决，因为共享资源可能很困难，或者需要额外的、可能容易出错的任务。

期待您的专业知识。

Answer 1

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

我的方法会使用单独的存储库，具体取决于涉及的代码量。我不确定你所说的添加任务是什么意思，尽管它是一个主要的重构。我要做的第一件事是将共享资源变成一个独立的存储库，并将其发布作为(特定于版本的)依赖项 merge 到每个平台构建中。这将每个平台上的开发与单个共享资源版本分离。无论如何，对共享项目的每次更改都需要测试每个平台，现在您有了一条清晰的分界线。然后，您可以让每个项目都拥有自己的存储库，一次一个。

如果您想跨多个平台“共享发布”一个项目，您需要一个“项目”作为构建代码的根。您也可以考虑为该代码使用共享存储库，但这会将共享代码的发布与项目的发布结合在一起。如果您的代码已经达到这种复杂程度，您可能想要的是另一个存储库，仅用于 stash 您的构建代码的“元项目”。除非你有一大群项目要处理，否则多个项目的构建可以全部驻留在一个存储库中，允许它们共享公共(public)代码。再次出现同样的问题，但规模较小，单个存储库有效。请注意，所有这些都假设了一定程度的自动化测试:)

我在多模块项目方面的经验来自使用 perl 和 java。在 perl 中，使用许多来自 CPAN 的独立共享模块是常态。在 java 中，可以使用 Apache Ivy 或 Maven 处理模块化依赖关系。我在一个环境中使用 Maven，该环境具有公司的顶级元项目和每个产品的单独项目(取决于公司的元项目)。每个项目都可以自由地做它需要的事情。从一个项目升级到两个或多个项目之间共享的代码将成为其自身的项目。一个特别大的项目最终被分解成几个项目，所有项目都继承自它自己的“元项目”。处理这种层次依赖是 Maven 和 Ivy 的初衷。我们使用 Jenkins/Hudson 作为集成服务器，每晚自动检查跨项目构建(假设没有人逃避编写测试……)。有一次我们需要为整个公司更改网站。没问题，在公司元项目中更改一次，它会在每个项目的新版本中自动获取!