在Git中存储生成的文件

我们有一个相当大的、非常混乱的代码库，我们希望使用Git迁移到它。目前，它是一个巨大的整体块，不容易分割成更小的独立组件。该代码构建了大量共享库，但它们的源代码是如此交错，以至于目前无法将其清晰地分离到单独的存储库中

我不太关心Git是否能够将所有代码放在一个存储库中，但问题是我们需要对源代码和许多基于源代码构建的库进行版本化。从头开始构建所有东西都需要几个小时，因此在签出代码时，开发人员还应该获得这些库的预编译版本以节省时间

这是我需要一些建议的地方。这些库不需要是100%最新的（因为它们通常保持二进制兼容性，并且在必要时可以由单个开发人员重新构建），因此，我正在寻找一些方法来避免我们的源代码存储库被无数不同版本的二进制文件弄得乱七八糟，这些文件无论如何都可以从源代码中重新生成，同时仍然可以让开发人员很容易地访问这些库，这样他们就不必从头开始重建一切

所以我想通过某种方式来实现如下目标

• 这些库由我们的构建服务器定期生成，然后可以将它们提交到Git存储库。然后，开发人员应该将这些文件视为只读文件（获取最新版本，必要时重新生成，但不提交新版本），理想情况下，Git应该强制执行这一点。（特别是，运行quick

  git commit-a

  的开发人员不应该意外地用所有这些生成文件的新版本污染存储库）
• 将这些文件保存在单独的存储库中，这样源代码就不必永久地携带所有这些生成的二进制文件（因为它们可以方便地减少编译时间，但实际上并不需要）

当然，与此同时，使用这些工具的过程应该尽可能顺利。在签出源代码时，从中构建的库应该遵循（或者至少很容易获得）。在提交时，不应该仅仅因为重新编译了这些库，并且现在嵌入了不同的时间戳，就意外地提交这些库的新版本

我一直在考虑使用git的子模块，创建包含源代码的“超级”存储库，然后为生成的库创建一个或多个子模块，但到目前为止，对我来说，这似乎有点笨拙和脆弱。看起来它们实际上并没有阻止开发人员直接将更改提交到子模块，它只是导致事情进一步恶化（在玩子模块时，我得到的

分离头比我想计算的要多）

考虑到我们几乎所有的开发人员都是Git新手，这最终可能会浪费比它节省我们更多的时间

那么我们的选择是什么呢？对于Git大师来说，子模块方法听起来合理吗？我如何“驯服”它，使它对我们的开发人员来说尽可能容易使用（而且很难搞糟）

还是有一个完全不同的解决方案我们没有考虑

我应该提到的是，我只使用Git几天，所以我自己也是一个新手。
我会将这些保存在源文件的单独存储库中。您可以使用“git子模块”在两者之间保留引用；因此，“编译的libs”成为父模块，而源模块成为子模块。这样，当您提交libs时，您就提交了对源代码当时确切位置的引用

此外，由于开发人员不需要完整的历史记录，因此可以使用git clone--depth 1libs.git，它只提供最新版本的libs。它不会提取进一步的历史记录，也不允许您提交（这是可以的，因为服务器应该为您这样做），您将允许他们访问最新版本（或使用-b在clone命令中指定的任何分支）

理想情况下，您不希望主git存储库包含或指向二进制存储库。
我不是git大师，但我想这可以通过子模块解决。将预编译的二进制文件添加为子模块，要获得它们，只需执行以下操作：

git submodule update --init

描述了如何忽略子模块中的更改。因此，如果开发人员重新编译某些内容，那么它将不会使用
git commit-a提交，也不会使用
git add添加。
。他们只需要确保不直接从子模块中提交某些内容。这显示了如何使用子模块来控制VIM文件，但这应该很容易适应您的问题。
理想的解决方案是避免对二进制文件进行版本控制，并将它们存储在类似的文件中

VCS中的交付问题在于，VCS设计用于记录和保存其管理的所有文件的历史记录，而：


交付的许多版本都是中间版本，需要在某个时刻进行清理
清理（删除旧版本）在VCS中很难做到，在工件库中很容易做到
回购的规模将成为一个问题（特别是对于DVCS，除非您总是获得最新版本，在这种情况下，浅层克隆可能会缓解该问题）
无法将二进制文件的一个版本与另一个版本进行比较（因此“版本控制”没有多大意义）
这是正确的依赖关系图：编译的lib依赖于源（=>编译的lib将源作为子模块），而不是相反。我也有同样的问题。子模块方法是否有效？哪个成为了子模块，源代码还是二进制文件？