読者の利益のために、ここではそれを要約し、物事が期待どおりに機能しない場合にそれを行う方法について段階的なガイドを提供することを試みます。以下は、サブモジュールを取り除くためのバージョン以上のテスト済みで安全な方法です。git2.17
submodule="path/to/sub" # no trailing slash!
git submodule deinit -- "$submodule"
git rm -- "$submodule"
- これでうまくいかない場合は、以下を参照してください。
- オプションはありません。危険はありません。そして、もっとやることを考えさえしないでください！
- Debian Buster
2.20.1およびUbuntu 18.04でテスト済み2.17.1。
"$submodule" 名前を付ける場所を強調するだけで、スペースなどに注意する必要があります- Windowsの場合、最初の行を無視
"$submodule"し、サブモジュールへの適切に指定されたパスのWindowsの方法で置き換えます。（私はWindowsではありません）
警告！
.git自分でディレクトリの内部に触れないでください。 内部編集.gitはダークサイドに入ります。絶対に近づかないでください！
そして、はい、git多くの便利なものが欠けていたので、あなたはこれのせいにすることができますgit過去にたので、。サブモジュールを再び削除する適切な方法のように。
のドキュメントには非常に危険な部分があると思いますgit submodule。$GIT_DIR/modules/<name>/自分自身を削除することをお勧めします。
私の理解では、これは明らかに間違っているだけでなく、非常に危険であり、将来的に大きな頭痛の種となるでしょう！ 下記参照。
ご了承ください
git module deinit
の直接逆
git module init
だが
git submodule deinit -- module
git rm -- module
また、かなり逆です
git submodule add -- URL module
git submodule update --init --recursive -- module
一部のコマンドは、基本的に1つ以上のことを実行する必要があるためです。
git submodule deinit -- module
git rm
- （2）モジュールのファイルを削除します
- （3）これにより、サブモジュールのサブモジュールが再帰的に削除されます
- （4）アップデート
.gitmodules
git submodule add
- データを引き込む
.git/modules/NAME/
- （1）する
git submodule initので、更新.git/config
- （2）行う
git submodule updateので、モジュールを非再帰的にチェックアウトします
- （4）アップデート
.gitmodules
git submodule update --init --recursive -- module
- 必要に応じてさらにデータを取得します
- （3）サブモジュールのサブモジュールを再帰的にチェックアウトします
これを完全に対称にすることはできません。厳密に対称に保つことはあまり意味がありません。3つ以上のコマンドは必要ありません。また、「データのプル」は暗黙的に行われます。必要なためですが、キャッシュされた情報の削除は行われません。これはまったく必要がなく、貴重なデータを消去する可能性があるためです。
これは本当に初心者には不可解ですが、基本的には良いことです。 git明らかにそれを実行し、それを正しく実行するだけで、それ以上のことはしません。 gitは、単なる別の "Eierlegende Wollmilchsau"（ "Eierlegende Wollmilchsau"は "スイスアーミーナイフのいくつかの邪悪なバージョン"と解釈されます）ではなく、信頼できる仕事をしなければならないツールです。
だから私は「なぜ私にはgit明白なことをしないのか」と言って人々の不満を理解しています。これは、ここでの「自明」が観点から決まるためです。あらゆる状況での信頼性ははるかに重要です。したがって、多くの場合、明らかなことは、考えられるすべての技術的状況において正しいことではありません。覚えておいてください：AFAICSgitは社会的な道ではなく、技術的な道をます。（したがって、賢い名前：git）
これが失敗した場合
上記のコマンドは、次の理由で失敗する可能性があります。
- あなた
gitは年を取りすぎています。その後、新しいを使用してくださいgit。（以下の方法を参照してください。）
- コミットされていないデータがあり、データを失う可能性があります。次に、最初にそれらをコミットします。
- あなたのサブモジュールはある
git clean意味できれいではありません。次に、最初にそのコマンドを使用してサブモジュールをクリーンアップします。（下記参照。）
- あなたは過去にサポートされていない何かをしました
git。次に、あなたは暗い側面にあり、物事は醜く複雑になります。（おそらく別のマシンを使用すると修正されます。）
- おそらく、私が気づいていない失敗する方法が他にもあるでしょう（私は一部の
gitパワーユーザーです）。
可能な修正が続きます。
新しいものを使う git
あなたのマシンが古すぎる場合は全くありませんsubmodule deinit、あなたにgit。を更新したくない（または更新できない）場合gitは、新しいgit！の別のマシンを使用してください。 git完全に分散されることを意図しているので、別のものgitを使って仕事を終わらせることができます：
workhorse:~/path/to/worktree$ git status --porcelain 何も出力しないでください！ある場合は、最初にクリーンアップしてください！workhorse:~/path/to/worktree$ ssh account@othermachineothermachine:~$ git clone --recursive me@workhorse path/to/worktree/.git TMPWORK && cd TMPWORK- 次にサブモジュールのことを行います
othermachine:~/TMPWORK$ git commit . -m . && exitworkhorse:~/path/to/worktree$ git fetch account@othermachine:TMPWORK/.gitworkhorse:~/path/to/worktree$ git merge --ff-only FETCH_HEAD。これが機能しない場合は、git reset --soft FETCH_HEAD- クリーンアップするように
git statusなりました。最初のステップのおかげで、以前はきれいにしていたので、それを行うことができます。
これothermachineは、VMでも、WindowsでのUbuntu WSLでもかまいません。a chroot（ただし、ルートでない場合はroot、新しいに更新する方が簡単であるため、ルートでないことを前提としていますgit）。
ssh入室できない場合は、gitリポジトリを転送する方法がたくさんあることに注意してください。ワークツリーをUSBスティック（.gitディレクトリを含む）にコピーし、スティックからクローンを作成できます。コピーを複製して、再びクリーンな状態にしてください。他のマシンから直接サブモジュールにアクセスできない場合、これはPITAである可能性があります。しかし、これに対する解決策もあります：
git config --add url.NEWURLPREFIX.insteadOf ORIGINALURLPREFIX
この乗算を使用でき、これはに保存され$HOME/.gitconfigます。何かのようなもの
git config --add 'url./mnt/usb/repo/.insteadof' https://github.com/
のようなURLを書き換えます
https://github.com/XXX/YYY.git
に
/mnt/usb/repo/XXX/YYY.git
gitこのような強力な機能に慣れ始めたら簡単です。
最初にクリーンアップする
手動でクリーンアップすることをお勧めします。これにより、忘れていたものを検出できる可能性があります。
- 保存されていないものについてgitが文句を言う場合は、コミットして安全な場所にプッシュしてください。
- gitのは、いくつかの残り物を訴え、場合
git statusとgit clean -ixfdあなたの友達です
- オプションを控えるようにしてください
rmとdeinitすることができます限り。あなたがプロであるなら-f、オプション（のような）gitは良いです。しかし、あなたがここに来たとき、あなたはおそらくそのsubmodule地域でそれほど経験されていません。申し訳ありませんが、安全であることをお勧めします。
例：
$ git status --porcelain
M two
$ git submodule deinit two
error: the following file has local modifications:
two
(use --cached to keep the file, or -f to force removal)
fatal: Submodule work tree 'two' contains local modifications; use '-f' to discard them
$ cd two
$ git submodule deinit --all
error: the following file has local modifications:
md5chk
(use --cached to keep the file, or -f to force removal)
fatal: Submodule work tree 'md5chk' contains local modifications; use '-f' to discard them
$ cd md5chk
$ git submodule deinit --all
error: the following file has local modifications:
tino
(use --cached to keep the file, or -f to force removal)
fatal: Submodule work tree 'tino' contains local modifications; use '-f' to discard them
$ cd tino
$ git status --porcelain
?? NEW
$ git clean -i -f -d
Would remove the following item:
NEW
*** Commands ***
1: clean 2: filter by pattern 3: select by numbers 4: ask each
5: quit 6: help
What now> 1
Removing NEW
$ cd ../../..
$ git status --porcelain
$ git submodule deinit two
Cleared directory 'two'
Submodule 'someunusedname' (https://github.com/hilbix/src.git) unregistered for path 'two'
ご覧のとおり、には-f必要ありませんsubmodule deinit。あるgit clean意味で物事がきれいなら。また、git clean -x必要ないことに注意してください。 これgit submodule deinitは、無視された追跡されていないファイルを無条件に削除することを意味します。 これは通常あなたが望むものですが、忘れないでください。キャッシュされたデータが再計算されるまでに数時間から数日かかるような、無視されたファイルは貴重な場合があります。
なぜ削除し$GIT_DIR/modules/<name>/ないのですか？
後で問題が発生するのを恐れているため、おそらくキャッシュされたリポジトリを削除したいと思うでしょう。これは本当ですが、その「問題」に遭遇することがそれを解決する正しい方法です！修正は簡単で、正しく行われるので、いつまでも幸せに暮らせるでしょう。これにより、自分でデータを削除する場合よりも厄介な問題を回避できます。
例：
mkdir tmptest &&
cd tmptest &&
git init &&
git submodule add https://github.com/hilbix/empty.git two &&
git commit -m . &&
git submodule deinit two &&
git rm two &&
git commit -m . &&
git submodule add https://github.com/hilbix/src.git two
最後の行は次のエラーを出力します：
A git directory for 'two' is found locally with remote(s):
origin https://github.com/hilbix/empty.git
If you want to reuse this local git directory instead of cloning again from
https://github.com/hilbix/src.git
use the '--force' option. If the local git directory is not the correct repo
or you are unsure what this means choose another name with the '--name' option.
なぜこのエラーなのか？ので.git/modules/two/以前から移入されたhttps://github.com/hilbix/empty.gitとなりましすなわち、何か他のものから再投入されなければならないhttps://github.com/hilbix/src.git。https://github.com/hilbix/empty.gitから再入力しても、これは表示されません
今何をする？まあ、ちょうど言われたとおりにしてください！使用する--name someunusedname
git submodule add --name someunusedname https://github.com/hilbix/src.git two
.gitmodules その後のようになります
[submodule "someunusedname"]
path = two
url = https://github.com/hilbix/src.git
ls -1p .git/modules/ 与える
someunusedname/
two/
この方法では、将来、ブランチ/コミットを前後に切り替えることができ、two/2つの異なる（場合によっては互換性のない）アップストリームリポジトリがあるため、再び問題が発生することはありません。そして、最高のものは、両方ともローカルにキャッシュすることです。
- これはあなただけに当てはまるわけではありません。これは、リポジトリを使用する他のすべてのユーザーにも当てはまります。
- そして、あなたは歴史を失うことはありません。古いサブモジュールの最新バージョンをプッシュするのを忘れた場合は、ローカルコピーを入力して後で実行できます。誰かがいくつかのサブモジュールをプッシュするのを忘れるのはごく一般的なことです（これは、慣れるまで、これは新参者のためのPITAであるため
git）。
しかし、キャッシュされたディレクトリを削除した場合、--nameオプションを使用しないため、両方の異なるチェックアウトが互いにぶつかります。したがって、チェックアウトを実行するたびに、おそらく.git/modules/<module>/ディレクトリを何度も削除する必要があります。これは非常に扱いにくく、のようなものを使用するのを難しくしますgit bisect。
したがって、このモジュールディレクトリをプレースホルダーとして保持することには、非常に技術的な理由があります。以下の何かを削除することを推奨する人々は、これがそのようなサブモジュールの非互換性を越える.git/modules/と、これが強力な機能git bisectを使用することをほぼ不可能にするようなことをよく知らない、または忘れることを忘れます。
さらなる理由は上に示されています。を見てくださいls。そこで何が見えますか？
さて、モジュールの2番目のバリアントはtwo/下.git/modules/two/にありません、下にあり.git/modules/someunusedname/ます！のようなものgit rm $module; rm -f .git/module/$moduleは完全に間違っています！相談するmodule/.gitか.gitmodules、削除する適切なものを見つける必要があります！
したがって、他のほとんどの回答がこの危険なトラップに該当するだけでなく、非常に人気のあるgit拡張機能にもこのバグがありました（現在は修正されています）。そのため、.git/正確に行わない場合は、ディレクトリを手元に置いておくことをお勧めします。
そして哲学的な観点から、歴史を拭くのは常に間違っています！
いつものように、量子力学を除いて、これは完全に異なるものです。
FYIあなたはおそらくそれを推測：hilbixは、私のGitHubのアカウントです。
git rm modulenameにrm -rf .git/modules/modulename