我们有一个相当大且过于混乱的代码库，我们希望使用 Git 进行迁移。目前，它是一个大的整体块，不能轻易地分割成更小的独立组件。该代码构建了大量共享库，但它们的源代码如此交错，目前无法将其干净地分离到单独的存储库中。
我不太关心 Git 是否可以处理将所有代码放在一个存储库中，但问题是我们需要对源代码和从中构建的许多库进行版本控制。从头开始构建所有内容需要几个小时，因此在检查代码时，开发人员还应该获取这些库的预编译版本以节省时间。
这是我可以使用一些建议的地方。这些库不需要 100% 是最新的（因为它们通常保持二进制兼容性，并且在必要时始终可以由个人开发人员重建），因此我正在寻找避免弄乱我们的源代码存储库的方法具有无数略有不同版本的二进制文件，可以从源重新生成anyway，同时仍然使开发人员可以轻松访问这些库，这样他们就不必从头开始重建所有内容。
所以我想要某种方法来实现类似以下的目标。
- 这些库由我们的构建服务器定期生成，然后可以将它们提交到 Git 存储库。然后，开发人员应该将这些文件视为只读（拉取最新版本，并在必要时就地重建，但不要提交新版本），理想情况下，Git 应该强制执行这一点。 （特别是，开发人员运行快速
git commit -a不应该最终因所有这些生成的文件的新版本而意外污染存储库）
- 将这些文件保存在单独的存储库中，这样源代码就不必永远携带所有这些生成的二进制文件（因为它们可以方便地减少编译时间，但实际上它们并不是必要的).
当然，同时，使用这些的过程也应该尽可能的顺利。在检查源代码时，从中构建的库应该遵循（或者至少很容易获得）。并且在提交时，不应该仅仅因为它们被重新编译并且现在嵌入了不同的时间戳而意外地提交这些库的新版本。
我一直在寻找使用 git 的选项子模块，创建包含源代码的“超级”存储库，然后为生成的库创建一个或多个子模块，但到目前为止，对于我的口味来说，它似乎有点过于笨拙和脆弱。看来他们实际上并没有prevent开发人员直接向子模块提交更改，只会导致事情进一步恶化（在使用子模块时，我最终得到了更多detached HEAD比我想数的多）。
考虑到我们几乎所有的开发人员都是 Git 新手，这最终可能会浪费更多的时间，而不是为我们节省的时间。
那么我们有什么选择呢？对于 Git 专家来说，子模块方法听起来合理吗？我如何“驯服”它，以便它对我们的开发人员来说尽可能易于使用（并且很难搞砸）？
或者是否有我们没有考虑过的完全不同的解决方案？
我应该提到的是，我只使用了 Git 几天，所以我自己也算是个新手。
我会将它们保存在与源文件不同的存储库中。您可以使用“git submodules”来保留两者之间的引用；因此“编译的库”成为父模块，源代码成为子模块。这样，当您提交库时，您就提交了对当时源代码的确切位置的引用。
此外，由于开发人员不需要完整的历史记录，因此您可以使用 git clone --depth 1 libs.git 它只为您提供最新版本的库。它不会提取进一步的历史记录，并且不允许您提交（这是可以的，因为服务器应该为您执行此操作），并且您将允许他们访问最新版本（或您在克隆上指定的任何分支）命令与 -b)。
理想情况下，您不希望主 git 存储库包含或指向二进制存储库。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
