在存储库的嵌套文件夹中设置多个.gitignore文件的正确方法

Question

我有以下文件夹结构：

Project/
    .git/
    .gitignore #1
    a/
        a1/
             a2.txt
             a3.txt
        .gitignore #2
    b/
        b1.txt
    c.txt

我想拥有 git 不要忽略 a2.txt ，而不是忽略 B/的全部。其他一切都应忽略。

根据建议/注释/答案提供， .gitignore＃1 的内容是：

a/
c.txt

这实际上忽略了 c.txt 以及文件夹中的所有内容 a/，后者受到不被更深的嵌套 .gitignore 覆盖的约束。

.gitignore＃2 的内容是：

!a1/a2.txt

我希望更深的嵌套 gitignore 文件将导致不忽略文件 a2.txt 。

但是，运行 git状态 - 签名结果：

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        b/

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)
        a/
        c.txt

nothing added to commit but untracked files present (use "git add" to track)

即，尽管我希望我希望通过提供 a/的整体似乎被忽略了.gitignore＃2 。

如何正确地使用嵌套 .gitignore 的？

（注意：我仅命名了 .gitignore 在上面的描述中为＃1 和＃2 以澄清两个。

Answer 1

这里的一般规则是：

• GIT将使用操作系统的设施读取目录。
• 要扫描目录，git调用和关联的 readdir （以及最终 nocleir ）功能。
• readdir 然后返回目录条目一次。每个条目都保留了以下定义的A 名称组件。条目 May 还保留其他信息，尤其是目录与文件区别，但这与Git一样多，可以真正依靠此处。如果操作系统填充 d_type 带有 dt_dir ， dt_file 等。回到调用 lstat （这很昂贵）。

阅读了整个目录后，Git现在具有一组名称组件。 a name component 基本上是斜线之间的路径名的一部分：路径，<代码> 和 file.ext 。请注意，对于/path/to/file.ext ：领先的斜线仅表示“从顶部”而不是“从我们在树上的任何地方”而言，这也是如此。 git可以使用相同的想法（相当奇特）的使用 - 从斜线开始的路径是“ root相对”，其余的是“当前位置相对”，当使用 .gitignore中的“锚定”条目文件（请参见下文）。因此，如果 path/to/file 存在于工作树的顶层中，则git在扫描顶级目录时仅会看到 path 零件。

（旁注：POSIX还包括 scandir < /a>，但人们发现此接口很难正确使用。 git使用 readdir 。）

现在，Git具有名称组件，Git可以根据该特定级别的 .gitignore （如果存在）检查它们。它还可以将每个组件与任何领先的路径名相结合，这些路径名首先在这里获得git。 对于初始扫描没有这样的领先组件，也不会发生组合，但是让我们在下面观察如果允许我们进入 path/（这是目录）。

现在，组件可能需要A 类型检查：文件与目录。 .REAL-WORLD文件系统可能具有其他类型，包括符号链接，但就我们的目的而言，符号链接 目前将被视为文件。我们只想知道组件是否代表目录。

现在，我们到目前为止已阅读的任何 .gitignore 文件中的条目 - 包括我们现在正在阅读的 this 目录中的一个条目 - 以三种独立的方式标记：

• < p>有些是锚定，例如/path/to 或 a/b ，而有些则不是，例如 in *.o 例如。 锚定条目是一个包含任何斜线后 删除单个尾随的斜线。

• 有些仅适用于目录，而有些则用于所有名称。如果条目以直接斜线结束，则将其标记为仅目录。 （由于尾斜线是“仅目录”标志的意思，因此在决定是否设置“锚定”标志时必须忽略它。）

• 。 （“不要忽略”）条目。负面条目是以！作为第一个字符开始的条目。 （/path 的锚定负条目必须读取！/path ; /！路径在这里不起作用。）

因此，让我们想象一下我们正在阅读最高级别，或者我们正在读取目录 path 在顶级。假设我们在此级别上遇到两个名称组件： path ， to 。现在，我们或多或少同时检查所有这些内容（按顺序，“最后一个条目”覆盖）：

• 检查目录条目本身本身忽略表达式。 路径是否适合其中任何一个？如果是这样，则根据正/负标志忽略/Unigning。

• 检查到到目前为止的完整路径 针对所有锚定忽略表达式。对于路径这是/path ，/path/path/path ，或/to/path ;对于到，这是/to 或/path/to 或/to/to/to/to/to 之一。 （请记住，我们同时找到了/path 和/to ，并且大概是我们在内部都在内部。表达式，根据正/负标志对此名称被忽略/无标记。

请注意，当我们 do 检查锚固路径时，我们正在查看工作树中的完整路径，而 .gitignore 本身可能来自内部的子路径 .gitignore 树。因此，如果我们正在读取目录/path 例如，我们有/path/.gitignore ，并且它具有锚定的条目读取/xyzzy ，我们真的在检查此/Xyzzy 针对/path/xyzzy （因为它来自/path/.gitignore ，而不是/ .gitignore ）。这有点复杂，但是一旦考虑一下它是有道理的：锚是相对于 .gitignore 的位置。这使您可以重命名目录，而无需在任何子 .gitignore 文件中编辑所有锚定路径。

进一步注意，“是匹配”测试可能要求目录条目本身名称为目录。如果忽略条目被标记为仅目录，则是这种情况。因此，要检查这一点，我们需要知道输入是否是 path 或 to 例如 - 将OS文件系统中的目录命名为“名称”。

在这一点上，我们已经完成了所有必须在此上进行的检查。它要么匹配一些 .gitignore 条目或条目，在这种情况下， last 匹配的 .gitignore 是摄取的，或者未进行。并且，subdirectory .gitignore s稍后在链条中匹配，因此最深 .gitignore 可以匹配如果具有匹配项，则此条目将始终具有Last 匹配。

如果此条目与任何 .gitignore 规则不匹配，则此特定名称是不忽略的。如果它 did 匹配 .gitignore 规则，则最后一个人的正/负标志确定该特定名称是否被忽略。

现在我们知道该名称是否被忽略，我们有两个选项，每个选项都有两个子选项：

• 它被忽略：

  • 如果是目录，我们根本不扫描它。
  • 如果是 file ，我们不自动添加文件（使用 git add。实例）或 git状态，我们不抱怨 未跟踪文件（假设它实际上是未跟踪的）。

  
  

  
  

• 不忽略它：

  • 如果是目录，我们会递归扫描并应用所有这些规则。
  • 如果是 file ，我们 git add it（对于 git add。添加。 git状态）。

  


  


这确定 git状态是否抱怨它是未经跟踪的（ git状态命令），还是 git git add 某种递归风味（ git add - all ， git add。， git add add somedir 等）添加了它。

请注意，您可以使用 git add-force ，例如， git add add-force忽略 - 忽略f-file 添加它，即使忽略忽略代码>将被普通 .gitignore 规则忽略。我从未尝试过 git add -force。查看这里会发生什么，但这可能不好。