Git提交到公共子模块（master分支）
我有两个或两个以上的项目（让我们称之为ProjectFoo和ProjectBar ）具有一些通用的代码 ，我把它们放在一个子模块中 。
我的理解是，如果我从ProjectFoo内部对子模块提交更改，它将会是一个独立的头，只有所有ProjectFoo克隆可以看到：
(master) $ cd ProjectFooBarCommoneSubmodule/ (master) $ git commit -am "Common code fix." (56f21fb0...) $ git push Everything up-to-date 这可能是因为master分支没有改变。 我可以做一些像git checkout master && git merge Everything up-to-date但看起来很丑。 可能是一个git reset --hard master做同样的事情，但似乎更丑陋。
如何让项目共享一个共同的代码， 在使用它的项目中进行更新？ 换句话说，对该子模块的提交应该更新所有使用同一个子模块的各种存储库（ 存储库，而不仅仅是克隆 ）。
—-编辑—-
显然，我的签出库被搞砸了。 它应该从一开始就这样工作（在这个例子中是ProjectFoo ）：
(master) $ cd ProjectFooBarCommoneSubmodule/ (master) $ git commit -am "Common code fix." (master) $ git push .... fbfdd71..0acce63 master -> master (master) $ cd .. (master) $ git add ProjectFooBarCommoneSubmodule (master) $ git commit -m "Submodule update."
然后从其他项目（如ProjectBar）获取该更改：
(master) $ cd ProjectFooBarCommoneSubmodule/ (master) $ git pull
将更新到最新的通用代码。 如果在分离的头上，可能需要使用git checkout master 。
简短的回答：
cd ProjectFooBarCommoneSubmodule git checkout master <Do your editing> git commit --all -m "Lots of fixes" git push submodule_origin master cd .. git add ProjectFooBarCommoneSubmodule git commit -m "Bumped up the revision of ProjectFooBarCommoneSubmodule" git push origin master
更长的一个：
Git子模块是一个依赖机制，其中主项目（比如说A）在一个子项目中定义了一个指定的修订（比如说B），这个子项目将被用于构build项目A.为了使这个工具有用，这个行为必须是可预测的从A：的angular度来看。 除非有人决定把变更合并到项目A中，否则依赖关系是不能改变的。所有types的讨厌事情都可能发生，项目B的变化是自动导入的，其中编译错误可能是最好的，因为A会马上注意到失败。 这就是为什么B的头部保持分离状态。
B的状态存储在A中（检出git submodule status ），并且修改更改必须在A中完成并提交，才能起作用。 这是在上面的例子中发生的，A修改存储在回购站中的版本号，并将版本升级到最新版本。 这个过程将不得不在其他主要的回购中重复，所以没有自动的“使用主”开关AFAIK。
BTW。 有关子模块和子模块手册页的Git书籍章节包含大量关于子模块的有用信息，正常使用情况和典型缺陷也是如此。 值得检查。
编辑：我会尽力解释这个更好
我冒昧地在我的github帐户上创build示例项目。 提交是无意义的，包含垃圾，但设置应该没问题。 请检查出来。
ProjectFoo和ProjectBar都共享公共子模块中的代码。
ProjectFooBarCommoneSubmodule：master是6850e4e4c1fac49de398
在ProjectFoo中：
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0常见
在ProjectBar中：
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0常见
所以都指向相同的修订，对吧？ 这里的技巧是看到，ProjectFoo和ProjectBar指向修订 （6850e4e4c1fac49de39890703f21486ca04b87a0） 不是分支 （主），虽然他们是同样的事情。 第一个是分离的头，另一个是分支。
如果你想修复ProjectFooBarCommoneSubmodule，你可以在ProjectFoo的子目录中select分支，而不是修改 ：
git checkout master <Do your coding and pushing here>
然后去一个目录，并检查混帐子模块的状态。 它应该告诉你，你现在不同步。 例如
git submodule status
+ e24bd2bf45d52171a63b67ac05cd4be0ac965f60 common（heads / master-1-ge24bd2b）
现在你可以做一个git add，设置对这个特定的提交（ge24bd …）的引用，做一个提交，然后submodule引用指向这个版本，这也正好是ProjectFooBarCommoneSubmodule上的master。
现在您需要更新ProjectBar中的引用。 转到ProjectBar / common，并做git fetch来源（这是一个快速合并），做
git checkout master cd .. git add common git commit -m "Bumped up the revision" git push origin master # to publish the revision bump to everybody else
所以，和任何git仓库一样，你不需要在独立的头上工作。 你可以在master上工作，或者创build一个命名的分支。 无论哪种方式，请确保上游包含ProjectFooBarCommoneSubmodule更改，或者如果它们引用不存在的东西，则会同时中断ProjectFoo和ProjectBar。 希望这解释得更好
在submodule ： git push origin HEAD:master
如果你想一次提交并推送所有子模块，请执行以下操作： git submodule foreach 'git commit -a' ; git submodule foreach 'git push --all' ; git commit -a && \ git push --all --recurse-submodules=on-demand git submodule foreach 'git commit -a' ; git submodule foreach 'git push --all' ; git commit -a && \ git push --all --recurse-submodules=on-demand
要将分离的HEAD更改为master，请运行：
git rebase HEAD master
然后结帐主（使用-f强制）：
git checkout master
如果你有多个子模块来处理，请使用： git submodule foreach ，例如
git submodule foreach git pull origin master -r
我只是做：
git submodule foreach git push -u origin master
