gitignore规则（应用于codeigniter堆栈） [英] gitignore rules (applied to a codeigniter stack)

问题描述

我正在将CodeIgniter网站添加到新的存储库中（作为初始添加-存储库当前为空）。

I'm adding a CodeIgniter website into a new repo (as an initial add - the repo is currently empty).

我已将 application 和 system 目录，以及 index.php 从CodeIgniter根目录进入子目录 www 。我想忽略在 application\config中创建的开发和生产目录。 https://www.gitignore.io/?templates=codeigniter 使用 * / config / development / * ;

I've moved the application and system directories, and index.php from the CodeIgniter root into a subdirectory, www. I wanted to ignore the development and production directories I'd created in application\config. https://www.gitignore.io/?templates=codeigniter uses */config/development/*; this didn't work for me, but

**/config/development/*

did，这导致了许多问题：

did, which has led to a number of questions:

我正确地认为 * / 仅在 * / config / development / * 开头

1. 如果是这样，gitignore.io包括 * / 而不是显式使用`/的可能原因是什么？ application / config / development / *'？


2. 因为（？）我已将应用程序移至子文件夹，我发现需要更改 * / config / development / * 到 ** / config / development / *
   
   
   
   
   • 但是， https://stackoverflow.com/a/41761521/889604 表示 ** / 是多余的，但是当我尝试将其更改为 config / development / * 时，仍然添加了文件。当目录与.gitignore位于同一目录中时，是否只需要排除 * [*] / ？
   
   

1. am I right in thinking that the */ at the beginning of */config/development/* only refers to any immediate subfolder?
2. If so, what's the likely rational for gitignore.io including */ instead of explicitly using `/application/config/development/*'?
3. Because(?) I'd moved application to a subfolder, I found that I needed to change */config/development/* to **/config/development/*
   • however, https://stackoverflow.com/a/41761521/889604 implies that **/ is redundant but when I tried changing it to config/development/* the files were still added. Do you only need to exclude *[*]/ when the directory is in the same directory as the .gitignore?

推荐答案

TL; DR

在 .gitignore 中，带有前导或嵌入式斜杠的模式会得到特殊处理。它们不同于没有前导或嵌入斜杠的模式。因此，由于两个嵌入式斜杠，您可能需要 ** / config / development / * 。

TL;DR

In a .gitignore, patterns with leading or embedded slashes are treated specially. They are different from patterns that have no leading or embedded slash. So you may need **/config/development/* here because of the two embedded slashes.

要按顺序回答您的问题：

To answer your questions in order:

1. 是。

1. Yes.

您必须问问谁写了那些忽略文件。

You'll have to ask whoever wrote those ignore files.

注释中，中的假设是前导星号 ** / .gitignore路径匹配语法是否多余？是错误的；

这里最后一项的解释似乎很合适。

An explanation of this last item seems appropriate here.

由于没有明显的原因，Git决定是否使用 .gitignore 模式与在某些目录树行走期间发现的特殊文件名相匹配。如果图案没有没有嵌入斜杠，则将以一种方式处理。如果确实有一个嵌入式斜杠，则将其视为另一种第二种方式。要真正理解这一点，我们需要定义一些术语。

For no obvious reason, Git's rule about whether a .gitignore pattern matches some file name found during some directory-tree-walk has a peculiar wrinkle. If a pattern does not have an embedded slash, it's treated one way. If it does have an embedded slash, it's treated a different, second way. To really understand this, we need to define a few terms.

作为副注，在谈论这些内容时，我倾向于喜欢 directory 一词。操作系统提供的实体。如果您更喜欢用 folder 这个术语，则可以在精神上代替它-它们本质上是同一件事。但是，如果您熟悉C或Python或相关语言，就会了解 opendir 和/或 readdir 和/或 os.listdir ，以及 os.walk 之类的功能，其中大多数还使用目录一词来描述这些东西。

As a side note, I tend to like the term directory when talking about the OS-provided entities. If you prefer the term folder, you can substitute that in mentally—they're essentially the same thing. If you're familiar with C or Python or related languages, though, you'll know about opendir and/or readdir and/or os.listdir, and functions like os.walk, most of which also use the word "directory" to describe these things.

让我们从开始。 gitignore 条目，它们由扩展的glob模式组成。在此Wikipedia页面上，很好地定义了 glob模式一词，但我们可以使用更多。

Let's start with the .gitignore entries, which are made up of extended glob patterns. The term glob pattern is pretty well defined at this Wikipedia page, but we could use a bit more.

最基本的glob形式只有 * ，？和 [...] 元字符。单个问号与文件名中的一个字符匹配。星号可匹配任意数量的字符（包括零个字符），方括号字符串可匹配括号内的任何字符。 ¹ 请注意，这种简单的基本glob仅适用于文件在一个目录中。无论哪个实体正在使用这种glob，该实体都可能会从实际目录中读取文件名列表，然后从该目录中选择与该glob表达式匹配的文件名。

The most basic form of glob just has *, ?, and [...] meta-characters. A single question mark matches one character in a file name. An asterisk matches any number of characters (including zero characters), and a square-bracketed string matches any of the characters inside the brackets.¹ Note that this kind of simple, basic glob is applied only to files within a single directory. Whatever entity is working with this kind of glob, that entity reads a list of file names—probably from an actual directory—and then selects those names within that directory that match that glob expression.

很显然，下一步是将目录添加到这种简单的glob。例如，我们可以写 dir / * 来表示名为 dir 。这不是很复杂，尽管它提出了一个最简单的情况我们忽略的问题：全局模式是否匹配目录名称？也就是说，如果 dir / sub 本身是目录怎么办？ dir / * 匹配吗？因此， * 是否匹配 dir ？通常的答案是，是的，这确实匹配，并且只要我们坚持使用 dir / * ，这仅意味着 dir / sub 被匹配（作为目录）。

Obviously, the next level up is to add directories to this kind of simple glob. For instance, we might write dir/* to mean all files within the directory named dir. This is not very complicated, though it brings up a question we ignored with the simplest case: does a glob pattern match a directory name? That is, what if dir/sub is itself a directory—does dir/* match it? For that matter, does * match dir? The typical answer is that, yes, this does match, and as long as we're sticking with dir/* that just means that dir/sub gets matched (as a directory).

扩展的glob差异很大。 Bash具有自己的特殊扩展glob语法， globstar 启用 ** 和 extglob 启用更多功能。 ** 本身的含义是不同的：某些实现要求它至少匹配一个目录，但允许任意数量的目录级别。其他实现允许 ** 匹配 no 目录，以便 ** / sub 匹配 dir / sub ，但也只是普通的 sub 。根据 ** 在很大程度上表现出这种最后的方式：它匹配零个或多个目录。 rel = nofollow noreferrer> gitignore文档。

Extended globs vary a lot. Bash has its own special extended glob syntax, using globstar to enable ** and extglob to enable even more. What ** itself means varies: some implementations require it to match at least one directory, but allow any number of directory levels. Other implementations allow ** to match no directories, so that **/sub matches dir/sub but also just plain sub. Git's ** largely behaves this last way: it matches zero or more directories, according to the gitignore documentation.

¹ 注意尽管有相似之处，但通配符模式与正则表达式根本不同，通常。表示任何单个字符，等同于？和 * 是后缀 operator ，表示以前的零或多个。因此，在正则表达式中，。* 表示任何字符的零个或多个。回覆。方括号通常允许范围和取反，例如[ ^ az] 表示 a not c $ c>到 z ，而Shell Glob模式通常只允许范围。

¹Note that despite the resemblance, glob patterns are not at all the same as regular expressions, where typically . means any single character—the equivalent of ? in glob—and * is a suffix operator, meaning zero-or-more of whatever came before. Hence in regular expressions, .* means zero-or-more of any character. R.E. square brackets usually allow for both ranges and inversion, e.g., [^a-z] means anything not in a through z, while shell glob patterns usually allow only ranges.

重要的是，Git不在乎目录。特别是，Git提交存储文件 ，而不是存储目录中的文件。这些文件仅具有看起来的路径名，它们占据目录。操作系统要求目录 dir 存在，以便 dir / sub 可以存在。反过来， dir / sub 必须是目录，以便 dir / sub / file 可以存在。但是就Git而言，Git只需要存储内容就可以进入一个名为 dir / sub / file 的文件。当需要将该内容写入该文件时，Git会简单地 create dir 和 dir / sub （如果需要的话），当时。目录的存在与否无关紧要。

In an important way, Git doesn't care about directories. In particular, Git commits store files, rather than storing directories full of files. The files simply have path names that look like they occupy directories. The OS demands that the directory dir exist, so that dir/sub can exist; dir/sub in turn must be a directory so that dir/sub/file can exist. But as far as Git is concerned, Git just needs to store content to go into a file that will be named dir/sub/file. When it comes time to write that content into that file, Git will simply create dir and dir/sub if needed, at that time. The presence or absence of the directories is irrelevant.

这就是为什么您不能在Git存储库中存储空目录的原因：Git存储文件的内容每次提交中 file 名称下的。没有文件，没有什么可存储的，因此提交中不存在空目录。

This is why you can't store an empty directory in a Git repository: Git stores the contents of files under file names in each commit. With no files, there's nothing to store, so empty directories just are not present in a commit.

尽管如此，而Git仅存储文件， Git必须使用操作系统提供的目录读取服务才能查找已放入工作树的文件。然后，Git会将这些文件（或更准确地说，是与它们的（完整）名称相关的内容，例如 dir / sub / file ）复制到Git的 index 当您准备新提交时。索引包含每个文件的名称，模式（ 100644 或 100755 ）以及Git内容的哈希ID 。这就是您所做的下一个提交的内容。 （当您 git checkout 一些现有提交时，Git将从该提交中填充索引，以便该索引最初与该提交匹配。）

Nonetheless, while Git stores only files, Git must use the OS-provided directory reading services in order to find the files you have put into your work-tree. Git will then copy those files—or more precisely, their contents, associated with their (full) names such as dir/sub/file, into Git's index when you prepare a new commit. The index holds each file's name, mode (100644 or 100755), and the hash ID of the Git-ified content. That's what will go into the next commit you make. (When you git checkout some existing commit, Git fills the index from that commit, so that the index initially matches the commit.)

正如我们刚刚看到的，Git必须打开并读取工作树中的每个目录，从目录的顶层开始工作树本身。调用 os.listdir （Python）或 opendir 和 readdir （C）是名称列表：Git刚刚告诉OS枚举的目录中的文件和子目录名称。要做更多的工作（调用 lstat ）可以获得所需的其余信息，现在Git知道名称 dir

As we just saw, Git has to open and read each directory in your work-tree, starting with the top level of the work-tree itself. The results of calling os.listdir (Python) or opendir and readdir (C) is a list of names: file and sub-directory names within the directory that Git just told the OS to enumerate. A bit more work (calling lstat) gets the rest of the information required, and now Git knows whether the name dir refers to an ordinary file, or to a directory.

给出目录的名称，Git通常必须打开并阅读该目录也是如此。因此，Git将打开并读取 dir 并找到名称 sub ，然后发现 sub 是一个目录。然后，Git将打开并读取 dir / sub ，并找到名称 file 和该 file 命名文件。递归地打开和读取目​​录中的每个目录的过程称为遍历目录树。例如，这就是Python os.walk 函数的作用。

Given the name of a directory, Git is generally going to have to open and read that directory as well. So Git will open and read dir and find the name sub, and discover that sub is a directory. Git will then open and read dir/sub and find the name file, and that file names a file. This process of opening and reading, recursively, each directory within a directory, is called walking the directory tree. That's what the Python os.walk function does, for instance.

标准C没有用于行走的函数一棵树，所以Git照原样手工实现了这一切。片刻之间的关系开始变得很重要，但是现在，以这种方式来思考：通过走树，Git在存储库中找到 all 目录和 all 文件。缺少 .gitignore 时，Git丢弃所有目录名称，保留所有文件名（使用从顶部开始的完整路径），然后至少对 all添加操作，将所有这些名称和更新的内容放入索引中，为下一次提交做好准备。

Standard C does not have a function for walking a tree, so Git implements it all by hand, as it were. This starts to matter in a moment, but for now, think of it this way: by walking the tree, Git finds all the directories and all the files in the repository. Absent .gitignore, Git throws away all the directory names, keeps all the file names—using their full paths from the top—and then, at least for an "all" add operation, puts all those names and updated contents into the index, ready for the next commit.

对此有几点了解：

• 步行过程本质上是递归的。也就是说，找到目录后，我们必须打开并读取目录，并处理每个条目。如果条目本身是目录，则必须打开并读取那个目录，依此类推。

同时，每个条目<目录中的em>只是一个名称：我们（或Git）必须随行组装 path 。如果我们正在使用 dir 并遇到 sub ，则全名现在为 dir / sub 。如果我们正在处理 dir / sub 并遇到 file ，则全名现在为 dir / sub / file 。但是 dir 仅列出 sub ，而 sub 本身仅列出文件。

Meanwhile, each entry in a directory is just a name: we—or Git—must assemble the path as we go. If we're working on dir and come across sub, the full name is now dir/sub. If we're working on dir/sub and come across file, the full name is now dir/sub/file. But dir just lists sub, and sub itself just lists file. It's up to us / Git to remember the path.

相对而言，步行过程缓慢。 Git希望更快！

The walking process is slow, relatively speaking. Git wants to be fast!

所有这些都在中引入了一些复杂性。 规则。

在顶层，您可以有一个非常简单的 .gitignore 文件：

At the top level you can have a very simple .gitignore file:

# ignore files named *.o and *.pyc
*.o
*.pyc

$ b的文件
$ b

现在，Git可以浏览您的工作树，在目录的每个级别中查找文件。如果文件名（在该目录中以任意级别表示）与任何这些简单的全局模式匹配，并且该文件的完整路径名都没有在索引中，则Git会假装文件不存在：不会自动添加，并且 git status 不会抱怨该文件未被跟踪。

Now Git can walk through your work-tree, finding files in each level of directory. If the file's name—as expressed in that directory, at whatever level—matches any of these simple glob patterns, and the full path name of that file is not already in the index, Git will pretend that the file does not exist: it won't get automatically added, and git status won't complain about it being untracked.

但是如果我们想防止文件 dir / foo 和 dir / sub / foo 进入该怎么办？顶层，而又不能防范 foo 呢？然后我们可以告诉Git：仅忽略 dir 中的 foo 。一种简单的表达方式：创建文件 dir / .gitignore 。通过阅读 dir 或其任何子目录找到位于此处的文件名时，它们将被忽略：

But what if we want to prevent the file dir/foo and dir/sub/foo from going into the top level, while not protecting against foo in the top level? Then we can tell Git: only ignore foo when it's contained within in dir. There is an easy way to express this: create the file dir/.gitignore. File names listed here are ignored when they're found by reading dir or any of its sub-directories:

.gitignore:
    *.o
    *.pyc
dir/.gitignore:
    foo

现在，在步行过程中，当Git打开并读取 dir ，它会发现有一个 dir / .gitignore 。它将规则应用于此遍历遍历期间找到的所有文件：它们适用于 dir 中的文件和 dir / sub ，但不存储在顶层文件中，也不能存储在顶层 other / 目录中，也不能存储在其中。

Now, during the walk, when Git opens and reads dir, it notices that there is a dir/.gitignore. It applies the rules there to all files found during this recursive traversal: they apply to files in dir and files in dir/sub, but not to files in the top level, nor—if there's a top level other/ directory, to files in there either.

但是如果我们只想忽略 怎么办dir / foo ，而不是 dir / sub / foo ，而不是 other / foo 或 / foo ？现在我们遇到了另一个问题，Git提供了两个解决方案。其中之一是将 / foo 写入 dir / .gitignore 中的条目：

But what if we want to ignore only dir/foo, not dir/sub/foo, and not other/foo or /foo? Now we have a different problem, and Git provides two solutions. One of them is to write /foo as the entry in dir/.gitignore:

.gitignore:
    *.o
    *.pyc
dir/.gitignore:
    /foo

这仅忽略 dir / foo ，而不会忽略 dir / sub / foo 。它包含一个斜杠，告诉Git：不要将其应用于子目录。

This ignores only dir/foo, not dir/sub/foo. It contains a leading slash, which tells Git: Don't apply this to sub-directories.

另一种表达方式是进入顶层 .gitignore 的权限，从而完全不需要 dir / .gitignore ：

Another way to express this is to put this right into the top level .gitignore, which removes the need to have a dir/.gitignore at all:

*.o
*.pyc
dir/foo

其中包含一个嵌入式斜杠。当Git进行目录遍历时，它自然会找到去除路径路径的文件名-查找 foo ，而不是 dir / foo ，在通过 dir 时在 dir 内。因此，这种模式是单独处理的，在之后加上完整的路径名。

This contains an embedded slash. When Git is doing a directory walk, it naturally finds file names stripped of their paths—it finds foo, not dir/foo, inside dir when walking through dir. So this kind of pattern is handled separately, after putting together the full path name.

因此，这是前两个特殊内容的来源 .gitignore 文件中名称或模式斜杠的规则：

So, this is the source of the first two special rules about slashes in names or patterns in .gitignore files:

• 前导斜杠表示仅匹配此名称或此目录中的简单glob 。


• 嵌入式斜线表示仅匹配此完整路径名或相对于（扩展）的glob

• A leading slash means match only this name or simple glob in this directory.
• An embedded slash means match only this full path name or (extended) glob relative to this directory.

请注意，第二种情况涵盖了第一种情况：两种都可以正常工作，仅匹配<一旦将相对路径名放在一起（即，在 sub 的 foo 转换为 dir / sub / foo ）。但我们需要第一种情况，因为裸名称或全局模式，例如 foo 或 *。pyc ，将应用于该目录及其所有子目录。我们可以通过上移至顶层并直接忽略 dir / foo 来处理 dir / foo ，但是如果我们愿意忽略 / bar 而不忽略 dir / bar 和 dir / sub / bar ，此路径只有顶层 .gitignore 。

Note that the second case covers the first one: both will work correctly, matching only paths within this directory, once the relative path names are put together (i.e., after sub's foo is turned into dir/sub/foo). But we need the first case because a bare name or glob pattern, such as foo or *.pyc, would apply to this directory and all of its sub-directories. We could handle dir/foo by moving up to the top level and ignoring dir/foo directly, but if we want to ignore /bar without ignoring dir/bar and dir/sub/bar, we have only the top level .gitignore for this path.

这意味着您可以调用全路径匹配，即相对于 .gitignore 本身所在目录的完整，使用前导斜线，嵌入式斜线或两者兼而有之。通常，如果您创建的 .gitignore 文件尽可能靠近该文件，则需要使用斜杠规则。如果使用更高级别的 .gitignore 文件，则嵌入式斜杠规则就足够了。

This means you can invoke the full-path match—well, "full" relative to the directory in which the .gitignore itself lives—using a leading slash, an embedded slash, or both. In general, if you create the .gitignore file as close as possible to the file, you'll need the leading slash rule. If you use higher level .gitignore files, the embedded-slash rule suffices.

（嵌入式斜杠规则可能gitignore文档中的措辞表明 dir / sub 的意思是忽略 a / dir / sub ，并且您必须将 / dir / sub 写入 not 忽略 a / dir / sub 。但是测试表明它的行为符合我在此处描述的方式：

(The embedded slash rule might actually be a bug. The wording in the gitignore documentation suggests that dir/sub is meant to ignore a/dir/sub as well, and that you would have to write /dir/sub to not ignore a/dir/sub. But testing shows that it behaves the way I describe here:

$ git status -s -uall
?? a/dir/sub/file2
?? dir/sub/file
$ echo dir/sub > .gitignore
$ git status -s -uall
?? .gitignore
?? a/dir/sub/file2
$ git --version
git version 2.20.1

请注意，忽略 dir / sub 会生成 file 消失了，但 a / dir / sub / file2 仍然备受抱怨。）

Note that ignoring dir/sub made file disappear, but a/dir/sub/file2 remains complained-about.)

请记住，相对而言，我们说树步很慢。在工作树中，我们故意在其中添加一个完整的供应商SDK或其他打包的东西-Git存储库是很常见的-可以从存储库中作为一个单独的tarball提取，或者可以完全用Git之外的某种方法提取-从来没有想要从这个打包的东西中提交任何文件，无论它是什么。一旦取消存档，让Git遍历该程序包的每个级别只是在浪费时间。

Remember that we said that the tree-walk is slow, relatively speaking. It's pretty common to find a Git repository where, in the work-tree, we deliberately add an entire vendor SDK or other packaged thing—maybe taken from the repository as a single tarball, or maybe extracted in some method outside Git entirely—and never want to commit any of the files from inside this packaged thing, whatever it is. Having Git walk through every level of that package, once it's unarchived, is just a waste of time.

为此，如果Git还没有索引条目例如，列出 dir / sub / vendor / file ，并且-在其通过目录树的所有过程中-遍历名为 vendor的目录在 dir / sub 中，您可以告诉Git：不要打扰看看这个 vendor / 表示这种情况的一种方法是使用我们已经知道的内容：

To this end, if Git doens't already have an index entry listing, say, dir/sub/vendor/file, and—during one of its ambles through directory trees—comes across the directory named vendor in dir/sub, you can tell Git: Don't bother to look inside this vendor/ directory at all. One way to express this is to use what we already know:

.gitignore:
    *.o
    *.pyc
    dir/sub/vendor

或：

.gitignore:
    *.o
    *.pyc
dir/sub/.gitignore:
    /vendor

我们已经知道领先的斜杠是什么是在这里：它确保我们只忽略 dir / sub 中的供应商。顶层 .gitignore 也是如此。

We already know what the leading slash is for here: it makes sure we only ignore vendor in dir/sub. That's also already the case for the top level .gitignore.

但是，如果我们想跳过所有名为 vendor 的目录，而不会跳过任何名为 vendor 的文件 / code>？在这里，我们可以使用 trailing 斜杠语法：

However, what if we want to skip all directories named vendor, without skipping any files named vendor? Here, we can use the trailing slash syntax:

.gitignore:
    *.o
    *.pyc
    vendor/

此 vendor / 在某些方面看起来像 dir / sub 。但是这里的斜线不是嵌入，而是后缀。因此，此斜杠不会打开仅全路径代码。相反，它告诉Git：在树上行走时，遇到名为 vendor 的东西，并且它是目录时，不要后面的斜杠首先从该字符串中删除 ，剩下的 vendor 是匹配项。它既没有前导斜线，也没有嵌入的斜线，因此它可以在本次遍历的任何子级别进行匹配-但实际上确实有尾随的斜杠，因此，如果实际使用的是 在树中是目录。

This vendor/ looks like dir/sub in some ways. But the slash here is not embedded, it's trailing. So this slash does not turn on the full-path-only code. Instead, it tells Git: During your tree-walk, when you come across something named vendor, and it's a directory, don't bother recursing into it. The trailing slash is first removed from this string, leaving vendor is the item to match. That has neither a leading slash, nor an embedded one, so it's matched at any sub-level of this level of the walk—but it does actually have a trailing slash, so it's matched only if what's actually in the tree is a directory.

当然，我们也可以说供应商或 v * r 或其他与供应商匹配的东西，如果我们愿意忽略文件好。或者，如果我们要忽略所有基名（没有完整路径的部分）匹配 v * r的目录，则可以编写 v * r / 。

Of course, we can also just say vendor, or v*r, or any other thing that matches vendor, if we're willing to ignore files as well. Or we can write v*r/ if we want to ignore all directories whose base-name—the part without the full path—matches v*r.

.gitignore 中任何以开头的条目！会覆盖先前也与此条目匹配的忽略规则。但是请注意，为使这种情况发生， Git需要在其遍历过程中打开并读取目录。如果较早的忽略规则允许Git忽略目录，则Git在树遍历阶段执行 。

Any entry in .gitignore that starts with ! overrides a previous ignore rule that also matched this entry. Note, however, for this to occur, Git needs to have opened and read the directory during its tree-walk. If an earlier ignore rule allows Git to ignore a directory, Git does that during the tree-walk phase.

也就是说，如果有任何规则在任何时候与供应商匹配，并且该规则说请忽略此和 vendor 是一个目录，Git 不会打开 vendor 并读取其内容。它不会看到 供应商/文件1 ，供应商/文件2 ，依此类推。这些名称绝不会以我们应该忽略此名称显微镜的形式出现，无论是以其基本名称 file1 格式还是以其 dir / sub / vendor / file1 全路径格式。

That is, if there's any rule that matches vendor at any point, and that rule says do ignore this, and vendor is a directory, Git won't open vendor and read its contents. It won't see vendor/file1, vendor/file2, and so on. Those names will never be brought under the should we ignore this name microscope, neither in their base-name file1 format, nor in their dir/sub/vendor/file1 full-path format.

• 前导斜杠具有锚定效果。锚点与 .gitignore 文件位于同一级别。 （如果忽略文件位于工作树之外，例如位于 $ HOME / .gitignore 或 .git / info / exclude （锚定级别是工作树的顶层。）

• A leading slash has an anchoring effect. The anchor is at the same level as the .gitignore file. (If the ignore file is outside the work-tree—e.g., is in $HOME/.gitignore or .git/info/exclude—the anchoring level is the top level of the work-tree.)

嵌入式斜杠（但不是尾随的斜杠）打开锚定尽管文档含糊地暗示了其他暗示，但效果也是如此。这可能是一个错误，但是Git在许多发行版中的行为方式都是一致的（所以也许是 documentation 错误）。

Embedded slashes—but not a trailing slash—turn on the anchoring effect too, despite the documentation's vague implied hint otherwise. This might be a bug, but Git has behaved this way consistently through many releases (so maybe it's a documentation bug).

双星全局匹配（ ** /任何）包含一个嵌入式斜杠，几乎是按定义的。没有嵌入斜线的唯一两个双星球是 ** / 和 ** ，两者都不这很可能会在实践中使用。内嵌的斜杠锚定名称，但双星号在此处允许零个或多个目录级别，因此锚定没有抑制作用。如果您想要这种自由浮动的匹配行为，而没有前导 ** / 的名称也会 ，则需要前导双星em>包含一个嵌入式斜杠。

Double-star glob matching (**/whatever) contains an embedded slash, almost by definition. The only two double-star globs that do not have an embedded slash are **/ and **, neither of which is likely to be used in practice. Embedded slashes anchor names, but the double-star allows zero or more directory levels here, so that the anchoring has no inhibitory effect. The leading double-star is required if you want this kind of free-floating match behavior on a name that, without the leading **/, would also contain an embedded slash.

不可忽略的规则要求Git打开并读取目录。如果要取消忽略目录树深处的某个文件，则不希望忽略其中的任何包含目录，或者希望发现某些内容迫使Git扫描深层子目录。也就是说，如果您有一个名为 long / path / to / important / file 的文件，并且希望将那个文件存储在每次提交中，您需要该名称进入Git的索引，以便Git将其存储在下一次提交中。

Un-ignore rules require that Git open and read a directory. If you want to un-ignore some file deep in the directory tree, you want none of its containing directories to be ignored, or to find that something forces Git to scan the deep subdirectory. That is, if you have a file named long/path/to/important/file and you want that file to be stored in each commit, you'll need that name to get into Git's index, so that Git will store it in the next commit.

根据定义，索引中存在的值不会被忽略。忽略条目仅适用于索引中没有但位于工作树中的文件。

Files that exist in the index are, by definition, not ignored. Ignore entries apply only to files that aren't in the index, but are in the work-tree.

索引（总是存在），并且由于操作系统的坚持，它所保存的文件名实际上出现在目录中。因此，如果索引具有 long / path / to / important / file ，Git将检查以查看 long / path / to / important / file 仍然存在，并且已经修改或尚未修改。但是，如果您忽略了 long 或 long / path / to / important 或此处的某些方法， Git不会读取目录。 ² 如果您以某种方式意外地删除 long / path / to / important / file ，而忽略目录 long / path / to / important 时，Git不会再次单独添加文件，也不会警告您工作树文件已成为未跟踪的文件。

The index (always) exists, and it holds file names that—because the OS insists—actually appear inside directories. So if the index has a long/path/to/important/file, Git will check to see if long/path/to/important/file is still there and has or has not been modified. But if you've ignored long, or long/path/to/important, or something along the way here, Git won't read the directory.² If you somehow accidentally remove long/path/to/important/file from the index while ignoring the directory long/path/to/important, Git won't add the file back again by itself, nor will it warn you that the work-tree file has become an untracked file.

² 您可以使用 git add -f 添加否则将被忽略的文件，并且您可以在目录中拥有一组文件不会被忽略，将其中一些文件添加到索引中，然后修改 .gitignore 以忽略其包含的目录。所有这些都会导致索引中的文件无法通过更直接或更有力的方法（ add -f ）到达那里。这些是我考虑的情况：它们不是错误，但它们违反了最后一个要点。

²You can add a file that would otherwise be ignored using git add -f, and you can have a set of files in directories that aren't ignored, add some of those files to the index, then modify .gitignore to ignore their containing directories. All of these result in files in the index that would not have gotten there by a more direct, or less forceful (add -f), method. These are the cases I consider concerning: they are not wrong but they fall afoul of this last bullet-point.

这篇关于gitignore规则（应用于codeigniter堆栈）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！