但现在这种情况,主项目记录的子模块版本并没有变化, git submodule update 自然也不会将子模块更新到新版本。 此时,一般需要进入到子模块的目录主动拉取新版,再按照第二种情况进行操作。 也可以使用下面的命令,将所有子模块全部更新。 git submodule foreach 'git pull' 删除 submodule 按照当前的例子,从 project-...
$ git submodule update --remote xxx // 指定需要同步的子模块 子模块目录下更新: git pull 默认情况下会跟踪子模块的 master 分支,设置为其他分支: a. .gitmodules 设置 git config -f .gitmodules submodule.[submodule-name].branch [branch-name] 如果不用 -f .gitmodule...
记录主项目中Submodules的目录位置 记录引用Submodule的commit id 在project1中push之后其实就是更新了引用的commit id,然后project1-b在clone的时候获取到了submodule的commit id,然后当执行git submodule update的时候git就根据gitlink获取submodule的commit id,最后获取submodule的文件,所以clone之后不在任何分支上;但是mas...
查看当前仓库的submodule状态,包括submodule的submodule状态(if you want to show nested submodules.): git submodule status --recursive 七. 更改submodule的版本 我一开始直接用的git submodule update --remote path-to-submodule的指令,cmd界面上成功走完了,没报错,但是我进去我的submodule里,发现文件内容并没有...
难道还是像project1中那样进入子模块的目录然后git checkout master,接着git pull? 而且现在仅仅才两个子模块、两个项目,如果在真实的项目中使用的话可能几个到几十个不等,再加上N个submodule,自己算一下要怎么更新多少个submodules? 例如笔者现在做的一个项目有5个web模块,每个web模块引用公共的css、js、images...
你需要在 git pull 之后,调用 git submodule update 来更新 submodule 信息。这儿的坑在于,如果你 git pull 之后,忘记了调用 git submodule update,那么你极有可能再次把旧的submodule 依赖信息提交上去(使用 git submit -am "message" 或者 git add . 提交的人会遇到这种事)。
如果子模块已经被初始化过，只需要使用git submodule update recursive来更新。 如果需要更新子模块到最新的commit，可以先进入子模块的目录，然后执行git pull命令更新子模块，再回到父仓库目录执行git add <pathtosubmodule>和git commit来记录子模块的更新。修改子模块： 在父仓库中，进入子模块的目录，对...
在进行Pull操作之后,Git会进行自动地合并操作,结果大概是这样的: 这个第M个提交即代表着合并的提交,也就是Anna本地的分支与Github上的特征分支最终合并的点,现在Anna解决了所有的合并冲突并且可以Push她的代码,在Bob进行Pull之后,每个人的Git Commit结构为: ...
Git Submodule使用 git submodule是一个很好的多项目使用共同类库的工具,它允许类库项目做为repository,子项目做为一个单独的git项目存在父项目中,子项目可以有自己的独立的commit,push,pull。而父项目以Submodule的形式包含子项目,父项目可以指定子项目header,父项目中会的提交信息包含Submodule的信息,再clone父项目的...
git pull 默认情况下会跟踪子模块的 master 分支,设置为其他分支: a. .gitmodules 设置 代码语言:javascript 代码运行次数:0 运行 AI代码解释 git config-f.gitmodules submodule.[submodule-name].branch[branch-name] 如果不用 -f .gitmodules 选项,那么它只会为你做修改。但是在仓库中保留跟踪信息更有意义一...