Question

我们有一个相当大的，太混乱的代码库，我们希望迁移到使用Git。目前，它是一个巨大的单片块，不能轻易拆分成更小的独立组件。该代码构建了大量的共享库，但它们的源代码是交错的，目前无法将它干净地分成单独的存储库。

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

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

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

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

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

我一直在考虑使用git的子模块的选项，创建包含源代码的“超级”存储库，然后创建生成库的一个或多个子模块，但到目前为止，它对我来说似乎有点过于笨拙和脆弱。看起来他们实际上并没有阻止开发人员直接向子模块提交更改，这只会导致事情进一步突破（在玩子模块时，我最终得到了更多） detached HEAD而不是我想要的数字。）

考虑到几乎我们所有的开发人员都是Git的新手，最终可能会浪费更多时间而不是拯救我们。

那么我们的选择是什么？那个子模块对你来说听起来很合理Git guru吗？我如何“驯服”它，所以我们的开发人员尽可能容易使用（并且很难搞乱）？

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

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

Answer 1

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

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

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

Answer 2

理想的解决方案是避免对二进制文件进行版本控制，并将其存储在<{> 3 {}等 artifact repository 中。

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

许多版本的交付都是中间版本，需要在某个时间点清理
清理（删除旧版本）在VCS中很难做到，在工件库中很容易做到。
回购的大小将成为问题（特别是对于DVCS，除非您总是获得最新版本，在这种情况下，浅层克隆可能会缓解该问题）
无法将二进制版本与另一版本进行比较（因此“版本化”没有多大意义）

Answer 3

我不是一个git-guru，但我想这可以通过子模块来解决。将预编译的二进制文件作为子模块添加，然后只需执行此操作即可：

git submodule update --init

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

在Git中存储生成的文件

3 个答案: