git - 使用 git 处理静态库修订(即二进制文件)的见解

Question

我正在寻找有关如何处理每个都使用(大型)静态库的 git 存储库的一些见解，并且对我考虑的解决方案有一些担忧。

假设有很多独立的项目，都在版本控制下，每个项目都依赖于一个正在(非常)积极开发的大型静态库。假设 repo A , B , C , ...都有自己的开发团队，都依赖lib .现在，lib项目本身处于版本控制之下，并且还由另一个团队进行处理。让我们假设一些团队不能/不应该访问 lib 的来源，但可以访问 header 和静态库二进制文件。

现在，当我第一次想到如何在 git repos 中组织这种情况时，我立刻想到了子模块。这是一个快速图表:

"lib" repo:
    Dist/ -> "lib_dist" submodule
    Headers/
    Sources/
    ...

"lib_dist" repo:
    Binaries/ (output from "lib" repo build process)
    Headers/ (copied from "lib" repo in its build script)

"A" repo:
    Headers/
    Libs/
        lib_dist/ -> "lib_dist" submodule
    Sources/

"B" repo:
    (looks just like "A")

"C" repo:
    (again looks like "A")

lib 的构建过程会将源代码编译成静态库文件并将 header 复制到 Dist子文件夹。此子文件夹是 lib 的子模块 repo ，我们称之为 lib_dist repo 。这lib_dist然后可以将 repo 添加到 A , B , C , ...作为子模块。

优势:团队中的开发人员 A , B , C等就不用自己编译这么大的静态库了，看不到lib的源码, 和 A , B , C , repos 将始终能够编译无论开发人员使用的是哪个版本。我的意思是，如果项目开发人员 A需要返回到旧版本，他们可以简单地 git checkout <rev_hash> .然后 git submodule update ;即使lib_dist自时间以来发生了变化 <rev_hash>已提交，将调整子模块版本以匹配当时的版本 <rev_hash>被制成。这意味着 lib_dist header 和二进制文件将“正常工作”。

缺点:随着时间的推移(并且由于积极开发而加剧)，lib_dist repo 协议(protocol)将增长非常大，因为 git 实际上并不是要在版本控制下存储二进制文件。超过 1GB 的 Git 存储库确实会给服务器带来负担，推送/pull 将变得非常耗时和资源密集。

那么，在这种情况下，“最佳实践”是什么？ git 是正确的工具吗？是否存在更好的工具(我对其他版本控制工具持开放态度)？除了手动管理 lib，我什么都没想到版本。但是，在我看来，手动管理静态库的待编译版本太……20 世纪了(而且容易出错)。

谢谢!

编辑:我应该补充一点，这些项目是用 C/C++ 编写的。

Answer 1

我不建议使用 git 来管理库二进制文件，因为 git 的核心功能是版本控制，这不是您所需要的。此外，如果您在多个平台上构建，则必须为每个平台提供单独的二进制文件。

您真正在寻找的似乎是某种自动化的依赖管理，例如用于 Java 的 Maven。