Gitサブモジュールの更新
（ Gitサブモジュールの更新 のドキュメントから）次のような意味がはっきりしない。
...
--rebaseまたは--mergeが指定されていない限り、サブモジュールHEADは切り離されます。
--rebase/--mergeはどのように変化しますか？
私の主な使用例は、中央のリポジトリをたくさん持っていることです。それをサブモジュールを介して他のリポジトリに埋め込むつもりです。これらの中央リポジトリを、元の場所に直接配置するか、埋め込みリポジトリ（サブモジュールを介して使用するもの）内から改良したいと思います。
- これらのサブモジュールの中から、通常のリポジトリと同じようにブランチ/モディフィケーションを作成してPush/pullを使用することができますか、または注意することはありますか？
- サブモジュールで参照されているコミットをsay（タグ付き）1.0から1.1に進める（元のリポジトリの先頭が既に2.0になっている場合でも）、またはどのブランチのコミットが使用されているかを選択するにはどうすればよいでしょうか。
この GitProページ はgitサブモジュールの更新の結果をうまくまとめています
git submodule updateを実行すると、プロジェクトの特定のバージョンがチェックアウトされますが、ブランチ内はチェックアウトされません。これは、分離ヘッドを持つと呼ばれます。つまり、HEADファイルは、シンボリック参照ではなく、コミットを直接指します。
問題は、変更を失いやすいため、一般的に切り離されたヘッド環境で働きたくないということです。
最初のサブモジュールの更新を行い、動作するブランチを作成せずにそのサブモジュールディレクトリでコミットし、その間にコミットせずにスーパープロジェクトからgitサブモジュールの更新を再度実行すると、Gitは通知せずに変更を上書きします。技術的には、作業を失うことはありませんが、それを指すブランチがないため、取得するのは多少困難です。
注2013年3月：
「 git submodule tracking latest 」で述べたように、サブモジュール（git1.8.2）はブランチを追跡できるようになりました。
# add submodule to track master branch
git submodule add -b master [URL to Git repo];
# update your submodule
git submodule update --remote
# or (with rebase)
git submodule update --rebase --remote
「 git submodule update --remote VS git pull 」を参照してください。
MindTooth の answer は、手動更新を示しています（ローカル設定なし）：
git submodule -q foreach git pull -q Origin master
どちらの場合も、サブモジュールの参照（gitlink、 親リポジトリの特別なエントリindex ）、そして、あなたはメインリポジトリからの参照を追加、コミット、プッシュする必要があります。
次回、その親リポジトリのクローンを作成するときに、サブモジュールにこれらの新しいSHA1参照を反映するように設定します。
この回答の残りの部分では、古典的なサブモジュール機能（fixedコミットへの参照。これはサブモジュールの概念の背後にあるすべてのポイントです）。
この問題を回避するには、git checkout -b workまたは同等のものを使用してサブモジュールディレクトリで作業するときにブランチを作成します。サブモジュールの更新を2回実行しても、作業は元に戻りますが、少なくともポインタを戻すことができます。
サブモジュールが含まれるブランチの切り替えも難しい場合があります。新しいブランチを作成し、そこにサブモジュールを追加し、そのサブモジュールなしでブランチに切り替えた場合、サブモジュールディレクトリは追跡されていないディレクトリのままです。
したがって、あなたの質問に答えるには：
通常のレポジトリと同じようにブランチ/変更を作成し、プッシュ/プルを使用できますか、または注意すべきことがありますか？
ブランチを作成し、変更をプッシュできます。
警告（from Git Submodule Tutorial ）：サブモジュールの変更を参照するスーパープロジェクトに公開（プッシュ）する前に、サブモジュールの変更を常に公開（プッシュ）します。サブモジュールの変更の公開を忘れると、他の人はリポジトリを複製できなくなります。
サブモジュールを参照するコミットを、たとえば（タグ付き）1.0から1.1にどのように進めますか（元のレポのヘッドが既に2.0であっても）
「 nderstanding Submodules 」ページが役立ちます
Gitサブモジュールは、2つの可動部分を使用して実装されます。
.gitmodulesファイルと- 特別な種類のツリーオブジェクト。
これらは一緒になって、プロジェクト内の特定の場所にチェックアウトされる特定のリポジトリの特定のリビジョンを三角測量します。
メインプロジェクト内からサブモジュールの内容を変更することはできません
100％正しい：サブモジュールは変更できず、そのコミットの1つのみを参照します。
これが、メインプロジェクト内からサブモジュールを変更する場合、次の理由によります。
- サブモジュールを（上流モジュールに）コミットしてプッシュ内にする必要があります。
- 次に、メインプロジェクトに移動して再コミットします（そのメインプロジェクトが、作成してプッシュしたばかりの新しいサブモジュールコミットを参照するため）
サブモジュールを使用すると、コンポーネントベースのアプローチ開発を行うことができます。ここで、メインプロジェクトは他のコンポーネントの特定のコミットのみを参照します。 （ここでは、「サブモジュールとして宣言されている他のGitリポジトリ」）。
サブモジュールは、メインプロジェクト開発サイクルに拘束されない別のGitリポジトリへのマーカー（コミット）です。サブモジュール（「他の」Gitリポジトリ）は独立して進化できます。
他のリポジトリから必要なコミットを選択するのは、メインプロジェクト次第です。
ただし、必要に応じて、（=-// ==）利便性から、これらのサブモジュールのいずれかをメインGitでは、first元のGitリポジトリにこれらのサブモジュールの変更を公開し、thenコミットすると上記のサブモジュールのnewバージョンを参照するメインプロジェクト。
しかし、主なアイデアは残ります：特定のコンポーネントを参照する：
- 独自のライフサイクルを持っている
- 独自のタグのセットを持っている
- 独自の開発がある
メインプロジェクトで参照している特定のコミットのリストは、configurationを定義します（これが何Configuration管理はすべてであり、単なるエングロビング バージョン管理システム ）
コンポーネントを実際にメインプロジェクトと同時に開発することができる場合（メインプロジェクトの変更にはサブディレクトリの変更が含まれ、その逆もあるため）それはもはや「サブモジュール」ではなく、サブツリーのマージ（質問 cvsから分散リポジトリへのレガシーコードベースの転送 ）であり、2つのGitリポジトリの履歴をリンクします。
Gitサブモジュールの本質を理解するのに役立ちますか？
各サブモジュールを更新するには、（リポジトリのルートで）次のコマンドを呼び出すことができます。
git submodule -q foreach git pull -q Origin master
プロセス全体を追跡するには、- qオプションを削除します。
--rebase vs. --mergeオプションに対処するには：
スーパーリポジトリAとサブモジュールBがあり、サブモジュールBでいくつかの作業を行いたいとしましょう。
git submodule update
あなたはHEADのない状態にあるので、この時点であなたがするどんなコミットも戻るのは難しいです。サブモジュールBの新しいブランチで作業を始めました。
cd B
git checkout -b bestIdeaForBEver
<do work>
その間、プロジェクトAの他の誰かがBの最新かつ最高のバージョンが本当にAに値するものであると決めました。あなたは、慣れないうちに、最新の変更をマージしてサブモジュールを更新します。
<in A>
git merge develop
git submodule update
ああ、いやー！おそらく、BがBの新しいチップに関連付けられたSHAを指しているか、その他のコミットが行われていることが原因です。あなただけが持っていたならば：
git merge develop
git submodule update --rebase
Fast-forwarded bestIdeaForBEver to b798edfdsf1191f8b140ea325685c4da19a9d437.
Submodule path 'B': rebased into 'b798ecsdf71191f8b140ea325685c4da19a9d437'
今やBのためのこれまでの最高のアイデアは新しいコミットにリベースされました、そしてさらに重要なことに、あなたはまだヘッドレス状態ではなく、Bのためのあなたの開発ブランチにいます！
（--mergeは、変更をafterUpdateSHAにリベースするのではなく、beforeUpdateSHAからafterUpdateSHAへの変更を作業ブランチにマージします。）
Git 1.8.2には新しいオプション--remoteが追加され、まさにこの振る舞いを可能にします。ランニング
git submodule update --rebase --remote
各サブモジュールのアップストリームから最新の変更を取得し、それらをリベースし、サブモジュールの最新のリビジョンをチェックアウトします。ように ドキュメント はそれを置く：
- リモート
このオプションはupdateコマンドに対してのみ有効です。スーパープロジェクトの記録済みSHA-1を使用してサブモジュールを更新する代わりに、サブモジュールのリモートトラッキングブランチのステータスを使用してください。
これは各サブモジュールでgit pullを実行するのと同等です。
（これは この回答 からコピーされたものです。）