一、实际问题

在实际应用中遇到了一些代码管理问题，一个工程需要依赖其它几个子模块。其中一个模块由于不小心在本地的应用中修改后提交了（即A中有子模块B，直接在A中将B修改提交了，而不是修改B工程，再在A中更新）即开发者将module本地hash提交到了主分支. 因此其它开发者更新时候因为gitlab中不含有这个hash分支而无法正常获取。结果导致服务器打包时无法正常的拉取相关的子模块，最终的现象就是数据不一致，引发了一些模块的崩溃。

二、初步解决

在确定是这个问题后，使用原有的命令：

#enter sub path
git submodule update --remote

本地环境可以实现，但如果使用自动环境（如Jenkins），仍然会拉取老的子模块代码。经过查找相关资料，发现可以使用下面的方法：
1、在Git中删除原子模块的依赖并再次增加
1）删除原子模块
执行下列命令：

git submodule deinit -f 子模块路径
git rm -f 子模块路径
git add -u
git commit -m "删除子模块"
git push
#也可使用其它GIT删除子模块方法 

2）增加相关模块
有两种方法：
第一种是：

git submodule add -b main --force  git@192.168.3.214:libs/子模块名字.git

第二种：

git submodule add <url> <path>
git submodule add <git库URL> path  //如果进入path则不用再指定

然后：

git add .(-u)
git commit
git push

说明：这样做可能不太安全，需要下面的4的处理方式

2、强制更新方式

git submodule foreach git pull origin main
或
git submodule foreach git submodule update --remote（此种未测试）

3、子模块改名
在上述的实际问题中，有一个子模块是需要改名字的，即可能拉下来是A,但实际的名字叫B，可以使用下面的方法：

git mv msglib msg
git submodule sync

它可以放在1的增加相关模块后，注意，如果只是单纯的修改名字，此时就可以使用提交命令提交即可。否则需要等最终一起提交修改。
4、安全说明
如果在上面直接提交子模块的更新，则可能导致安全性的问题，比如提交的有问题。那么可以使用分支的方式进行：

git checkout -b fixmiss_module

git commit -m "fix"

#git push origin fixmiss_module:main

分支提交一般容易为GIT跟踪和控制，这也是一个好的应用习惯。

三、总结

用得越多，遇到的问题也越多，这就是经验的来源。经验是一个好的东西，也是一个不好的东西。它让人可以快速的处理实际问题也可以让人固化于这种思维。至于如何打破这种边界，需要自己不断的学习，与时俱进。