[解決済み】Gitサブモジュールのアップデート

質問

以下の意味がよくわからないのですが( Git サブモジュールの更新 のドキュメントを参照してください)。

...サブモジュールの HEAD を切り離すようにします。 --rebase または --merge が指定されている場合...

どのように --rebase / --merge を変更しますか？

私の主なユースケースは、セントラルリポジトリの束を持ち、それをサブモジュールを介して他のリポジトリに埋め込むことです。私は、これらの中央リポジトリについて、元の場所で直接、または埋め込みリポジトリ（サブモジュールを介してそれらを使用するもの）の中から、改良できるようにしたいと思います。

• これらのサブモジュールから、通常のリポジトリと同じようにブランチや修正を作成し、push/pullを使用することができますか、それとも注意すべきことがありますか？
• サブモジュールの参照するコミットを (タグ付けされた) 1.0 から 1.1 に進めたり (元のリポジトリの先頭が既に 2.0 になっていても)、どのブランチのコミットを使用するかを選択したりするにはどうすればよいですか?

解決方法は？

これは GitProのページ は、git サブモジュールの更新の結果をうまくまとめています。

<ブロッククオート

を実行すると git submodule update ブランチ内ではなく、プロジェクトの特定のバージョンをチェックアウトします。これは detached head と呼ばれ、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 --remote 対 git pull "です。

マインドトゥース 's 答え は、手動更新（ローカル設定なし）を説明します。

git submodule -q foreach git pull -q origin master

どちらの場合も、それによってサブモジュールの参照先が変更されます ( ギットリンク , a 親リポのインデックスにある特別なエントリ ) を作成し、メインリポジトリから当該参照を追加、コミット、プッシュする必要があります。

次に親レポをクローンすると、新しい SHA1 参照を反映したサブモジュールが作成されます。

この回答の残りの部分では、古典的なサブモジュールの機能(参照先が 固定 コミット、これはサブモジュールの概念の背後にあるすべてのポイントです）。

---

<ブロッククオート

この問題を回避するには、サブモジュールのディレクトリで作業するときに git checkout -b work またはそれに相当する何かでブランチを作成します。サブモジュールの更新を二度目に行ったときに作業が元に戻ってしまいますが、少なくとも元に戻るためのポインタを持つことができます。

サブモジュールを含むブランチの切り替えも厄介なことがあります。新しいブランチを作成してそこにサブモジュールを追加し、そのサブモジュールのないブランチに戻した場合、サブモジュールのディレクトリが未追跡のディレクトリとして残ってしまいます。

---

では、質問にお答えします。

通常のレポと同じようにブランチや変更を作成し、push/pullを使用することができますか、それとも注意することがありますか？

ブランチを作成し、変更をプッシュすることができます。

警告 ( Git サブモジュールチュートリアル ): サブモジュールの変更は、それを参照するスーパープロジェクトに変更を公開 (プッシュ) する前に、必ず公開 (プッシュ) してください。サブモジュールの変更を公開し忘れると、他の人がそのリポジトリをクローンすることができなくなります。

サブモジュールの参照コミットを (タグ付けされた) 1.0 から 1.1 に進めるには (元のレポの先頭がすでに 2.0 になっていても) どうしたらよいでしょうか?

ページ " サブモジュールの理解 が参考になります。

Gitのサブモジュールは、2つの可動部分を使って実装されています。

• その .gitmodules ファイルと
• 特別な種類のツリーオブジェクトです。

これらは一緒に、プロジェクトの特定の場所にチェックアウトされた、特定のリポジトリの特定のリビジョンを三角測量します。

---

から git submodule ページ

メインプロジェクトの中からサブモジュールの内容を変更することはできません。

100%正しいです。サブモジュールを変更することはできませんが、そのコミットの一つを参照することだけはできます。

このため、メインプロジェクトの中からサブモジュールを修正する場合、以下のようになります。

• をコミットしてプッシュする必要があります。 内の サブモジュール(上流モジュール)と
• を作成し、メインプロジェクトで再コミットします (作成・プッシュした新しいサブモジュールのコミットをメインプロジェクトで参照できるようにするためです)。

サブモジュールを利用すると コンポーネントベースのアプローチ この場合、メインプロジェクトは他のコンポーネント (ここでは "other Git repositories declared as sub-modules") の特定のコミットのみを参照することになります。

サブモジュールは、メインプロジェクトの開発サイクルに縛られない、別の Git リポジトリへのマーカー（コミット）です：それ（" other" Git リポジトリ）は独立して進化することができます。

必要なコミットを他のレポから選ぶのは、メインプロジェクト次第です。

ただし、万が一。 便宜上 サブモジュールの1つをメインプロジェクトから直接変更する場合、Gitでは以下の条件を満たせば可能です。 まず サブモジュールの変更を元の Git リポジトリに公開し、さらに その後 を参照してメインプロジェクトをコミットします。 新しい のバージョンで、そのサブモジュールの

しかし、主要なアイデアは残っている：特定のコンポーネントを参照すること。

• 独自のライフサイクルを持つ
• 独自のタグを持つ
• 独自に開発する

メインプロジェクトで参照している特定のコミットのリストは、あなたの 構成 (これは 構成 経営とは、単なる囲い込みではない バージョン管理システム )

もし、本当に部品が開発されたら 同時に メインプロジェクトに変更を加えると、サブディレクトリにも変更が及ぶため）、それはもはやサブモジュールではなく、サブツリーマージになるでしょう（質問でも提示されているように、サブモジュールとサブディレクトリを統合する必要があります）。 レガシーコードベースをcvsから分散型リポジトリに移行する ) で、2つのGitレポの履歴を一緒にリンクさせます。

これで、Git Submodulesの本質を理解するのに役立ちそうですか？