【问题标题】:Git multiple submodule referencesGit 多个子模块引用
【发布时间】:2016-02-26 16:34:49
【问题描述】:

我对 git 很陌生,我不知道如何以最好的方式解决这个特定问题。希望大家能给我一些好的解决方案。我在网上搜索但找不到这样的例子来解决我的问题。也许这是一个设计缺陷?我只是找不到好的解决方案。

我有以下项目:

  • 常见
  • SqlApi:取决于具体的 Common 版本
  • CoreLogic:取决于具体的 Common 和 SqlApi 版本
  • 项目A:取决于具体的CoreLogic、SqlApi和Common版本
  • 项目 B:取决于特定的 CoreLogic 和 Common 版本

有了子模块,项目A的工作目录是这样的:

Project A
    - Common(1)
    - SqlApi(1)
        + Common(2)
    - CoreLogic
        + Common(3)
        + SqlApi(2)
            * Common(4)

有没有更好的方法来摆脱 Common (2-4) 和 SqlApi (2) 并让它们都链接到同一个项目中的相同 Common/SqlApi(1) 版本?

也许我只是“常规盲”,但我需要一些帮助来解决这个问题。

【问题讨论】:

    标签: git dependencies git-submodules


    【解决方案1】:

    有没有更好的办法摆脱Common(2-4)和SqlApi(2)

    简单:在 ProjectA 中,您只需创建 git submodule update --init,而不是 git submodule update --init --recursive (or git clone --recursive)

    这将给出:

    Project A
        - Common(1)
        - SqlApi(1)
        - CoreLogic
    

    这意味着:

    • SqlAPICoreLogic 能够基于变量构建(Common 路径一个变量,SqlAPI 路径一个变量,
    • Project A 有一个构建脚本,它将充分设置 SqlAPICommon 路径。

    这并不容易表明这些版本可能在 Project A 所需的版本与其中一个子模块所需的版本之间存在差异/重叠。

    【讨论】:

    • 感谢您的回复。这意味着 git 将检查/更新通过项目 A 的子模块引用的 SqlApi 和 Common 的提交,对吗?
    • @s7urmi 是的,Project1 将这些子模块的 SHA1 记录为 gitlink (special entries in the index)。
    • k,听起来不错,我马上试试。感谢您的帮助!
    猜你喜欢
    • 2015-11-25
    • 1970-01-01
    • 2021-01-19
    • 2015-04-24
    • 2011-10-05
    • 2013-07-28
    • 1970-01-01
    • 1970-01-01
    • 2017-04-20
    相关资源
    最近更新 更多