解释哪个gitignore规则忽略了我的文件

Question

有没有办法看到为什么某些文件被git忽略（即.gitignore文件中的哪个规则导致文件被忽略）？

想象一下，我有这个（或者更复杂的场景，有数百个文件夹和数十个.gitignore文件：

/
-.gitignore
-folder/
    -.gitignore
    -subfolder/
              -.gitignore
              -file.txt

如果我运行git add folder/subfolder/file.txt git可能会抱怨它被忽略：

The following paths are ignored by one of your .gitignore files:
folder/subfolder/file.txt
Use -f if you really want to add them.

有没有办法知道哪个可能的.gitignore有规则忽略这个文件，还显示规则？喜欢：

The following paths are ignored by your folder/.gitignore file (line 12: *.txt)
folder/subfolder/file.txt
Use -f if you really want to add them.

要不就：

$ git why-is-ignored folder/subfolder/file.txt
folder/.gitignore:12:*.txt

Answer 1

git check-ignore -v filename

有关详细信息，请参阅the man page。

原始答案如下：

git目前不提供此类内容。但在看到你的问题后，我做了一些谷歌搜索，发现回到2009年this feature was requested and partially implemented。在阅读完线程之后，我意识到要正确地完成这项工作并不会太多，所以我已经开始研究补丁并希望在接下来的一两天内完成。我准备好后会更新这个答案。

更新：哇，这比我想象的要难得多。 git排除处理的内部非常神秘。无论如何，这里的an almost finished series of commits适用于今天的上游master分支。测试套件完成了99％，但我还没有完成--stdin选项的处理。希望我能在本周末管理它，然后将我的补丁提交到git邮件列表。

与此同时，我绝对欢迎任何能够这样做的人进行测试 - 只需从my git fork克隆，查看check-ignore分支，然后正常编译。

更新2：已经完成了！最新版本在github上面，如上所述，我有submitted the patch series to the git mailing list进行同行评审。让我们看看他们的想法......

更新3：经过几个月的黑客/补丁评论/讨论/等待，我很高兴能够说出this feature has now reached git's master branch，并将在下一版本（1.8.2，预计2013年3月8日）上发布。这是check-ignore manual page。哎呀，这比我想象的要多得多！

更新4：如果您对这个答案如何演变并且该功能得到实施的完整故事感兴趣，请查看episode #32 of the GitMinutes podcast。

Answer 2

更新git 2。8（2016年3月）：

GIT_TRACE_EXCLUDE=1 git status

见“A way to validate .gitignore file”

这是对下面描述的git check-ignore -v的补充。

---

原始答案：2013年9月（git 1.8.2，然后1.8.5+）：

git check-ignore在git 1.8.5/1.9 (Q4 2013)再次改善：

“git check-ignore”遵循与“git add”和“git status”相同的规则，因为忽略/排除机制不会对已经跟踪的路径生效。 使用“--no-index”选项，它可用于诊断应该被忽略的路径被错误地添加到索引中。

参见commit 8231fa6的https://github.com/flashydave：

check-ignore目前展示了.gitignore规则如何处理未跟踪路径。跟踪路径不会生成有用的输出。 这可以防止调试路径被意外跟踪的原因，除非首先使用git rm --cached <path>从索引中删除该路径。

选项--no-index告诉命令绕过对索引中路径的检查，因此也允许检查跟踪路径。

虽然这种行为偏离了git add和git status的特征，但它的使用案例不太可能引起任何用户混淆。

扩充测试脚本以针对标准忽略检查此选项以确保正确的行为。

---

--no-index::

在进行检查时不要查看索引。 这可以使用：

• 调试例如跟踪路径的原因git add .并没有被用户所预期的规则所忽视
• 在开发包含否定的模式以匹配之前添加了git add -f的路径时。

Answer 3

我在man手册页中找不到任何内容，但这里有一个快速而脏的脚本，它将检查每个父目录中的文件，看看它是否可以git-add'ed。在包含问题文件的目录中运行它：

test-add.sh STOP_DIR FILENAME

其中STOP_DIR是Git项目的顶级目录，FILENAME是问题文件名（没有路径）。它在层次结构的每个级别创建一个同名的空文件（如果它不存在）并尝试使用git add -n来查看它是否可以添加（它自己清理后）。它输出如下：

FAILED:    /dir/1/2/3
SUCCEEDED: /dir/1/2

剧本：

#!/usr/bin/env bash
TOP=$1
FILE=$2
DIR=`pwd`
while : ; do
  TMPFILE=1
  F=$DIR/$FILE
  if [ ! -f $F ]; then
    touch $F
    TMPFILE=0
  fi
  git add -n $F >/dev/null 2>&1
  if [ $? = 0 ]; then
    echo "SUCCEEDED: $DIR"
  else
    echo "FAILED:    $DIR"
  fi
  if [ $TMPFILE = 0 ]; then
    rm $F
  fi
  DIR=${DIR%/*}
  if [ "$DIR" \< "$TOP" ]; then
    break
  fi
done 

Answer 4

要添加到使用git check-ignore -v filename的主要答案（感谢BTW），我发现我的.gitignore文件阻止了所有内容，因为在通配符后面有换行符，所以我有：

*
.sublime-project

举个例子。我刚刚删除换行符，瞧！它是固定的。