【问题标题】:Git submodule (one more time)Git 子模块(再一次)
【发布时间】:2012-08-19 11:33:55
【问题描述】:

我有与 git 子模块有关的复杂问题/案例。我在 github 和第三方子模块上有自己的 repo(由其他公司提供,只读)。我处理了初始化子模块,更新它,将 .gitsubmodule 和新文件夹添加到主仓库等 - 一切正常。现在我想对子模块文件进行一些更改,将新文件添加到子模块或类似的东西。我做到了,然后我从子模块目录级别执行了提交。我将文件夹更改为主仓库,并且 git status 显示子模块文件夹中未提交的提交。所以...git commit -agit push。 (当我在子模块目录中检查 git 状态时,我得到的信息是您的分支在 X 提交之前领先于 'origin/master'。)

当我从 github 对我的 repo 进行递归克隆时,我遇到了错误(我想是由子模块的更改引起的):

fatal: reference is not a tree: c19485a57b5152959b9a916409ad5d901c44741d 
Unable to checkout 'c19485a57b5152959b9a916409ad5d901c44741d' in submodule path 'apt'

所以,我的问题是:

  1. 我可以在子模块中进行更改并将它们(和跟踪)推送到 github。
    • 如果是,我必须做的就是将我的所有带有子模块的 repo 和其中的更改拉到另一个主机(一些工作流程?)。
    • 如果没有,我如何通过从我的 github 存储库级别查看子模块并拉取到另一个主机来规避对子模块进行更改
  2. 有可能吗?

【问题讨论】:

    标签: git git-submodules


    【解决方案1】:

    我想你忘了从子模块内部运行git push。这必须在将提交推送到封闭项目之前完成,否则没有人将能够签出您更新的子模块(因为远程上不存在提交)。

    【讨论】:

    • 我无法从子模块运行git push,因为我很难过它是只读存储库 - 我没有足够的权限写入。
    【解决方案2】:

    问题是您想要更改您没有推送访问权限的第 3 方存储库。解决方案是制作您自己的该存储库的克隆——当您进行编辑时,您应该在该子存储库的上下文中提交它们并推送它们。外部存储库跟踪子模块的状态,但不应管理对子模块文件的更改。

    因此,工作流程解决方案是拥有您自己的 3rd 方 repo 的克隆,您确实有权访问该 repo。您应该将自己版本的 repo 作为子模块添加到您的项目中。我认为这个answer 将有助于消除关于正确使用子模块的一些困惑(诚然,有时这有点棘手)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-12-04
      • 2015-04-24
      • 2014-09-30
      • 2011-06-03
      • 1970-01-01
      • 2015-10-20
      • 2015-03-22
      • 1970-01-01
      相关资源
      最近更新 更多