包管理器与Git子模块/子树

虚空花岗岩

是否有任何理由使用软件包管理器而不是git子模块/子树,反之亦然?git解决方案似乎比简单的包管理器麻烦得多。

假设git子模块的节省空间的好处并不重要。

更新:有人为此问题添加了C ++标记,但此后我将其删除。这个问题不专门与C ++有关。欢迎接受比接受的答案更多的一般答案。

git解决方案似乎比简单的包管理器麻烦得多。

这不是麻烦

这是关于构建项目的两种不同方式:

  1. 通过二进制依赖关系,使用程序包管理器(NexusC ++的Conan声明您的依赖关系,然后程序包管理器获取它们并在编译过程中使用它们。
    ),一个pom.xml或一个npm-package.json:唯一代码库中的一个文件,这将指示编译器下载相关的依赖项
  2. 通过依赖关系以及Git子模块或子树,您可以在其中存储对其他源代码的引用,将其导入并重新编译所有内容。
    例如,如果您的系统由前端GUI源和后端源组成,则可以在一个父项目存储库中引用这两个存储库,并将它们的源合并为一个代码库。

第一个是在构建系统时很好的,其中每个部分都有其自己的发布生命周期,并且您希望依赖于预先构建的依赖项。

当依赖项与主程序之间的联系更加紧密时,使用第二种方法。

或者当没有二进制依赖(这是情况下,例如,与围棋它的模块)。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章