Git 未获取被忽略的跟踪文件
Git not fetching ignored tracked files
这个问题几乎与如何阻止 Git 跟踪忽略的文件的常见问题解答相反。在这种情况下，我想跟踪它们，而不是忽略它们。
我有一个 .gitignore 文件，其中包含以下行：
**/*.exe
大多数时候，.exe 文件是构建的产物，应该被忽略（这个项目托管在 MinGW 和 Cygwin 的组合上，所以 运行 上的二进制文件 Windows.)
但是，此忽略规则也有例外。我在我的源代码树中添加了一些 .exe 文件。据我了解，.gitignore 不适用于跟踪文件（索引中的文件）。
但是，当我克隆我的存储库时，.exe 文件没有被提取。
如果我在添加它的原始存储库中对文件执行git status，我得到：
$ git status program.exe
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
该文件也存在于工作树中：
$ ls -l program.exe
-rwxrwx---+ 1 abc xyz 23040 Mar 20 15:35 program.exe
$ git log program.exe
commit 412fd58b5a11bf6a40f661109e71f2c0026c1643
Author: abc <abc@xyz.com>
Date: Sat Apr 1 02:21:40 2017 -0700
cleanup
commit b0a2efd4dc17b70d046c1e7d78e3142cf29410ba
Author: abc <abc@xyz.com>
Date: Mon Mar 20 18:41:00 2017 -0700
Initial version
我已将提交推送到另一台服务器上的裸存储库。我可以在裸仓库中找到最新签入对应的blob：
MyProject.git/objects/41/2fd58b5a11bf6a40f661109e71f2c0026c1643
很明显它被跟踪了。但是当我克隆存储库时，它不会出现在工作树中。 在克隆的存储库上：
$ git status program.exe
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
$ ls -l program.exe
ls: cannot access 'program.exe': No such file or directory
我没有使用 assume-unchanged 之类的东西。
被忽略但在其他存储库中提取时跟踪文件仍然被忽略？
即使它们匹配.gitignore，你如何强制获取它们？
是否需要将它们排除在匹配 .gitignore 之外才能被提取？
$ git --version
git version 2.12.0.windows.1
编辑：请记住，我并不是要在将跟踪文件添加到 .gitignore 后忽略它们；我正在尝试 获取 跟踪和提交的文件，尽管它们匹配 .gitignore.
您的构建文件位于 bin 文件夹中。所以你必须添加到你的 .gitignore 中：
bin/*.exe or bin/*
你应该从你的 gitignore 文件中删除这一行：
**/*.exe
编辑：如果你想忽略除了其中一些之外的所有 exe 文件，你可以使用“！”排除它们。在线条图案的开头，看看这个
TL;DR：我认为这里有一个关于 tracked 意味着什么的关键见解
在我最初的回答和下面的大量讨论之间，我意识到了一些我认为是 non-obvious 的事情。当我第一次使用 Git 时，这对我来说当然不是很明显（可能几个月甚至几年）。这里有两部分：
在Git中，tracked表示在索引中
但是，索引（您将进行的下一次提交）更改 每次您签出一些特定的提交，包括 git checkout otherbranch，因为实例.
这意味着文件是否被跟踪是相对的，不是绝对的。文件 F 可能在 git checkout branch1 之后被跟踪，然后在 git checkout branch2 之后被取消跟踪。它可能在分支 master 上的过去提交中被跟踪，现在在分支 master 上未被跟踪。如果文件未被跟踪 和 都被忽略，但是 过去被 跟踪并且 是 当前被跟踪work-tree，可能很难弄清楚发生了什么。该文件不会出现在新的克隆中，即使它在历史记录中也是如此。
（原始的，完整的答案在此处的行下方。）
However, when I clone my respository, the .exe files are not fetched.
git clone 操作不获取 任何 文件。相反，它获取 commits. 现在，提交确实包含文件，所以这可能看起来像是一种毫无意义的迂腐，但它是你的问题的核心，事实上几乎所有Git，所以它真的很重要。 Git 不关心 文件； Git 只关心提交。
提交本身形成了历史。每个提交都包含一些文件集，但也有一个 back-pointer 到前一个提交："This is what we have now. This is the hash ID of the commit we had before." 我们称之为提交的 parent。 parent 提交也有自己的 parent。此 backwards-looking 链 是 存储库中的历史记录。
像master这样的分支名称是Git记录该分支的当前哈希ID的方式。 Git 从这里开始，在最近一次提交时，使用分支名称；然后 Git 在需要时向后工作，获取较旧的 (parent) 提交并根据要求转到 still-older（大 parent、great-grandparent 等）提交。
运行 git clone 复制分支名称及其提交，以及该提交的 parent 和 parent 的 parent，等等在;这样你就可以得到所有的历史。每个提交都带有与该提交一起存储的文件，因此一旦您拥有所有提交，您不仅拥有所有 current 文件，而且还拥有所有 以前的当前 parent-commit 个文件，以及每个更早的文件一直回到第一次提交。但是所有这些文件都隐藏在一个秘密中，Git-only 格式除了 Git 对任何东西都没有好处。不过，这就是 git clone 份。
当然，要使 Git 真正发挥作用，我们需要某种 actually-useful 形式的文件。所以 Git 向这个提交历史添加了一些东西——但它不是被 克隆的东西； 这就是你的问题所在。
存储库中有什么
在有用的（即非--bare）存储库中，我们不仅需要所有提交和各种分支名称来记住它们的most-recent哈希 ID，我们还需要一个 work-tree。 work-tree 是我们可以处理实际文件的地方。它们以树状结构排列，包含顶级文件和目录，以及目录中的更多文件和 sub-directories，根据需要。 （因此得名 "work tree"：它是 working-form 个文件的树。）
Git 还抛出另一个东西 Git 调用 index。索引的简短描述是它是您构建 next 提交的地方。如果您从不对自己的存储库进行任何更改，那么该索引只会妨碍您，但 Git 仍然会迫使您了解它。如果你做修改，索引很关键，因为修改的方式就是修改work-tree里面的东西，那么使用 git add 将这些修改复制回索引，以便它们 暂存 用于下一次提交。当您然后 运行 git commit 进行 new 提交时，Git 复制索引 now[=257= 中的任何内容]——也就是说，之前所有的旧东西，除了你用 git adding 新东西替换的东西——到新提交中。
了解这一点非常重要：索引跟踪 work-tree 中的内容。 事实上，这正是 "tracked" 的含义：tracked表示在索引中。但是索引也是下一次提交中的内容，因此它开始匹配 当前提交中的内容 .
您可以——通常 ——在 work-tree 中拥有 delib 文件率 未 跟踪。例如，您的 *.exe 文件是故意未跟踪的。未被跟踪意味着它们不在索引中。这意味着它们也不在当前提交中，1现在我们可以看到会有问题。
1即它们不在当前提交中除非索引为"dirty"因此需要写出一个新的提交。同样，这就是您首先进行新提交的方式：修改 work-tree 中的内容——例如修改文件，或添加 all-new 文件，或删除现有文件——然后复制那些 "dirty" work-tree 文件进入索引，"dirtying" 索引。然后你 git commit 进行 new 提交。新提交的 parent 是当前提交的内容，其文件是索引中的任何内容。 Git 然后将新提交的哈希 ID 写入分支名称，新提交现在是历史的一部分，将永远保存。
异议："I can find the blob"
你提到过：
I can find the blob corresponding to the latest checkin in the bare repository: MyProject.git/objects/41/2fd58b5a11bf6a40f661109e71f2c0026c1643
这意味着文件已在某个时候提交。它在一些历史 提交中。这并不意味着该文件在 最近的 提交中 master 之类的分支上。存储库以 Git-only 内部（压缩 object）格式，every version of every file ever committed。而且，您可以并且经常在您的 work-tree 中拥有一个不在索引中且不在当前提交中的文件。该文件可能与您过去提交的文件很匹配。
因此，文件存在于 存储库 中并不意味着它位于某个特定分支的最新 commit 中。这确实意味着您可以提取历史文件。例如，鉴于上述情况，您可以：
git show 412fd58b5a11bf6a40f661109e71f2c0026c1643 > foo.exe
随时解压到foo.exe。如果您知道提交哈希和路径，您也可以使用它：
git show 1234567:path/to/foo.exe > foo.exe
如果提交有一个名称（例如分支或标签名称）：
git show name:path/to/foo.exe > foo.exe
你可以使用这种方法提取历史文件，但显然有些痛苦。
git clone 在获取所有提交后做了什么
如上所述，git clone 首先复制提交和分支名称。事实上，默认情况下，它将 重命名 这些 branch-names 为 Git 调用的 "remote-tracking branches"。但是，作为它退出之前的最后一步，并称一切正常，ready-to-go、git clone 填写你的 work-tree.
你work-tree里面填的方式是给git checkout某个分支名，一般是master。该分支名称会记住该分支最新提交的哈希 ID。该提交是根据索引进行的，该索引 中没有 .exe 文件。 所以最近的 master 提交 没有里面有 .exe 个文件。
因为这个 work-tree 是全新的，并且被签出的提交中没有 .exe 文件，所以你的新 work-tree 中没有 .exe 文件.这就是他们失踪的原因。
如果那些 .exe 文件 do 存在于存储库中的某些 other 提交中，那么它们就在存储库中，你可以把它们弄出来。你只是不能用简单的方法把它们弄出来：
git checkout master
因为 仅 将为 master 上的最新提交保存的文件提取到索引中，然后再提取到 work-tree 中。
那么 你在哪里得到你的 .exe 文件？
好吧，这部分由您决定。 Git 这里没有 pre-packaged 解决方案。它们可能在您正在克隆的另一个 Git 存储库的 work-tree 中，但是克隆协议中没有任何内容可以获取 work-tree另一个 Git.
处理此问题的一种方法是提交不包含任何内容但最新的.exe文件。然后你可以告诉 Git:
提取到我的 work-tree 中，而不提取到索引中，提交中哈希 ID 为 feede3e
的所有文件
例如，当然假设该提交具有该哈希 ID。事实证明这出奇地困难，因为 Git 真的 想在将文件复制到 work-tree 之前将提交的文件提取到索引中。将它们放入索引会使它们 tracked，这不是您想要的。当然，首先将那些 .exe 文件提交到提交中需要——好吧，还有什么：等等……你猜到了吗？是的，这需要将那些 .exe 个文件放入索引！
Git 就是不会让你两全其美。要么文件被跟踪，因此它们在索引中，因此它们 do 进入提交；或者它们未被跟踪，所以它们不在索引中，所以它们 不 进入提交。选择一个并坚持下去。如果您愿意，可以使用 git worktree add 或此存储库的单独克隆或完全独立的存储库来创建第二个存储库或 work-tree 使用 不同的 确实的分支跟踪并提交了.exe个文件。事实上，您可能希望此分支或其他存储库仅跟踪和保存 .exe 个文件。然后你可以简单地从那里复制 .exe 文件。
或者，当然，您可以从某个确实有它们的地方获得它们，但是通过 git clone 以外的其他方法。
（ 实际上可以在没有单独的 work-tree 的情况下使用各种 Git 的 管道 命令和一个临时索引，但这相当棘手，而不是 Git 是如何工作的。无论如何，请注意，您需要一个容易记住的名称，例如分支名称这让你 latest 提交 latest .exe 文件。让分支名称记住哈希 ID 的想法，使用提交 object 保存文件，并记住之前的提交 object ...好吧，那是一个 分支 。这就是 Git does: 它保留了记住提交哈希的分支名称，这些哈希记住了从索引中保存的文件。所以你真的 do 想要一个单独的 work-tree 并在更新和提交文件的位置分隔索引。毕竟你真的 不想 在 Git 模型之外工作。）
.gitignore 文件是一条红鲱鱼
.gitignore 中的条目主要做两件事：
它抑制关于未跟踪文件的投诉。如果 foo.exe 存在于 work-tree 但不在索引中，因此不会被保存在下一个 git commit, Git whines[=257= 】 对着你。它一遍又一遍地告诉你，"Hey, foo.exe is not going to be committed! Remember to add foo.exe to the index! Don't forget foo.exe, or it won't get committed!" 这变得令人讨厌，并且妨碍了你 想要 看到的关于你真正 的文件的投诉]没有忘记了。因此，将 foo.exe 或 *.exe 添加到 .gitignore 可以关闭此投诉。
它禁止foo.exe被git add -a或类似的自动添加。与其手动 git add 一次将一个文件添加到您的索引，您可以通过提及目录名称、使用 --all 或使用 [=433= 来大量添加脏 work-tree 文件] 像 git add * 这样的 glob。如果 foo.exe 当前未被跟踪 并且 列在 .gitignore 中，这些实际上不会将 foo.exe 复制到索引中。甚至 git add * 也会跳过它，抱怨； git add . 或 git add -a 将毫无怨言地跳过它。
请注意，如果文件 被 跟踪，则在 .gitignore 中列出文件名无效。 .gitignore 中的条目主要是关于防止文件 成为 跟踪，而不是阻止任何已经生效的内容。
这个问题几乎与如何阻止 Git 跟踪忽略的文件的常见问题解答相反。在这种情况下，我想跟踪它们，而不是忽略它们。
我有一个 .gitignore 文件，其中包含以下行：
**/*.exe
大多数时候，.exe 文件是构建的产物，应该被忽略（这个项目托管在 MinGW 和 Cygwin 的组合上，所以 运行 上的二进制文件 Windows.)
但是，此忽略规则也有例外。我在我的源代码树中添加了一些 .exe 文件。据我了解，.gitignore 不适用于跟踪文件（索引中的文件）。
但是，当我克隆我的存储库时，.exe 文件没有被提取。
如果我在添加它的原始存储库中对文件执行git status，我得到：
$ git status program.exe
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
该文件也存在于工作树中：
$ ls -l program.exe
-rwxrwx---+ 1 abc xyz 23040 Mar 20 15:35 program.exe
$ git log program.exe
commit 412fd58b5a11bf6a40f661109e71f2c0026c1643
Author: abc <abc@xyz.com>
Date: Sat Apr 1 02:21:40 2017 -0700
cleanup
commit b0a2efd4dc17b70d046c1e7d78e3142cf29410ba
Author: abc <abc@xyz.com>
Date: Mon Mar 20 18:41:00 2017 -0700
Initial version
我已将提交推送到另一台服务器上的裸存储库。我可以在裸仓库中找到最新签入对应的blob：
MyProject.git/objects/41/2fd58b5a11bf6a40f661109e71f2c0026c1643
很明显它被跟踪了。但是当我克隆存储库时，它不会出现在工作树中。 在克隆的存储库上：
$ git status program.exe
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
$ ls -l program.exe
ls: cannot access 'program.exe': No such file or directory
我没有使用 assume-unchanged 之类的东西。
被忽略但在其他存储库中提取时跟踪文件仍然被忽略？
即使它们匹配
.gitignore，你如何强制获取它们？是否需要将它们排除在匹配
.gitignore之外才能被提取？
$ git --version
git version 2.12.0.windows.1
编辑：请记住，我并不是要在将跟踪文件添加到 .gitignore 后忽略它们；我正在尝试 获取 跟踪和提交的文件，尽管它们匹配 .gitignore.
您的构建文件位于 bin 文件夹中。所以你必须添加到你的 .gitignore 中：
bin/*.exe or bin/*
你应该从你的 gitignore 文件中删除这一行：
**/*.exe
编辑：如果你想忽略除了其中一些之外的所有 exe 文件，你可以使用“！”排除它们。在线条图案的开头，看看这个
TL;DR：我认为这里有一个关于 tracked 意味着什么的关键见解
在我最初的回答和下面的大量讨论之间，我意识到了一些我认为是 non-obvious 的事情。当我第一次使用 Git 时，这对我来说当然不是很明显（可能几个月甚至几年）。这里有两部分：
在Git中，tracked表示在索引中
但是，索引（您将进行的下一次提交）更改 每次您签出一些特定的提交，包括
git checkout otherbranch，因为实例.
这意味着文件是否被跟踪是相对的，不是绝对的。文件 F 可能在 git checkout branch1 之后被跟踪，然后在 git checkout branch2 之后被取消跟踪。它可能在分支 master 上的过去提交中被跟踪，现在在分支 master 上未被跟踪。如果文件未被跟踪 和 都被忽略，但是 过去被 跟踪并且 是 当前被跟踪work-tree，可能很难弄清楚发生了什么。该文件不会出现在新的克隆中，即使它在历史记录中也是如此。
（原始的，完整的答案在此处的行下方。）
However, when I clone my respository, the
.exefiles are not fetched.
git clone 操作不获取 任何 文件。相反，它获取 commits. 现在，提交确实包含文件，所以这可能看起来像是一种毫无意义的迂腐，但它是你的问题的核心，事实上几乎所有Git，所以它真的很重要。 Git 不关心 文件； Git 只关心提交。
提交本身形成了历史。每个提交都包含一些文件集，但也有一个 back-pointer 到前一个提交："This is what we have now. This is the hash ID of the commit we had before." 我们称之为提交的 parent。 parent 提交也有自己的 parent。此 backwards-looking 链 是 存储库中的历史记录。
像master这样的分支名称是Git记录该分支的当前哈希ID的方式。 Git 从这里开始，在最近一次提交时，使用分支名称；然后 Git 在需要时向后工作，获取较旧的 (parent) 提交并根据要求转到 still-older（大 parent、great-grandparent 等）提交。
运行 git clone 复制分支名称及其提交，以及该提交的 parent 和 parent 的 parent，等等在;这样你就可以得到所有的历史。每个提交都带有与该提交一起存储的文件，因此一旦您拥有所有提交，您不仅拥有所有 current 文件，而且还拥有所有 以前的当前 parent-commit 个文件，以及每个更早的文件一直回到第一次提交。但是所有这些文件都隐藏在一个秘密中，Git-only 格式除了 Git 对任何东西都没有好处。不过，这就是 git clone 份。
当然，要使 Git 真正发挥作用，我们需要某种 actually-useful 形式的文件。所以 Git 向这个提交历史添加了一些东西——但它不是被 克隆的东西； 这就是你的问题所在。
存储库中有什么
在有用的（即非--bare）存储库中，我们不仅需要所有提交和各种分支名称来记住它们的most-recent哈希 ID，我们还需要一个 work-tree。 work-tree 是我们可以处理实际文件的地方。它们以树状结构排列，包含顶级文件和目录，以及目录中的更多文件和 sub-directories，根据需要。 （因此得名 "work tree"：它是 working-form 个文件的树。）
Git 还抛出另一个东西 Git 调用 index。索引的简短描述是它是您构建 next 提交的地方。如果您从不对自己的存储库进行任何更改，那么该索引只会妨碍您，但 Git 仍然会迫使您了解它。如果你做修改，索引很关键，因为修改的方式就是修改work-tree里面的东西，那么使用 git add 将这些修改复制回索引，以便它们 暂存 用于下一次提交。当您然后 运行 git commit 进行 new 提交时，Git 复制索引 now[=257= 中的任何内容]——也就是说，之前所有的旧东西，除了你用 git adding 新东西替换的东西——到新提交中。
了解这一点非常重要：索引跟踪 work-tree 中的内容。 事实上，这正是 "tracked" 的含义：tracked表示在索引中。但是索引也是下一次提交中的内容，因此它开始匹配 当前提交中的内容 .
您可以——通常 ——在 work-tree 中拥有 delib 文件率 未 跟踪。例如，您的 *.exe 文件是故意未跟踪的。未被跟踪意味着它们不在索引中。这意味着它们也不在当前提交中，1现在我们可以看到会有问题。
1即它们不在当前提交中除非索引为"dirty"因此需要写出一个新的提交。同样，这就是您首先进行新提交的方式：修改 work-tree 中的内容——例如修改文件，或添加 all-new 文件，或删除现有文件——然后复制那些 "dirty" work-tree 文件进入索引，"dirtying" 索引。然后你 git commit 进行 new 提交。新提交的 parent 是当前提交的内容，其文件是索引中的任何内容。 Git 然后将新提交的哈希 ID 写入分支名称，新提交现在是历史的一部分，将永远保存。
异议："I can find the blob"
你提到过：
I can find the blob corresponding to the latest checkin in the bare repository:
MyProject.git/objects/41/2fd58b5a11bf6a40f661109e71f2c0026c1643
这意味着文件已在某个时候提交。它在一些历史 提交中。这并不意味着该文件在 最近的 提交中 master 之类的分支上。存储库以 Git-only 内部（压缩 object）格式，every version of every file ever committed。而且，您可以并且经常在您的 work-tree 中拥有一个不在索引中且不在当前提交中的文件。该文件可能与您过去提交的文件很匹配。
因此，文件存在于 存储库 中并不意味着它位于某个特定分支的最新 commit 中。这确实意味着您可以提取历史文件。例如，鉴于上述情况，您可以：
git show 412fd58b5a11bf6a40f661109e71f2c0026c1643 > foo.exe
随时解压到foo.exe。如果您知道提交哈希和路径，您也可以使用它：
git show 1234567:path/to/foo.exe > foo.exe
如果提交有一个名称（例如分支或标签名称）：
git show name:path/to/foo.exe > foo.exe
你可以使用这种方法提取历史文件，但显然有些痛苦。
git clone 在获取所有提交后做了什么
如上所述，git clone 首先复制提交和分支名称。事实上，默认情况下，它将 重命名 这些 branch-names 为 Git 调用的 "remote-tracking branches"。但是，作为它退出之前的最后一步，并称一切正常，ready-to-go、git clone 填写你的 work-tree.
你work-tree里面填的方式是给git checkout某个分支名，一般是master。该分支名称会记住该分支最新提交的哈希 ID。该提交是根据索引进行的，该索引 中没有 .exe 文件。 所以最近的 master 提交 没有里面有 .exe 个文件。
因为这个 work-tree 是全新的，并且被签出的提交中没有 .exe 文件，所以你的新 work-tree 中没有 .exe 文件.这就是他们失踪的原因。
如果那些 .exe 文件 do 存在于存储库中的某些 other 提交中，那么它们就在存储库中，你可以把它们弄出来。你只是不能用简单的方法把它们弄出来：
git checkout master
因为 仅 将为 master 上的最新提交保存的文件提取到索引中，然后再提取到 work-tree 中。
那么 你在哪里得到你的 .exe 文件？
好吧，这部分由您决定。 Git 这里没有 pre-packaged 解决方案。它们可能在您正在克隆的另一个 Git 存储库的 work-tree 中，但是克隆协议中没有任何内容可以获取 work-tree另一个 Git.
处理此问题的一种方法是提交不包含任何内容但最新的.exe文件。然后你可以告诉 Git:
- 提取到我的 work-tree 中，而不提取到索引中，提交中哈希 ID 为
feede3e例如，当然假设该提交具有该哈希 ID。事实证明这出奇地困难，因为 Git 真的 想在将文件复制到 work-tree 之前将提交的文件提取到索引中。将它们放入索引会使它们 tracked，这不是您想要的。当然，首先将那些 .exe 文件提交到提交中需要——好吧，还有什么：等等……你猜到了吗？是的，这需要将那些 .exe 个文件放入索引！
Git 就是不会让你两全其美。要么文件被跟踪，因此它们在索引中，因此它们 do 进入提交；或者它们未被跟踪，所以它们不在索引中，所以它们 不 进入提交。选择一个并坚持下去。如果您愿意，可以使用 git worktree add 或此存储库的单独克隆或完全独立的存储库来创建第二个存储库或 work-tree 使用 不同的 确实的分支跟踪并提交了.exe个文件。事实上，您可能希望此分支或其他存储库仅跟踪和保存 .exe 个文件。然后你可以简单地从那里复制 .exe 文件。
或者，当然，您可以从某个确实有它们的地方获得它们，但是通过 git clone 以外的其他方法。
（ 实际上可以在没有单独的 work-tree 的情况下使用各种 Git 的 管道 命令和一个临时索引，但这相当棘手，而不是 Git 是如何工作的。无论如何，请注意，您需要一个容易记住的名称，例如分支名称这让你 latest 提交 latest .exe 文件。让分支名称记住哈希 ID 的想法，使用提交 object 保存文件，并记住之前的提交 object ...好吧，那是一个 分支 。这就是 Git does: 它保留了记住提交哈希的分支名称，这些哈希记住了从索引中保存的文件。所以你真的 do 想要一个单独的 work-tree 并在更新和提交文件的位置分隔索引。毕竟你真的 不想 在 Git 模型之外工作。）
.gitignore 文件是一条红鲱鱼
.gitignore 中的条目主要做两件事：
它抑制关于未跟踪文件的投诉。如果
foo.exe存在于 work-tree 但不在索引中，因此不会被保存在下一个git commit, Git whines[=257= 】 对着你。它一遍又一遍地告诉你，"Hey,foo.exeis not going to be committed! Remember to addfoo.exeto the index! Don't forgetfoo.exe, or it won't get committed!" 这变得令人讨厌，并且妨碍了你 想要 看到的关于你真正 的文件的投诉]没有忘记了。因此，将foo.exe或*.exe添加到.gitignore可以关闭此投诉。它禁止
foo.exe被git add -a或类似的自动添加。与其手动git add一次将一个文件添加到您的索引，您可以通过提及目录名称、使用--all或使用 [=433= 来大量添加脏 work-tree 文件] 像git add *这样的 glob。如果foo.exe当前未被跟踪 并且 列在.gitignore中，这些实际上不会将foo.exe复制到索引中。甚至git add *也会跳过它，抱怨；git add .或git add -a将毫无怨言地跳过它。
请注意，如果文件 被 跟踪，则在 .gitignore 中列出文件名无效。 .gitignore 中的条目主要是关于防止文件 成为 跟踪，而不是阻止任何已经生效的内容。