4

我有一个基于 .NET 的大型项目，其中包含超过 20 个单独的不同解决方案，每个解决方案代表更大系统中的不同模块。在每个解决方案中都有许多项目。

我们目前在一个 Git 存储库中处理所有解决方案，因为它们属于一起，并且到目前为止对我们来说效果很好。然而，现在我们想开始使用 CI 服务器来构建和测试修改。然而，这是开始变得毛茸茸的地方。我不能让 CI 服务器构建完整的解决方案，而只能构建已更改的组件。在 SVN 中，我们可以通过一个 repo 来实现这一点，并限制 CI 服务器的不同配置以监听不同的路径 - 例如，“src/ModuleA”是一个构建和配置，“src/ModuleB”是另一个。

我在 Git 中有哪些选择，什么是最佳实践？他们的优缺点是什么？我很想指出一个更大的开源解决方案，它具有类似的设置作为答案的一部分。

  1. 我想我可以将每个模块都放在自己的仓库中？但是，当涉及到在 GitHub 等上托管时，这是一个问题，因为他们通过 repo 收费......否则这会是最好的选择吗？
  2. Git 子模块会起作用吗？这是子模块的正确用途吗？
  3. 您是否知道 CI 产品中可以通过某种方式帮助解决此场景的其他选项？
4

3 回答 3

2

我想我可以将每个模块都放在自己的仓库中？但是，当涉及到在 GitHub 等上托管时，这是一个问题，因为他们通过 repo 收费......否则这会是最好的选择吗？

这仍然是最好的选择，除非这些模块过于相互依赖，这意味着在管理分支时会遇到额外的障碍（因为您需要记住同时分支所有或大部分模块，合并回来也是如此）

如果收费是个问题，请记住您可以在 BitBucket 存储库中有一个类似的组织（它提供免费的 私人存储库，尽管是针对小团队的）

一旦您在自己的 git 存储库中拥有每个模块，您就可以将它们与子树或子模块结合起来，正如我在“结合在 git 存储库中的子项目中增长的基础项目，除了 git 子模块或子树合并方法”中所解释的那样。
git slave也可以是一个更简单的选择。

于 2013-02-03T18:30:17.303 回答
1

虽然git submodule和git subtree都是很好（但不同）的子组件管理解决方案，但它们确实有一些缺点

git子模块：

  • 您最终会得到多个存储库。
  • 您必须分别管理每个存储库。
  • 用户界面有时完全令人困惑。

git subtree （我没有经常使用它，所以我的反对意见可能没有根据）：

  • 您对整个项目只有一个历史记录。虽然这很好用，而且总有一种方法可以分离历史，但是没有简单的方法可以将任意版本的组件组合到一个系统中。

我设计了一种称为git components的方法，它在单个存储库中工作（如 git subtree），并为您提供独立组件历史的灵活性（如 git submodule）。

该方法基于路径检出：（ checkout <branch_name> -- .注意尾随点）。

该方法使用一个简单的类似清单的 bash 脚本，并强加了一些命名约定以方便组件管理。

您可以在此处找到该方法的完整描述和玩具实现：

https://github.com/picrin/git-components

编辑

正如VonC所建议的，我尝试将其与 git 2.5 提供的新 git 功能结合起来git worktree。虽然 2.5 尚不可用（除非您从未来来到这里），但最新的 master 具有该功能并且似乎运行良好。

我建议git worktree与 git 组件一起使用的方法是检查主工作树以掌握，并为每个组件和系统的每个版本（clientA、clientB 等）创建一个工作树。这样，您可以同时处理每个组件，而无需在有人打扰您对组件 2 进行快速修复时将您的工作隐藏在组件 1 上。

于 2015-07-25T22:01:56.853 回答
1

另一种选择是使用git sparse-checkout。这使您能够在过滤掉其他所有内容的同时，指定您希望在本地工作目录（例如“src/ModuleA”）中的 git 存储库中的哪些文件夹。

如果您的集成工具了解 git 的 sparse-checkout 功能，或者您可以设置一个脚本来为您的集成工具执行 sparse-checkout，那么这可能会解决您的问题。

于 2021-08-06T21:52:21.570 回答