在 Git 中存储生成的文件

Question

我们希望使用 Git 迁移到相当大且过于混乱的代码库。目前，它是一个庞大的整体块，不能轻易拆分成更小的独立组件。该代码构建了大量的共享库，但它们的源代码交错得如此之快，以至于目前无法将其干净地分离到单独的存储库中。

我不太关心 Git 是否可以处理将所有代码都放在一个存储库中，但问题是我们需要对源代码和从它构建的许多库进行版本控制。从头开始构建所有内容需要数小时，因此在检查代码时，开发人员还应该获得这些库的预编译版本以节省时间。

这是我可以使用一些建议的地方。这些库不需要 100% 是最新的（因为它们通常保持二进制兼容性，并且在必要时始终可以由单个开发人员重新构建），所以我正在寻找避免弄乱我们的源代码存储库的方法无论如何，可以从源代码重新生成无数略有不同的二进制文件版本，同时仍然使开发人员可以轻松访问这些库，因此他们不必从头开始重新构建所有内容。

所以我想要一些方法来实现以下目标。

• 这些库由我们的构建服务器定期生成，然后可以将它们提交到 Git 存储库。然后开发人员应该将这些文件视为只读文件（拉取最新版本，并在必要时重建，但不要提交新版本），理想情况下，Git 应该强制执行此操作。 （特别是，运行快速git commit -a 的开发人员最终不应该因为所有这些生成的文件的新版本而意外污染存储库）
• 将这些文件保存在单独的存储库中，这样源代码就不必永远携带所有这些生成的二进制文件（因为它们可以方便地减少编译时间，但它们实际上并不是 必要的）。

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

我一直在研究使用 git 的 子模块 的选项，创建包含源代码的“超级”存储库，然后为生成的库创建一个或多个子模块，但到目前为止，它对我来说似乎有点笨拙和脆弱。似乎他们实际上并没有阻止开发人员直接将更改提交到子模块，它只会导致事情进一步分解（在玩子模块时，我最终得到了更多detached HEADs 比我想数）。

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

那么我们有哪些选择？子模块方法对你那里的 Git 大师来说是否合理？以及我如何“驯服”它，以便我们的开发人员尽可能地易于使用（并且难以搞砸）？

或者有没有我们没有考虑过的完全不同的解决方案？

我应该提一下，我只使用了几天 Git，所以我自己几乎是个新手。

Answer 1

我会将它们保存在源文件的单独存储库中。您可以使用“git submodules”来保持两者之间的引用；所以“编译的库”成为父模块，源代码成为子模块。这样，当您提交库时，您就提交了对当时源代码确切点的引用。

此外，由于开发人员不需要完整的历史记录，您可以使用 git clone --depth 1 libs.git 它只为您提供最新版本的库。它不会提取更多历史记录，也不允许您提交（这没关系，因为服务器应该为您执行此操作）并且您将让他们访问最新版本（或您在克隆上指定的任何分支带有 -b) 的命令。

理想情况下，您不希望主 git 存储库包含或指向二进制存储库。

Answer 2

理想的解决方案是避免对二进制文件进行版本控制，并将它们存储在 artifact repository 中，例如 Nexus。

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

• 交付的许多版本都是中间版本，需要在某个时间点或另一个点进行清理
• 清理（删除旧版本）在 VCS 中非常困难，但在工件存储库中却很容易。
• repo 的大小将成为一个问题（尤其是对于 DVCS，除非您始终获得最新版本，在这种情况下，浅层克隆可能可以缓解该问题）
• 无法将二进制文件的版本与另一个版本进行比较（因此“版本控制”没有多大意义）

Answer 3

我不是 git-guru，但我想这可以通过子模块来解决。将预编译的二进制文件添加为子模块，要获得它们，只需这样做：

git submodule update --init

here 描述了如何忽略子模块中的更改。因此，如果开发人员重建了某些内容，则不会使用git commit -a 提交，也不会使用git add . 添加。他们只需要确保他们不会直接从子模块中提交某些内容。这个Vimcast 展示了如何使用子模块来控制你的vim文件，但这应该很容易适应你的问题。