フォルダー自体は Git にとってまったく無関心です:ファイルのみが追跡されません (ファイルのみが追跡されるため)。1 だからgit status
言うとき:
?? public/bar/
それは何かを隠しています。それが隠しているのは、どこかに少なくとも 1 つのファイルpublic/bar/
があるという事実です。
実行git clean -fd
しても、この追跡されていないファイルが必ずしも削除されるわけではありません。特に、-x
またはを指定しないと-X
、追跡されていない間は無視されたファイルgit clean
が削除されなくなります。
IMSoP がコメントで言及しているように、使用git status --untracked-files=all --ignored
するとより多くの情報が得られます。内のさまざまなファイルの名前が表示されますpublic/bar/
。ここで何をするかというと、含まれているディレクトリを(末尾にスラッシュを付けて)git status
アナウンスすることで複数のファイルがあることを要約できる場合、各ファイルを 1 つずつアナウンスする必要がないことに注意してください。public/bar/
1サブモジュールがあるため、これは完全には真実ではありませんが、問題について考えさせるには十分に近いものです。また、ドキュメントgit clean
では、オプションの説明の下で「追跡されていないディレクトリ」について説明してい-d
ますが、これはどういう意味ですか? 手がかりは、-x
および-X
オプションの説明にあります。
-x
標準の無視ルールを使用しないでください...
一般に、無視ルールがどのように機能するかという点で、何かが欠けています。私が切り取ったセクションでこれが参照している gitignore のドキュメントでさえ、次のような重要な詳細をカバーしていません:
- 追跡されていないファイルを見つけるために、Git は作業ツリー内のファイルのツリーをたどる必要があります。つまり、そのディレクトリ内に存在するファイルを確認するには、各ディレクトリ (または、その用語を好む場合はフォルダー) をピアリングする必要があります。
- ファイル ツリーをたどる (ディレクトリを開いて読み取り、ファイルのリストを取得し、すべてのサブディレクトリを再帰的に開いて読み取る) には時間がかかります。
- Gitignore ルール (
.gitignore
特定のパターンを無視するファイル内の行) は、末尾にスラッシュを付けて明示的に、またはディレクトリ名が一部の gitignore 行と一致するため暗黙的に、ディレクトリ名を一覧表示できます。
- したがって、Git がディレクトリ内のすべてのファイル (たとえば、
public/bar/
—<em>) が無視されることを事前に判断できれば、Git はそのディレクトリを開いて読み取ることを単純に回避できます。意味がありません。Git がここで見つけたものはすべて無視されます!
最後の箇条書きのショートカットは時間を節約します。大規模なビルドでは、典型的な最新のシステムでは、実行を文字通り数秒git status
(場合によっては数十秒、またはそれ以上) 短縮できます。したがって、可能な場合は両方git status
をgit clean
利用してください。ただし、すべてが無視されるディレクトリ内の実際のファイルを列挙する必要がある場合でも、ディレクトリを開いて読み取る必要があります。