SYNOPSIS
git submodule [--quiet] [--cached] git submodule [--quiet] add [<options>] [--] <repository> [<path>] git submodule [--quiet] status [--cached] [--recursive] [--] [<path>…] git submodule [--quiet] init [--] [<path>…] git submodule [--quiet] deinit [-f|--force] (--all|[--] <path>…) git submodule [--quiet] update [<options>] [--] [<path>…] git submodule [--quiet] set-branch [<options>] [--] <path> git submodule [--quiet] set-url [--] <path> <newurl> git submodule [--quiet] summary [<options>] [--] [<path>…] git submodule [--quiet] foreach [--recursive] <command> git submodule [--quiet] sync [--recursive] [--] [<path>…] git submodule [--quiet] absorbgitdirs [--] [<path>…]
DESCRIPTION
サブモジュールを検査、更新、管理します。
サブモジュールの詳細については、 gitsubmodules(7) を参照してください。
COMMANDS
引数なしで、既存のサブモジュールのステータスを示します。 サブモジュールで操作を実行するために、いくつかのサブコマンドを使用できます。
- add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]
-
現在のプロジェクトの次にコミットされるチェンジセットへの指定のパスで、指定のポジトリをサブモジュールとして追加します。現在のプロジェクトは「スーパープロジェクト」と呼ばれます。
<repository> は、新しいサブモジュールの元リポジトリのURLです。これは、絶対URLまたは、(
./または../で始まる場合、)スーパープロジェクトのデフォルトのリモートリポジトリに相対的な場所のいずれかです(スーパープロジェクトbar.gitのすぐ隣にあるリポジトリfoo.gitを指定するには、./foo.gitの代わりに../foo.gitを使用する必要があることに注意してください — 相対 URL の規則に従っていれば、期待通りになるでしょう — Git における相対 URL の評価は相対ディレクトリの場合と同じだからです)。デフォルトのリモートは、現在のブランチのリモート追跡ブランチのリモートです。そのようなリモート追跡ブランチが存在しないか、または、HEADが切り離されている場合、「origin」がデフォルトのリモートであると見なされます。 スーパープロジェクトにデフォルトのリモートが構成されていない場合、スーパープロジェクトはそれ自身に権限のあるアップストリームであり、代わりに現在の作業ディレクトリが使用されます。
オプションの引数 <path> は、複製されたサブモジュールがスーパープロジェクト内で存在するための相対的な場所です。 <path> が指定されていない場合、ソースリポジトリの正規部分(canonical part)が使用されます(
/path/to/repo.gitの場合は「repo」、host.xz:foo/.gitの場合は「foo」)。 <path> が存在し、すでに有効なGitリポジトリである場合、クローンを作成せずにコミット用にステージングされます。 <path> は、--nameを使用して論理名を指定しない限り、構成エントリでサブモジュールの論理名としても使用されます。指定のURLは、スーパープロジェクトのクローンを作成する後続のユーザーが使用できるように
.gitmodulesに記録されます。 URLがスーパープロジェクトのリポジトリに関連して指定されている場合、スーパープロジェクトとサブモジュールのリポジトリは同じ相対位置にまとめられ、スーパープロジェクトのURLのみを指定する必要があると想定します。 git-submoduleは、.gitmodulesの相対URLを使用してサブモジュールを正しく検索します。 - status [--cached] [--recursive] [--] [<path>…]
-
サブモジュールの状態を表示します。これにより、各サブモジュールの現在チェックアウトされているコミットの SHA-1 が、サブモジュールのパスと SHA-1 の
git describeの出力と共に出力されます。各 SHA-1 には、サブモジュールが初期化されていない場合は-、現在チェックアウトされているサブモジュールコミットが、含まれているリポジトリのインデックスにある SHA-1 と一致しない場合は+、サブモジュールにマージ競合がある場合はU、 という接頭辞が付く可能性があります。--cachedが指定されている場合、このコマンドは代わりに、各サブモジュールのスーパープロジェクトに記録されたSHA-1を出力します。--recursiveが指定されている場合、このコマンドはネストされたサブモジュールに再帰し、それらのステータスも表示します。あなたがインデックスまたはHEADに記録されたコミットに関して、現在初期化されているサブモジュールの変更のみに関心がある場合は、 git-status(1) および git-diff(1) もその情報を提供します(サブモジュールの作業ツリーへの変更も報告します)。
- init [--] [<path>…]
-
インデックスに記録されたサブモジュール(他の場所で追加およびコミットされたサブモジュール)を初期化するには、
.git/configにsubmodule.$name.urlを設定します。テンプレートとして.gitmodulesと同じ設定を使用します。URLが相対的な場合は、デフォルトのリモートを使用して解決されます。デフォルトのリモートがない場合、現在のリポジトリはアップストリームであると見なされます。オプションの <path> 引数は、初期化されるサブモジュールを制限します。パスが指定されておらず、 submodule.active が構成されている場合、アクティブになるように構成されたサブモジュールが初期化されます。そうでない場合、すべてのサブモジュールが初期化されます。
存在する場合は、
submodule.$name.updateの値もコピーします。このコマンドは、.git/configの既存の情報を変更しません。あなたは次に、ローカル設定用に.git/configのサブモジュールクローンURLをカスタマイズして、git submodule updateに進むことができます。サブモジュールの場所をカスタマイズする予定がない場合は、明示的な「init」ステップなしでgit submodule update --initを使用することもできます。デフォルトのリモートの定義については、add サブコマンドを参照してください。
- deinit [-f|--force] (--all|[--] <path>…)
-
指定のサブモジュールの登録を解除します。つまり、
.git/configからsubmodule.$nameセクション全体をその作業ツリーとともに削除します。さらにgit submodule updateとgit submodule foreachとgit submodule syncを呼び出すと、 未登録のサブモジュールが再び初期化されるまでスキップされるので、作業ツリーにあるサブモジュールのローカルチェックアウトをもうこれ以上やりたくない場合は、このコマンドを使用してください。コマンドをpathspecなしで実行すると、間違いを防ぐために、すべてを無効にするのではなく、エラーが発生します。
--forceが指定されている場合、サブモジュールの作業ツリーは、ローカルの変更が含まれていても削除されます。あなたが本当にリポジトリからサブモジュールを削除してコミットしたい場合は、代わりに git-rm(1) を使用してください。削除オプションについては、 gitsubmodules(7) を参照してください。
- update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--[no-]single-branch] [--filter <filter spec>] [--] [<path>…]
-
登録されたサブモジュールを更新して、欠落しているサブモジュールのクローンを作成し、サブモジュールで欠落しているコミットをフェッチし、サブモジュールの作業ツリーを更新して、スーパープロジェクトが期待するものと一致させます。「更新」は、コマンドラインオプションと
submodule.<name>.update構成変数の値に応じていくつかの方法で実行できます。 コマンドラインオプションは、構成変数よりも優先されます。 どちらも指定されていない場合、「checkout」が実行されます。 コマンドラインとsubmodule.<name>.update構成の両方でサポートされる「update」手順は以下のとおりです:- checkout
-
スーパープロジェクトに記録されたコミットは、 切り離された HEAD (detached HEAD)上のサブモジュールでチェックアウトされます。
+
--forceが指定された場合、サブモジュールは(git checkout --forceを使って)チェックアウトされます。たとえ含んでいるリポジトリのインデックスで指定されたコミットが、すでにサブモジュールでチェックアウトしたコミットに一致していてもです。- rebase
-
サブモジュールの現在のブランチは、 スーパープロジェクトに記録されたコミットに基づいてリベースされます。
- merge
-
スーパープロジェクトに記録されたコミットは、 サブモジュールの現在のブランチにマージされます。
以下の「update」手順は、
submodule.<name>.update構成変数を介してのみ使用できます:- custom command
-
単一の引数 (スーパープロジェクトに記録されたコミットのsha1)をとる 任意のシェルコマンドが実行されます。
submodule.<name>.updateが!commandに設定されている場合、 感嘆符(!)の後の残りはカスタムコマンドです。 - none
-
サブモジュールは更新されません。
サブモジュールがまだ初期化されておらず、
.gitmodulesに格納されている設定を使用するだけの場合、 あなたは--initオプションを使用してサブモジュールを自動的に初期化できます。--recursiveが指定されている場合、このコマンドは登録されたサブモジュールに再帰し、その中でネストされたサブモジュールを更新します。--filter <filter spec>が指定されている場合、 指定の部分(partial)クローン・フィルタがサブモジュールに適用されます。 フィルター仕様の詳細については、 git-rev-list(1) を参照してください。 - set-branch (-b|--branch) <branch> [--] <path>
- set-branch (-d|--default) [--] <path>
-
サブモジュールのデフォルトのリモート追跡ブランチを設定します。
--branchオプションを使用すると、リモートブランチを指定できます。--defaultオプションを使用すると、 submodule.<name>.branch 構成キーを削除し、これにより、追跡ブランチはデフォルトでリモートの「HEAD」になります。 - set-url [--] <path> <newurl>
-
指定されたサブモジュールのURLを <newurl> に設定します。そしてその次に、サブモジュールの新しいリモートURL構成を自動的に同期します。
- summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>…]
-
指定のコミット(デフォルトはHEAD)と 作業ツリー/インデックス の間のコミットの概要を表示します。問い合わせがサブモジュールの場合、指定のスーパープロジェクトコミットと、インデックスまたは作業ツリー(
--cachedによって切り替えられる)の間のサブモジュール内の一連のコミットが表示されます。オプション--filesが指定されている場合は、スーパープロジェクトのインデックスとサブモジュールの作業ツリーの間の、サブモジュールでの一連のコミットを表示します(このオプションでは、--cachedオプションを使用したり、明示的なコミットを提供したりすることはできません)。git-diff(1) で
--submodule=logオプションを使用すると、その情報も提供されます。 - foreach [--recursive] <command>
-
チェックアウトされた各サブモジュールで任意のシェルコマンドを評価します。このコマンドは、変数 $name と $sm_path と $displaypath と $sha1 と$toplevel にアクセスできます。$name は、
.gitmodulesの関連するサブモジュールセクションの名前で、 $sm_path は、直接のスーパープロジェクト(immediate superproject)に記録されているサブモジュールのパスで、 $displaypath には、現在の作業ディレクトリからサブモジュールのルートディレクトリへの相対パスが含まれ、 $sha1 は、直接のスーパープロジェクト(immediate superproject)に記録されているコミットで、 $toplevel は、直接のスーパープロジェクト(immediate superproject)のトップレベルへの絶対パスです。Windowsでの$PATHとの競合を避けるために、$path変数は$sm_path変数の非推奨の同義語になっていることに注意してください。スーパープロジェクトで定義されているがチェックアウトされていないサブモジュールは、このコマンドでは無視されます。--quietが指定されていない限り、foreachはコマンドを評価する前に各サブモジュールの名前を出力します。--recursiveが指定されている場合、サブモジュールは再帰的にトラバースされます(つまり、指定のシェルコマンドはネストされたサブモジュールでも評価されます)。 サブモジュールのコマンドからゼロ以外の値が返されると、処理が終了(terminate)します。これは、コマンドの最後に|| :を追加することでオーバーライドできます。例として、以下のコマンドは、各サブモジュールのパスと現在チェックアウトされているコミットを表示します:
git submodule foreach 'echo $sm_path `git rev-parse HEAD`' - sync [--recursive] [--] [<path>…]
-
サブモジュールのリモートURL構成設定を
.gitmodulesで指定された値に同期します。 これは、.git/configにすでにURLエントリがあるサブモジュールにのみ影響します(これは、初期化されたとき、または新しく追加されたときの場合です)。これは、サブモジュールのURLがアップストリームで変更され、それに応じてローカルリポジトリを更新する必要がある場合に役立ちます。git submodule syncはすべてのサブモジュールを同期しますが、git submodule sync -- Aはサブモジュール "A" のみを同期します。--recursiveが指定されている場合、このコマンドは登録されたサブモジュールに再帰し、その中でネストされたサブモジュールを同期します。 - absorbgitdirs
-
サブモジュールのgitディレクトリがサブモジュール内にある場合、サブモジュールのgitディレクトリをそのスーパープロジェクトの
$GIT_DIR/modulesパスに移動し、次に、core.worktreeを設定して、gitディレクトリとその作業ディレクトリを接続し、そして、スーパープロジェクトのgitディレクトリに埋め込んだサブモジュールのgitディレクトリを指す .git ファイルを追加します。独立して複製され、後でサブモジュールまたは古いセットアップとして追加されたリポジトリでは、スーパープロジェクトのgitディレクトリに埋め込まれるのではなく、サブモジュール内にサブモジュールのgitディレクトリがあります。
このコマンドはデフォルトで再帰的に実行されます。
OPTIONS
-
-q -
--quiet -
エラーメッセージのみを出力します。
-
--progress -
このオプションは、addおよびupdateコマンドにのみ有効です。
-qが指定されていない限り、進行状況は、端末に接続されている場合、デフォルトで標準エラーストリームに報告されます。このフラグは、標準エラーストリームが端末に送信されていない場合でも、進行状況を強制します。 -
--all -
このオプションは、deinitコマンドに対してのみ有効です。 作業ツリーのすべてのサブモジュールの登録を解除します。
-
-b <branch> -
--branch <branch> -
サブモジュールとして追加するリポジトリのブランチ。ブランチの名前は、
update --remoteの.gitmodulesにsubmodule.<name>.branchとして記録されます。 特別な値.は、サブモジュール内のブランチの名前が現在のリポジトリ内の現在のブランチと同じ名前でなければならないことを示すために使用されます。オプションが指定されていない場合、デフォルトでリモートの「HEAD」になります。 -
-f -
--force -
このオプションは、addとdeinitとupdateコマンドにのみ有効です。addを実行するときは、無視されるサブモジュールパスの追加を許可します。 deinitを実行するときは、ローカルの変更が含まれている場合でも、サブモジュールの作業ツリーが削除されます。 updateを実行するときは(checkout手順でのみ有効)、別のコミットに切り替えるときにサブモジュールのローカル変更を破棄し、そして、含まれているリポジトリのインデックスにリストされているコミットがサブモジュールでチェックアウトされたコミットと一致する場合でも、常にサブモジュールでチェックアウト操作を実行します。
-
--cached -
このオプションは、statusコマンドとsummaryコマンドにのみ有効です。これらのコマンドは通常、サブモジュールHEADにあるコミットを使用しますが、このオプションを使用すると、代わりにインデックスに格納されているコミットが使用されます。
-
--files -
このオプションは、summaryコマンドにのみ有効です。 このコマンドを使用すると、インデックス内のコミットと、サブモジュールHEAD内のコミットが比較されます。
-
-n -
--summary-limit -
このオプションは、summaryコマンドにのみ有効です。 サマリーサイズ(合計で表示されるコミットの数)を制限します。 0を指定すると、要約が無効になります。 負の数は無制限(デフォルト)を意味します。この制限は、変更されたサブモジュールにのみ適用されます。 追加/削除/タイプ変更された サブモジュールのサイズは常に1に制限されます。
-
--remote -
このオプションは、updateコマンドに対してのみ有効です。 スーパープロジェクトの記録されたSHA-1を使用してサブモジュールを更新する代わりに、サブモジュールのリモート追跡ブランチのステータスを使用します。 使用されるリモートはブランチのリモート(
branch.<name>.remote)で、デフォルトはoriginです。 使用されるリモートブランチのデフォルトはリモートのHEADですが、ブランチ名は、.git / configまたは.gitmodulesのいずれかでsubmodule.<name>.branchオプションを設定することでオーバーライドできます(.git / configが優先されます)。これは、サポートされている更新手順(
--checkout、--rebaseなど)のいずれでも機能します。唯一の変更は、ターゲットSHA-1のソースです。 たとえば、submodule update --remote --mergeはアップストリームのサブモジュールの変更をサブモジュールにマージし、submodule update --mergeはスーパープロジェクトのgitlinkの変更をサブモジュールにマージします。現在の追跡ブランチの状態を確認するために、
update --remoteはSHA-1を計算する前にサブモジュールのリモートリポジトリをフェッチします。フェッチしたくない場合は、submodule update --remote --no-fetchを使用する必要があります。このオプションを使用して、アップストリームサブプロジェクトからの変更をサブモジュールの現在のHEADと統合します。または、サブモジュールから
git pullを実行することもできます。これは、リモートブランチ名を除いて同等です。update --remoteはデフォルトのアップストリームリポジトリとsubmodule.<name>.branchを使用し、git pullはサブモジュールのbranch.<name>.mergeを使用します。スーパープロジェクトでデフォルトのアップストリームブランチを配布する場合はsubmodule.<name>.branchを、サブモジュール自体で作業しているときによりネイティブな感じが必要な場合はbranch.<name>.mergeを使用してください。 -
-N -
--no-fetch -
このオプションは、updateコマンドに対してのみ有効です。リモートサイトから新しいオブジェクトをフェッチしません。
-
--checkout -
このオプションは、updateコマンドに対してのみ有効です。サブモジュールの切り離されたHEAD(detached HEAD)のスーパープロジェクトに記録されたコミットをチェックアウトします。これはデフォルトの動作です。このオプションの主な用途は、
checkout以外の値に設定されたときにsubmodule.$name.updateをオーバーライドすることです。 キーsubmodule.$name.updateが明示的に設定されていないか、checkoutに設定されている場合、このオプションが暗黙に指定されています。 -
--merge -
このオプションは、updateコマンドに対してのみ有効です。 スーパープロジェクトに記録されたコミットをサブモジュールの現在のブランチにマージします。 このオプションを指定すると、サブモジュールのHEADは切り離されません。 マージの失敗によりこの処理が妨げられる場合は、通常の競合解決ツールを使用して、サブモジュール内で発生する競合を解決する必要があります。 キー
submodule.$name.updateがmergeに設定されている場合、このオプションが暗黙に指定されます。 -
--rebase -
このオプションは、updateコマンドに対してのみ有効です。 現在のブランチをスーパープロジェクトに記録されたコミットにリベースします。 このオプションを指定すると、サブモジュールのHEADは切り離されません。 マージの失敗によりこのプロセスが妨げられる場合は、 git-rebase(1) を使用してこれらの失敗を解決する必要があります。 キー
submodule.$name.updateがrebaseに設定されている場合、このオプションが暗黙に指定されます。 -
--init -
このオプションは、updateコマンドに対してのみ有効です。更新する前に、これまで
git submodule initが呼び出されていないすべてのサブモジュールを初期化します。 -
--name -
このオプションは、addコマンドに対してのみ有効です。 サブモジュールの名前を、デフォルトのパスではなく、指定の文字列に設定します。 名前はディレクトリ名として有効である必要があり、
/で終わらせることはできません。 -
--reference <repository> -
このオプションは、addとupdateコマンドにのみ有効です。これらのコマンドでは、リモートリポジトリのクローンを作成する必要がある場合があります。その場合、このオプションを git-clone(1) コマンドに渡します。
注意: git-clone(1) の
--referenceと--sharedと--dissociateオプションに関するNOTEを注意深く読んでいない限り、 このオプションを使用しないでください。 -
--dissociate -
このオプションは、addとupdateコマンドにのみ有効です。これらのコマンドでは、リモートリポジトリのクローンを作成する必要がある場合があります。その場合、このオプションを git-clone(1) コマンドに渡します。
注意:
--referenceオプションについては NOTE を参照してください。 -
--recursive -
このオプションは、foreachとupdateとstatusとsyncコマンドにのみ有効です。サブモジュールを再帰的にトラバースします。この操作は、現在のリポジトリのサブモジュールだけでなく、それらのサブモジュール内のネストされたサブモジュール(など)でも実行されます。
-
--depth -
このオプションは、addとupdateコマンドに有効です。 指定のリビジョン数に切り捨てられた履歴を持つ「浅い」クローン(shallow clone)を作成します。 git-clone(1) を参照してください。
-
--[no-]recommend-shallow -
このオプションは、updateコマンドに対してのみ有効です。サブモジュールの初期クローンは、デフォルトで
.gitmodulesファイルによって提供される推奨されるsubmodule.<name>.shallowを使用します。 提案を無視するには、--no-recommend-shallowを使用します。 -
-j <n> -
--jobs <n> -
このオプションは、updateコマンドに対してのみ有効です。多くのジョブと並行して新しいサブモジュールのクローンを作成します。デフォルトは
submodule.fetchJobsオプションです。 -
--[no-]single-branch -
このオプションは、updateコマンドに対してのみ有効です。 HEAD または、
--branchで指定されたブランチは、更新中に1つのブランチのみを複製します - <path>…
-
サブモジュールへのパス。これを指定すると、指定したパスで見つかったサブモジュールでのみ動作するようにコマンドが制限されます。(この引数はaddでは必須です)。
FILES
サブモジュールを初期化するとき、含まれているリポジトリの最上位ディレクトリにある .gitmodules ファイルを使用して、各サブモジュールのURLを検索します。 このファイルは、 $GIT_DIR/config と同じ方法でフォーマットする必要があります。各サブモジュールURLのキーは、「submodule.$name.url」です。 詳細については、 gitmodules(5) を参照してください。
SEE ALSO
GIT
Part of the git(1) suite