Git提交公共子模块(master branch)

Question

我有两个或更多的项目(我们称之为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如果它在一个独立的头上,可能需要A.

Answer 1

简短回答:

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),它将用于构建项目A.为了使工具有用,行为必须是可预测的从A:s的角度来看.依赖关系不能改变,除非有人决定将更改合并到项目A中.所有类型的讨厌的事情都可能发生,项目B:自动导入的更改,其中编译错误可能是最好的,因为A会立即注意到失败.这就是B:头部处于分离状态的原因.

B的状态存储在A(检出git submodule status)中,并且必须在A中进行修订更改并使其生效,以使其具有任何效果.这是上面示例中发生的情况,A更改存储在repo中的修订号,并将版本更新为最新版本.该过程也必须在另一个主回购中重复,因此没有自动"使用主"切换AFAIK.

BTW.关于子模块和子模块手册页的Git书章节包含许多关于子模块的有用信息,作为正常使用和典型的陷阱.值得一试.

编辑:我会尝试更好地解释这一点

我冒昧地在我的github帐户上创建示例项目.提交没有意义,包含垃圾,但设置应该没问题.请检查出来.

ProjectFoo和ProjectBar共享公共子模块中的代码.

ProjectFooBarCommoneSubmodule:master是6850e4e4c1fac49de398

在ProjectFoo中:

git submodule status

-6850e4e4c1fac49de39890703f21486ca04b87a0常见

在ProjectBar中:

git submodule status

-6850e4e4c1fac49de39890703f21486ca04b87a0常见

所以两者都指向相同的版本,对吧？这里的诀窍是看,ProjectFoo和ProjectBar指向修订版(6850e4e4c1fac49de39890703f21486ca04b87a0)而不是分支(master),尽管它们是相同的.第一个是分离头,另一个是命名分支.

如果你想在ProjectFooBarCommoneSubmodule上做一些修复,你可以转到例如ProjectFoo的子目录,然后选择分支而不是修订:

git checkout master 
<Do your coding and pushing here>

然后进入一个目录,并检查git子模块状态.它应该告诉你,你现在已经不同步了.例如

git submodule status

+ e24bd2bf45d52171a63b67ac05cd4be0ac965f60 common(heads/master-1-ge24bd2b)

现在你可以做一个git add,设置对这个特定提交的引用(ge24bd ...),做一个提交,然后子模块引用指向这个版本,它也恰好是ProjectFooBarCommoneSubmodule上的master.

现在您还需要更新ProjectBar中的引用.转到ProjectBar/common,并执行git fetch origin(这是一个快进合并),do

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,也可以创建命名分支.无论哪种方式,确保上游包含ProjectFooBarCommoneSubmodule更改,或者如果它们引用了不存在的内容,您将破坏ProjectFoo和ProjectBar.希望这能更好地解释它