このGitProページは、gitサブモジュール更新の結果をうまくまとめています
を実行するgit submodule updateと、プロジェクトの特定のバージョンがチェックアウトされますが、ブランチ内はチェックアウトされません。これは、ヘッドが分離されていると呼ばれます—これは、HEADファイルがシンボリック参照ではなく、コミットを直接指すことを意味します。
問題は、変更が失われやすいため、分離したヘッド環境で作業したくないということです。
最初のサブモジュールの更新を行い、作業するブランチを作成せずにそのサブモジュールディレクトリにコミットし、その後コミットせずにスーパープロジェクトからgit submodule updateを再度実行すると、Gitは通知せずに変更を上書きします。技術的には作業を失うことはありませんが、それを指すブランチはないため、取得するのはやや困難になります。
2013年3月の注：
「最新のgitサブモジュールの追跡」で説明したように、サブモジュール（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 --remotevsgit pull」を参照してください。
MindToothの回答は、手動更新（ローカル構成なし）を示しています。
git submodule -q foreach git pull -q origin master
どちらの場合も、サブモジュール参照（gitlink、親リポジトリインデックスの特別なエントリ）が変更され、メインリポジトリからの参照を追加、コミット、プッシュする必要があります。
次回、その親リポジトリのクローンを作成するときに、サブモジュールにデータが入力され、それらの新しいSHA1参照が反映されます。
この回答の残りの部分では、古典的なサブモジュール機能について説明します（サブモジュールの概念の背後にあるすべてのポイントである固定コミットへの参照）。
この問題を回避するには、git checkout -b workまたは同等のものを使用してサブモジュールディレクトリで作業するときにブランチを作成します。サブモジュールの更新を2回行っても、作業は元に戻りますが、少なくとも戻るためのポインターがあります。
サブモジュールを含むブランチを切り替えるのも難しい場合があります。新しいブランチを作成し、そこにサブモジュールを追加してから、そのサブモジュールのないブランチに切り替えても、サブモジュールディレクトリは追跡されていないディレクトリのままです。
だから、あなたの質問に答えるには：
通常のリポジトリの場合と同じように、ブランチ/モディフィケーションを作成してプッシュ/プルを使用できますか、または注意すべき点はありますか？
ブランチを作成して変更をプッシュできます。
警告（Gitサブモジュールチュートリアルから）：サブモジュールの変更を、それを参照するスーパープロジェクトに発行（プッシュ）する前に、必ず発行（プッシュ）してください。サブモジュールの変更を公開するのを忘れると、他の人はリポジトリを複製できなくなります。
サブモジュールを参照するコミットを言う（タグ付き）1.0から1.1にどのように進めますか（元のレポのヘッドはすでに2.0ですが）
「サブモジュールを理解する」ページが役立ちます
Gitサブモジュールは、2つの可動部分を使用して実装されます。
.gitmodulesファイルと- 特別な種類のツリーオブジェクト。
これらは一緒に、プロジェクトの特定の場所にチェックアウトされている特定のリポジトリの特定のリビジョンを三角測量します。
gitのサブモジュールのページ
メインプロジェクト内からサブモジュールの内容を変更することはできません
100％正解：サブモジュールを変更することはできません。そのコミットの1つのみを参照してください。
このため、メインプロジェクト内からサブモジュールを変更すると、次のようになります。
- サブモジュール内で（上流モジュールに）コミットしてプッシュする必要がある。
- 次に、メインプロジェクトに移動し、再コミットします（そのメインプロジェクトが、作成してプッシュした新しいサブモジュールコミットを参照するようにするため）。
サブモジュールを使用すると、コンポーネントベースのアプローチを開発できます。 メインプロジェクトは、他のコンポーネント（ここでは「サブモジュールとして宣言された他のGitリポジトリ」）の特定のコミットのみを参照します。
サブモジュールは、メインのプロジェクト開発サイクルに拘束されない別のGitリポジトリーへのマーカー（コミット）です。それは（「他の」Gitリポジトリ）独立して展開できます。
必要なコミットを他のリポジトリから選択するのはメインプロジェクトの責任です。
ただし、便宜上、これらのサブモジュールの1つをメインプロジェクトから直接変更する場合、Gitを使用すると、最初にそれらのサブモジュールの変更を元のGitリポジトリに公開し、次にメインプロジェクトを参照してコミットすることができます。新しい言ったサブモジュールのバージョン。
ただし、主な考え方は変わりません。次のような特定のコンポーネントを参照します。
- 独自のライフサイクルを持っている
- 独自のタグセットがある
- 独自の開発をしています
メインプロジェクトで参照している特定のコミットのリストは、構成を定義します（これは、構成管理のすべてのことであり、単なるバージョン管理システムを展開します）
コンポーネントがメインプロジェクトと同時に実際に開発される可能性がある場合（メインプロジェクトの変更にはサブディレクトリの変更が含まれるため、その逆も同様です）、コンポーネントは「サブモジュール」ではなくなりますが、サブツリーマージ（質問「レガシーコードベースをcvsから分散リポジトリに転送する」でも提示）、2つのGitリポジトリの履歴をリンクします。
Gitサブモジュールの本質を理解するのに役立ちますか？