我们有一个相当大但过于困惑的代码库，我们希望迁移到使用 Git。目前，它是一个巨大的整体 block ，无法轻易拆分成更小的独立组件。该代码构建了大量的共享库，但它们的源代码交织在一起，目前无法将其完全分离到单独的存储库中。
我不太关心 Git 是否可以处理将所有代码放在一个存储库中的问题，但问题是我们需要对源代码和许多从中构建的库进行版本控制。从头开始构建一切都需要数小时，因此在检查代码时，开发人员还应该获得这些库的预编译版本以节省时间。
这是我可以使用一些建议的地方。这些库不需要是 100% 最新的(因为它们通常保持二进制兼容性，并且在必要时始终可以由各个开发人员重建)，所以我正在寻找避免弄乱我们的源代码存储库的方法有无数版本略有不同的二进制文件，无论如何都可以从源代码中重新生成这些文件，同时仍然使开发人员可以轻松访问这些库，这样他们就不必从头开始重建所有内容。
所以我想要一些方法来实现如下内容。
- 这些库由我们的构建服务器定期生成，然后可以将它们提交到 Git 存储库。然后，开发人员应该将这些文件视为只读( pull 最新版本，必要时就地重建，但不要提交新版本)，理想情况下，Git 应该强制执行此操作。 (特别是，运行快速
git commit -a的开发人员不应该因所有这些生成文件的新修订而意外污染存储库) - 将这些文件保存在一个单独的存储库中，这样源代码就不必永久携带所有这些生成的二进制文件(因为它们可以方便地减少编译时间，但它们实际上不是必要的)。
当然，同时，使用这些的过程也要尽可能的顺畅。在查看源代码时，应该遵循从中构建的库(或者至少，很容易获得)。并且在提交时，不应该意外提交这些库的新版本，只是因为它们被重新编译并且现在嵌入了不同的时间戳。
我一直在寻找使用 git 的 子模块 的选项，创建包含源代码的“ super ”存储库，然后为生成的库创建一个或多个子模块，但到目前为止，它对我来说似乎有点笨拙和脆弱。看起来他们实际上并没有阻止开发人员直接向子模块提交更改，它只是导致事情进一步崩溃(在玩弄子模块时，我最终得到了更多detached HEAD 比我想数的多)。
考虑到我们几乎所有的开发人员都是 Git 的新手，这最终可能会浪费更多的时间而不是为我们节省的时间。
那么我们的选择是什么？子模块方法对你们这些 Git 专家来说听起来明智吗？我如何“驯服”它，使它对我们的开发人员尽可能易于使用(并且不易搞砸)？
或者是否存在我们尚未考虑过的完全不同的解决方案？
我应该提一下，我才使用 Git 几天，所以我自己几乎是个新手。
最佳答案
我会将它们保存在源文件的单独存储库中。您可以使用“git submodules”来保持两者之间的引用；所以“编译库”成为父模块，源代码成为子模块。这样，当您提交库时，您提交了对当时源代码的确切位置的引用。
此外，由于开发人员不需要完整的历史记录，您可以使用 git clone --depth 1 libs.git，它只为您提供最新版本的库。它不会提取更多历史记录，也不允许您提交(这没关系，因为服务器应该为您执行此操作)并且您将允许他们访问最新版本(或您在克隆上指定的任何分支使用 -b 命令)。
理想情况下，您不希望主 git 存储库包含或指向二进制存储库。
关于git - 在 Git 中存储生成的文件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5632280/