TortoiseGit サブモジュールをリモート最新状態に更新する際の失敗例

エクスプローラで Git 操作ができるクライアントソフト TortoiseGit を用いて、追加したサブモジュールを対応するリモートリポジトリの最新の状態に更新するために模索した際の失敗例を紹介します。
フェッチした後に参照を切り替えてチェックアウトすることで、サブモジュールをリモートリポジトリの最新の状態にアップデートする手順についても紹介しますが、「サブモジュールを更新」（git submodule update で –remote オプション）を行った方が簡単でした。

※ TortoiseGit-2.17.0.2-64bit を使用します。

前回の記事

TortoiseGit を用いて、追加したサブモジュールを対応するリモートリポジトリの最新の状態に更新する手順を紹介しました。
サブモジュールの変更をコミット・プッシュして、ハッシュ値（SHA-1）の比較を行いました。

簡単にサブモジュールをアップデートする手順については、以下の記事を参照してください。

TortoiseGit サブモジュールをリモートリポジトリの最新の状態に更新

TortoiseGit を用いて、追加したサブモジュールを対応するリモートリポジトリの最新の状態に更新する手順を紹介します。その後、サブモジュールが指すリビジョンの変更を、スーパープロジェクトにコミットし、スーパープロジェクトのリモートリポジトリにプッシュし、結果をハッシュ値（SHA-1）で確認します。

compota-soft.work

2026.01.25

今回は、それ以外の方法でサブモジュールをアップデートしようとして非効率だったり、失敗した例を紹介します。

サブモジュール内でフェッチして更新した結果

TortoiseGit の「フェッチ」ダイアログを使うことで、指定したリモートリポジトリの最新の情報を取得できます。

結果としては、サブモジュール自体をフェッチした後に、現在のブランチを切り替えることで、リモートリポジトリの最新のコミットの状態になりますが、「サブモジュールを更新」（git submodule update）を行った方が簡単です。

Update the registered submodules to match what the superproject expects by cloning missing submodules, fetching missing commits in submodules and updating the working tree of the submodules. The “updating” can be done in several ways depending on command line options and the value of submodule.<name>.update configuration variable. The command line option takes precedence over the configuration variable. If neither is given, a checkout is performed. (note: what is in .gitmodules file is irrelevant at this point; see git submodule init above for how .gitmodules is used). 

欠落しているサブモジュールのクローンを作成し、サブモジュール内の欠落しているコミットをフェッチし、サブモジュールの作業ツリーを更新することにより、スーパープロジェクトが期待するものと一致するように登録されたサブモジュールを更新します。 「更新」は、コマンド ライン オプションと submodule..update 構成変数の値に応じて、いくつかの方法で行うことができます。コマンド ライン オプションは構成変数よりも優先されます。どちらも指定されていない場合は、チェックアウトが実行されます。 (注: .gitmodules ファイルの内容はこの時点では関係ありません。.gitmodules の使用方法については、上記の git submodule init を参照してください)。

Git – git-submodule Documentation と Google 翻訳

TortoiseGit でフェッチを行うには、対象の作業ディレクトリ（例ではサブモジュール内）をエクスプローラで開いて、右クリックで表示されるメニュー「TortoiseGit」→「フェッチ」で「フェッチ」ダイアログを表示します。

• 「リモート」枠の「リモート」ラジオボタンを選択して、リモート名を選択します。
  ※リモート名は、ダイアログ下側の「リモートを管理」リンクをクリックして「設定」ダイアログを開いて作成・編集できます。
• 「オプション」枠では「タグ」にチェックをいれてリモートリポジトリのタグの情報も取得するように設定します。

設定が済んだら OK ボタンを押します。

リモートリポジトリの情報のフェッチが成功しました。

git.exe fetch -v --progress -- "origin"
From G:/Dev/Godot4GD/SakuraCrowd/ScLibProject/remote/sc-fit-font-size
= [up to date]      develop    -> origin/develop

成功 (188 ms @ 2025/09/13 16:11:35)

しかし、サブモジュール内でフェッチしても、サブモジュールの作業ディレクトリはリモートリポジトリの最新の状態に変わりません。

例では、リモートリポジトリの最新のコミットにだけ、２つ目のサブモジュールを追加したのですが、サブモジュール内の .gitmodules ファイルを確認しても１つしか設定がなく、最新の状態になっていません。

[submodule "sc-util"]
	path = sc-util
	url = G:/Dev/Godot4GD/SakuraCrowd/ScLibProject/remote/sc-util.git

スーパープロジェクト（サブモジュールを持つ上位のリポジトリ）をエクスプローラで開いて、右クリックして表示されるメニュー「TortoiseGit」→「リポジトリブラウザー」を選択して、サブモジュールのフォルダショートカットを選択して、そのサブモジュールのリビジョンのハッシュ値（SHA-1）を確認すると、リモートリポジトリの最新のコミットのリビジョンのハッシュ値（SHA-1）ではなく、サブモジュール追加時の古いコミットを指すハッシュ値でした。

「リポジトリブラウザー」のサブモジュールのフォルダショートカットをダブルクリックすると、そのサブモジュールの内容を確認できます。
その結果、こちらもサブモジュールの作業ディレクトリと同じく古い状態で、リモートリポジトリの最新のコミットにだけある２つ目のサブモジュールが存在しませんでした。

下図は PC 内のリモートリポジトリを「リポジトリブラウザー」で表示した結果です。
１つ前のサブモジュールでは存在しなかった、リモートリポジトリの最新のコミットにだけ存在する２つ目のサブモジュール（例：sc-util-editor）が確認できます。

サブモジュールのフォルダをエクスプローラで開いて表示されるメニュー「TortoiseGit」→「ref ブラウザ」で参照を確認すると、現在のブランチは refs/heads/develop で、最後のコミットは、サブモジュール追加時の古いものでした。

フェッチで作られたと思われる新しい参照 remotes/origin/develop, HEAD には、リモートリポジトリの最新のコミットが確認できます。

この remotes/origin/develop, HEAD に「切り替え / チェックアウト」することで、サブモジュールの作業ディレクトリはリモートリポジトリの最新の状態になりました。

この結果から、サブモジュール自体をフェッチした後に、現在のブランチを切り替えることで、リモートリポジトリの最新のコミットの状態になります。
しかし、「サブモジュールを更新」（git submodule update）を行った方が簡単です。

既定の「サブモジュールを更新」ではリモートの最新は得られません

スーパープロジェクト（サブモジュールを持つ上位のリポジトリ）をエクスプローラで開いて、右クリックして表示されるメニュー「TortoiseGit」→「サブモジュールのアップデート」を選択して表示される「サブモジュールを更新」ダイアログを使うと、前の章よりも簡単にサブモジュールを更新できます。

しかし、「リモート追跡ブランチ」（–remote オプション）をチェックしていないと、サブモジュールを追加した時点で作成されたスーパープロジェクト内の .git/modules/ 内にあるサブモジュール用のリポジトリを用いて更新を行うため、リモートリポジトリの最新の情報は得られません。

–remote

This option is only valid for the update command. Instead of using the superproject’s recorded SHA-1 to update the submodule, use the status of the submodule’s remote-tracking branch. The remote used is branch’s remote (branch.<name>.remote), defaulting to origin. The remote branch used defaults to the remote HEAD, but the branch name may be overridden by setting the submodule.<name>.branch option in either .gitmodules or .git/config (with .git/config taking precedence).

このオプションは更新コマンドに対してのみ有効です。スーパープロジェクトの記録された SHA-1 を使用してサブモジュールを更新する代わりに、サブモジュールのリモート追跡ブランチのステータスを使用します。使用されるリモートはブランチのリモート（branch..remote）で、デフォルトはoriginです。使用されるリモート ブランチはデフォルトでリモート HEAD になりますが、.gitmodules または .git/config のいずれかで submodule..branch オプションを設定することでブランチ名をオーバーライドできます（.git/config が優先されます）。

This works for any of the supported update procedures (--checkout, --rebase, etc.). The only change is the source of the target SHA-1. For example, submodule update --remote --merge will merge upstream submodule changes into the submodules, while submodule update --merge will merge superproject gitlink changes into the submodules.

これは、サポートされている更新手順（–checkout、–rebase など）のいずれでも機能します。唯一の変更は、ターゲット SHA-1 のソースです。たとえば、submodule update –remote –merge はアップストリームのサブモジュールの変更をサブモジュールにマージし、submodule update –merge はスーパープロジェクトの gitlink の変更をサブモジュールにマージします。

In order to ensure a current tracking branch state, update --remote fetches the submodule’s remote repository before calculating the SHA-1. If you don’t want to fetch, you should use submodule update --remote --no-fetch.

現在の追跡ブランチ状態を確認するには、SHA-1 を計算する前に、update –remote でサブモジュールのリモート リポジトリを取得します。取得したくない場合は、submodule update –remote –no-fetch を使用する必要があります。

Use this option to integrate changes from the upstream subproject with your submodule’s current HEAD. Alternatively, you can run git pull from the submodule, which is equivalent except for the remote branch name: update --remote uses the default upstream repository and submodule.<name>.branch, while git pull uses the submodule’s branch.<name>.merge. Prefer submodule.<name>.branch if you want to distribute the default upstream branch with the superproject and branch.<name>.merge if you want a more native feel while working in the submodule itself.

このオプションを使用して、上流のサブプロジェクトからの変更をサブモジュールの現在の HEAD に統合します。あるいは、サブモジュールから git pull を実行することもできます。これはリモート ブランチ名を除いて同等です。update –remote はデフォルトの上流リポジトリと submodule..branch を使用し、git pull はサブモジュールのbranch..merge を使用します。デフォルトの上流ブランチをスーパープロジェクトとともに配布する場合は submodule..branch を、サブモジュール自体での作業中によりネイティブな操作感が必要な場合は branch..merge を優先します。

Git – git-submodule Documentation と Google 翻訳

「リモート追跡ブランチ」（–remote オプション）を有効にしていなかったため、「サブモジュールの更新」(git submodule update)を行っても、 リモートリポジトリの最新の状態には変わりませんでした。

git.exe submodule update --progress --init --recursive -- "addons/sc-fit-font-size"

成功 (1015 ms @ 2025/09/13 16:14:29)

まとめ

• サブモジュールを、リモートリポジトリの最新の状態にするには、TortoiseGit の場合「サブモジュールを更新」ダイアログ（git submodule update）で「リモート追跡ブランチ」（–remote オプション）を有効にする。
  
• サブモジュール内で「フェッチ」を行うことでリモートリポジトリの最新の状態を取得できるが、作業ディレクトリに反映させるには参照を変える必要がある。

参照サイト Thank You!

• Git
• Git – git-submodule Documentation
• Git – サブモジュール
• TortoiseGit – Windows Shell Interface to Git

記事一覧 → Compota-Soft-Press