git 何时在 gitignore 中使用前导斜杠

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/24139478/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-19 10:06:16  来源:igfitidea点击:

When to use leading slash in gitignore

gitgitignore

提问by swahnee

I'm trying to understand more clearly the .gitignoresyntax, and in particular as far as https://github.com/github/gitignoregitignores are concerned.

我试图更清楚地理解.gitignore语法,特别是就https://github.com/github/gitignoregitignores 而言。

I see that the leading slash is used to match only pathnames relative to the location of the .gitignorefile (from http://git-scm.com/docs/gitignore):

我看到前导斜杠仅用于匹配相对于.gitignore文件位置的路径名(来自http://git-scm.com/docs/gitignore):

A leading slash matches the beginning of the pathname. For example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".

前导斜杠与路径名的开头匹配。例如,“/*.c”匹配“cat-file.c”但不匹配“mozilla-sha1/sha1.c”。

But what happens when i remove the leading slash? As far as what i understood, there are two cases:

但是当我删除前导斜杠时会发生什么?据我了解,有两种情况:

  1. If the pattern does not contain a slash (or it contains only a trailing slash, which means that it should match a directory), the search is performed inside the entire directory tree. For example, the pattern dir/will match <root>/dir, <root>/a/dir, <root>/a/b/c/.../dir, etc., where <root>is the location of the .gitignorefile.
  2. If the pattern contains a slash, which is not in the trailing position (it's not the last character), then it is matched only with pathnames relative to the .gitignorefile location.
  1. 如果模式不包含斜杠(或者它只包含一个尾部斜杠,这意味着它应该匹配一个目录),则在整个目录树中执行搜索。例如,模式dir/将匹配<root>/dir<root>/a/dir<root>/a/b/c/.../dir等,其中<root>.gitignore文件的位置。
  2. 如果模式包含一个斜杠,它不在尾随位置(它不是最后一个字符),那么它只与相对于.gitignore文件位置的路径名匹配。

These are the examples i made to check this behaviour:

这些是我为检查此行为而制作的示例:

# Directory structure:
<root>
├─ dir/
│   └─ test
├─ src/
│   ├─ dir/
│   │   └─ test
test file is there only because Git does not track empty directories.

First test:

第一次测试:

# .gitignore
dir/

# git status
nothing to commit

So Git is ignoring both dirdirectories. This is consistent with case number 1: the pattern has no slashes (except for the trailing one), so Git is watching the entire directory tree, ignoring everything that matches the pattern.

所以 Git 忽略了这两个dir目录。这与第 1 种情况一致:模式没有斜杠(结尾的除外),因此 Git 正在监视整个目录树,忽略与模式匹配的所有内容。

Second test:

第二次测试:

# .gitignore
/dir/

# git status
Untracked files:
    src/

Here, Git is ignoring only the dirdirectory directly beneath the root directory, thanks to the leading slash in the pattern.

在这里,dir由于模式中的前导斜杠,Git 仅忽略根目录正下方的目录。

Third test:

第三次测试:

# .gitignore
dir/*

# git status
Untracked files:
    src/

This is consistent with the case number 2: the pattern has some slash inside it, so it is considered as a pathname starting from the root directory.

这与第 2 种情况一致:模式内部有一些斜杠,因此它被视为从根目录开始的路径名。

Now it's time for the real question. Let's consider this gitignore file: when they ignore the directory downloader/, for example, aren't they actually ignoring every single downloaderdirectory found in the entire directory tree? This is what i'm driven to think since what i saw about Git's workings before.

现在是真正的问题的时候了。让我们考虑这个 gitignore 文件downloader/例如,当他们忽略目录时,他们实际上是否忽略downloader了在整个目录树中找到的每个目录?自从我之前看到 Git 的工作原理以来,这就是我的想法。

So if i happen to have a custom module with a downloaderdirectory inside of it, will it be unexpectedly ignored as well as the regular one in the root of Magento? This is a bit of a rethorical question because it actually already happened to me, producing a really hard to find bug.

因此,如果我碰巧有一个自定义模块,其中包含一个downloader目录,它会不会像 Magento 根目录中的常规模块一样被意外忽略?这是一个有点理所当然的问题,因为它实际上已经发生在我身上,产生了一个很难找到的错误。

So, in the Magento .gitignorefile (which i'm referring to only as an example, btw) a lot of the patterns contain slashes, so they are correctly matched against pathnames starting from the root, but there are a few cases, like downloader/or errors/that, if i'm not mistaken, are potentially dangerous, and which should probably be changed to /downloader/and /errors/.

所以,在 Magento.gitignore文件中(我只是作为一个例子,顺便说一句)很多模式都包含斜杠,所以它们与从根开始的路径名正确匹配,但有一些情况,比如downloader/errors/那样,如果我没记错的话,是有潜在危险的,应该改成/downloader//errors/

As a more general question, should i always use the leading slash for patterns not containing slashes (except for the trailing one) when i want to select a pathname explicitly starting from root, and not to use it for patterns containing slashes, or should i always use the leading slash for clarity? What do you think about it?

作为一个更一般的问题,当我想从根显式地选择一个路径名而不是将它用于包含斜杠的模式时,我是否应该总是将前导斜杠用于不包含斜杠的模式(尾随除外),或者我应该为了清楚起见,总是使用前导斜杠?你怎么看待这件事?

Thank you for reading and sorry for the long post.

感谢您阅读并为长篇文章感到抱歉。

回答by solstice333

Just wanted to summarize for possible quick future reference -- the leading slash anchors the match to the root. Thus, in the example below, without the slash, the wildcard would also exclude everything within foo because it would take *and move recursively down the tree. However, with /*, it excludes everything except folder foo and its contents:

只是想总结一下以备将来可能的快速参考——前导斜杠将匹配锚定到根。因此,在下面的示例中,如果没有斜线,通配符也会排除 foo 中的所有内容,因为它会*在树中递归地向下移动。但是,使用/*,它排除文件夹 foo 及其内容以外的所有内容:

$ cat .gitignore
/*
!/foo

回答by tne

You've answered your own question entirely. If you look at the github/gitignore repo more closely, you'll see most files use inconsistent rules about how patterns are written; it's very likely most were contributed by people who didn't bother to read the documentation nor test things out as you did.

你已经完全回答了你自己的问题。如果您更仔细地查看 github/gitignore 存储库,您会发现大多数文件使用不一致的模式编写规则;很可能大多数是由那些不像你那样费心阅读文档或测试事物的人贡献的。

So if that helps: You're right, be confident.

所以如果这有帮助:你是对的,要自信。

If you see mistakes in collaborative projects such as this, don't hesitate to contribute your knowledge. There's even some precedentif you need to build up your confidence further.

如果您在此类协作项目中看到错误,请不要犹豫贡献您的知识。如果您需要进一步建立信心,甚至还有一些先例