Git提交到公共子模块（master分支） [英] Git commit to common submodule (master branch)
问题描述
我有两个或两个以上的项目（我们称之为 ProjectFoo 和 ProjectBar ），其中包含通用代码 > submodule 。
我的理解是，如果我从 ProjectFoo 中对子模块进行更改，它将处于分离只有所有的 ProjectFoo 克隆都可以看到：
（master）$ cd ProjectFooBarCommoneSubmodule /
（主）$ git commit -am通用代码修复。
（56f21fb0 ...）$ git push
所有最新的
<这可能是因为 master 分支没有改变。我大概可以做一些像 git checkout master&& git合并一切最新但这看起来很丑陋。可能是 git reset --hard master 会做同样的事情，但它似乎更丑陋。
如何拥有一个由项目共享的通用代码，从 内更新的项目使用它？换句话说，对该子模块的提交应该更新使用同一个子模块的所有不同的存储库（存储库，而不仅仅是克隆）。
- - 编辑----
显然，我的签出存储库被搞砸了。它应该从一开始就这样工作（在这个例子中，在 ProjectFoo 上）：
（ master）$ cd ProjectFooBarCommoneSubmodule /
（master）$ git commit -am常见代码修复。
（master）$ git push
....
fbfdd71..0acce63 master - > master
（master）$ cd ..
（master）$ git add ProjectFooBarCommoneSubmodule
（master）$ git commit -mSubmodule update。
然后从其他项目中获取该更改，例如 ProjectBar ：
（master）$ cd ProjectFooBarCommoneSubmodule /
（master）$ git pull
会更新到最新的通用代码。如果它位于分离的头部，则可能需要 git checkout master
<简单回答：
pre $ cd $ Project $ $ $ $ $ git checkout master
<做你的编辑>
git commit --all -m很多修正
git push submodule_origin master
cd ..
git add ProjectFooBarCommoneSubmodule
git commit -m 调整了ProjectFooBarCommoneSubmodule的版本
git push origin master
更长的一个：
Git子模块是一个依赖机制，其中主项目（比如说A）在子项目中定义了指定的修订（比如说B），这将用于构建项目A.为了让工具有用，行为必须从A：的角度来预测。除非有人决定将变更合并到项目A，否则依赖关系不会改变。所有类型的讨厌事情都可能发生，包括项目B：自动导入的更改，其中编译错误可能是最好的，因为A会马上注意到失败。这就是为什么B的头部保持分离状态的原因。
B的状态存储在A中（检出 git子模块状态），并且修改更改必须在A中完成并承诺，以使其发挥作用。这就是上面的例子中发生的情况，A更改存储在回购站中的版本号，并将版本升级到最新版本。这个过程将不得不在其他主要的回购中重复，所以没有自动的使用主开关AFAIK。
顺便说一句。有关子模块的 Git书籍章节和子模块手册页包含大量关于子模块的有用信息，正常使用和典型缺陷也是如此。值得检查。
编辑：我会尽力解释这一点
我冒昧地在我的github帐户上创建示例项目。提交是无意义的，包含垃圾，但设置应该没问题。请检查一下。
ProjectFoo和ProjectBar都共享公共子模块中的代码。
ProjectFooBarCommoneSubmodule：master是 6850e4e4c1fac49de398
在ProjectFoo中：
git子模块状态
-6850e4e4c1fac49de39890703f21486ca04b87a0 common
在ProjectBar中：
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0 common
相同的修订，对吗？这里的技巧是看看ProjectFoo和ProjectBar指向修订（6850e4e4c1fac49de39890703f21486ca04b87a0）不是分支（主），尽管它们是相同的。第一个是分离的头，另一个是已命名的分支。
如果您想修复ProjectFooBarCommoneSubmodule，您可以转到例如ProjectFoo和选择分支而不是修订：
git checkout master
< ;做你的编码并推向这里>
然后转到一个目录，并检查git子模块状态。它应该告诉你，你现在不同步。例如
git子模块状态
+ e24bd2bf45d52171a63b67ac05cd4be0ac965f60 common（heads / master-1-ge24bd2b）
现在你可以做一个git add来设置对这个特定提交的引用（ge24bd ...），执行提交，之后子模块引用指向此修订，这也正好是ProjectFooBarCommoneSubmodule上的主模块。
现在您还需要更新ProjectBar中的引用。转到ProjectBar / common，并执行git fetch origin（这是一个快速转发合并），执行
git checkout master
cd ..
git add common
git commit -m提高版本
git push origin master＃向其他人发布修订版块b $ b 因此，与任何git存储库一样，您不需要在独立的头上工作。你可以在master上工作，或者创建一个命名分支。无论哪种方式，请确保上游包含ProjectFooBarCommoneSubmodule更改，或者如果它们引用了不存在的内容，则会同时中断ProjectFoo和ProjectBar。希望这解释得更好
I've two or more projects (let's call them ProjectFoo and ProjectBar) having some common code that I put in a submodule.
My understanding is that if I commit changes to a submodule from within ProjectFoo it'll be in a detached head that only all ProjectFoo clones can see:
(master) $ cd ProjectFooBarCommoneSubmodule/
(master) $ git commit -am "Common code fix."
(56f21fb0...) $ git push
Everything up-to-date
That's probably because the master branch hasn't changed. I could probably do something like git checkout master && git merge Everything up-to-date but that seem pretty ugly. May be a git reset --hard master would do the same but it seems even uglier.
How to have a common code shared by project, updated from within those projects using it? In other words, committing to that submodule should update all various repositories (repositories, not just clones) that use this same submodule.
---- EDIT ----
Visibly my checked-out repository was messed up and broken. It should have worked right from the start like that (on ProjectFoo in this example):
(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."
Then to get that change from on other projects, like ProjectBar:
(master) $ cd ProjectFooBarCommoneSubmodule/
(master) $ git pull
Would update to the latest common code. A git checkout master may be required if it's on a detached head.
Short answer:
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
The longer one:
Git submodules are a dependency mechanism, where the main project (say A) defines a specified revision in a subproject (say B), which will be used in building project A. In order for the tool to be useful the behavior has to be predictable from A:s point of view. Dependencies cannot change, unless somebody decides to incorporate the change to project A. All kinds of nasty things could happen, were project B:s changes automatically imported, of which compile errors are probably the best ones, as A would notice the failures immediately. This is why B:s head is kept in detached state.
The state of B is store in A (check out git submodule status), and a revision change has to be done and committed in A, in order for it to have any effect. This is what happens in the example above, A changes the revision number stored in the repo, and bumps up the version to the latest one. The process will have to be repeated in the other main repo as well, so no automatic "use master" switch AFAIK.
BTW. The Git book chapter on submodules and the submodule man page contain lots of useful info about submodules, as normal usage and typical pitfalls as well. Worth checking out.
EDIT: I'll try to explain this better
I took the liberty to create example projects on my github account. The commits are meaningless and contain junk, but the setup should be fine. Please check it out to follow.
Both ProjectFoo and ProjectBar share the code in the common submodule.
ProjectFooBarCommoneSubmodule:master is 6850e4e4c1fac49de398
In ProjectFoo:
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0 common
In ProjectBar:
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0 common
So both point to the same revision, right? The trick here is to see, that ProjectFoo and ProjectBar point to the revision (6850e4e4c1fac49de39890703f21486ca04b87a0) not the branch (master), although they are the same thing. The first one is a detached head, and the other a named branch.
If you want to do some fixing on ProjectFooBarCommoneSubmodule, you can go to the subdir in e.g. ProjectFoo, and choose the branch instead of the revision:
git checkout master
<Do your coding and pushing here>
Then go one directory up, and check git submodule status. It should tell you, that you are now out of sync. E.g
git submodule status
+e24bd2bf45d52171a63b67ac05cd4be0ac965f60 common (heads/master-1-ge24bd2b)
Now you can do a git add, to set the reference to this particular commit(ge24bd...), do a commit, and after this the submodule reference points to this revision, which also happens to be master on ProjectFooBarCommoneSubmodule.
Now you need to update the reference in ProjectBar as well. Go to ProjectBar/common, and do git fetch origin (this is a fast forward merge), 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
So, as with any git repository, you don't need to work on a detached head. You can either work on master, or create a named branch. Either way, make sure that upstream contains the ProjectFooBarCommoneSubmodule changes, or you will break both ProjectFoo and ProjectBar, if they reference something that doesn't exist. Hope this explained it better
这篇关于Git提交到公共子模块（master分支）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
