在Git中存储生成的文件

Question

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

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

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

所以我想要一些方法来实现类似以下的东西.

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

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

我一直在寻找使用git 子模块的选项,创建包含源代码的"超级"存储库,然后创建生成库的一个或多个子模块,但到目前为止,它似乎有点过于笨拙和脆弱我的口味.看起来它们实际上并没有阻止开发人员直接对子模块进行更改,它只会导致事情进一步突破(在使用子模块时,我最终得到了detached HEAD比我更重要的s) .

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

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

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

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

Answer 1

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

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

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

Answer 2

理想的解决方案是避免对二进制文件进行版本控制并将其存储在像Nexus这样的工件库中.

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

• 许多版本的交付都是中间构建,需要在某个时刻进行清理
• 清理(​​删除旧版本)在VCS中很难做到,在工件库中很容易做到.
• 回购的大小将成为问题(特别是对于DVCS,除非您总是获得最新版本,在这种情况下,浅层克隆可能会缓解该问题)
• 没有办法将二进制版本与另一个版本进行比较(所以"版本化"没有多大意义)

Answer 3

我不是 git 专家，但我想这可以通过子模块来解决。将预编译的二进制文件添加为子模块，要获取它们，只需执行以下操作：

git submodule update --init

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