次の意味がよくわかりません ( Git サブモジュールの更新ドキュメントから)。
--rebase... or--mergeが指定されていない限り、サブモジュールの HEAD をデタッチします...
--rebase/はどのように--merge変化しますか?
私の主な使用例は、サブモジュールを介して他のリポジトリに埋め込む、多数の中央リポジトリを持つことです。これらの中央リポジトリを、元の場所で直接、または埋め込みリポジトリ (サブモジュールを介して使用するリポジトリ) 内から改善できるようにしたいと考えています。
このGitProページは、gitサブモジュールの更新の結果をうまくまとめています
を実行する
git submodule updateと、プロジェクトの特定のバージョンがチェックアウトされますが、ブランチ内ではチェックアウトされません。これは、切り離されたヘッドを持つと呼ばれます — これは、HEAD ファイルがシンボリック参照ではなく、コミットを直接指していることを意味します。
問題は、変更が失われやすいため、通常、分離されたヘッド環境で作業したくないということです。
最初のサブモジュールの更新を行い、作業するブランチを作成せずにそのサブモジュール ディレクトリでコミットし、その間にコミットせずにスーパープロジェクトから git submodule update を再度実行すると、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 --remotevsgit pull」を参照してください。
MindToothの回答は、手動更新 (ローカル構成なし) を示しています。
git submodule -q foreach git pull -q origin master
どちらの場合も、サブモジュールの参照 ( gitlink、親リポジトリ index の特別なエントリ) が変更され、メイン リポジトリから参照を追加、コミット、およびプッシュする必要があります。
次回その親レポを複製すると、それらの新しい SHA1 参照を反映するようにサブモジュールが設定されます。
この回答の残りの部分では、従来のサブモジュール機能について詳しく説明します (サブモジュールの概念の背後にあるすべてのポイントである固定コミットへの参照)。
この問題を回避するには、サブモジュール ディレクトリで作業するときに git checkout -b work または同等のものを使用してブランチを作成します。サブモジュールの更新を 2 回行うと、作業は元に戻りますが、少なくとも戻るためのポインターがあります。
サブモジュールを含むブランチの切り替えも難しい場合があります。新しいブランチを作成し、そこにサブモジュールを追加してから、そのサブモジュールなしでブランチに戻った場合、サブモジュール ディレクトリは追跡されていないディレクトリとして残ります。
だから、あなたの質問に答えるために：
通常のリポジトリと同じようにブランチ/変更を作成し、プッシュ/プルを使用できますか、または注意すべき点はありますか?
ブランチを作成して変更をプッシュできます。
警告 ( Git Submodule Tutorialから): サブモジュールの変更を公開 (プッシュ) してから、それを参照するスーパープロジェクトに変更を公開 (プッシュ) してください。サブモジュールの変更を公開するのを忘れると、他の人はリポジトリを複製できなくなります。
サブモジュール参照コミットを、たとえば (タグ付き) 1.0 から 1.1 に進めるにはどうすればよいでしょうか (元のリポジトリの先頭が既に 2.0 であっても)
「 サブモジュールを理解する」ページが役立ちます
Git サブモジュールは、次の 2 つの可動部分を使用して実装されます。
.gitmodulesファイルと- 特別な種類のツリー オブジェクト。
これらは一緒に、プロジェクト内の特定の場所にチェックアウトされた特定のリポジトリの特定のリビジョンを三角測量します。
メイン プロジェクト内からサブモジュールの内容を変更することはできません。
100% 正解: サブモジュールを変更することはできません。そのコミットの 1 つだけを参照してください。
これが、メイン プロジェクト内からサブモジュールを変更するときに、次のことを行う理由です。
サブモジュールを使用すると、メイン プロジェクトが他のコンポーネントの特定のコミットのみを参照する、 コンポーネント ベースのアプローチ開発を行うことができます (ここでは、「サブモジュールとして宣言された他の Git リポジトリ」)。
サブモジュールは、メイン プロジェクトの開発サイクルに拘束されない別の Git リポジトリへのマーカー (コミット) です。サブモジュール (「他の」Git リポジトリ) は独立して進化できます。
必要なコミットを他のリポジトリから選択するのは、メイン プロジェクト次第です。
ただし、便宜上、これらのサブモジュールの 1 つをメイン プロジェクトから直接変更したい場合は、Git を使用してそれを行うことができます。ただし、最初にそれらのサブモジュールの変更を元の Git リポジトリに公開し、次にを参照してメイン プロジェクトをコミットする必要があります。上記のサブモジュールの新しいバージョン。
しかし、主なアイデアは残ります: 特定のコンポーネントを参照すること:
メイン プロジェクトで参照している特定のコミットのリストは、構成を定義します(これが構成管理のすべてであり、単なるバージョン管理システムを包括するものです) 。
メイン プロジェクトと同時にコンポーネントを実際に開発できる場合(メイン プロジェクトの変更にはサブディレクトリの変更が含まれ、その逆も同様であるため)、それは「サブモジュール」ではなく、「サブモジュール」になります。サブツリー マージ (これも質問「cvs から分散リポジトリへのレガシー コード ベースの転送」で提示) で、2 つの Git リポジトリの履歴をリンクします。
それは Git サブモジュールの本質を理解するのに役立ちますか?
各サブモジュールを更新するには、次のコマンドを (リポジトリのルートで) 呼び出すことができます。
git submodule -q foreach git pull -q origin master
-qオプションを削除して、プロセス全体に従うことができます。