我知道這個問題有點神秘，我無法用一個句子準確地說出它（可能需要一些幫助）。

我在我的主目錄初始化的git（即~/，在Arch Linux的）來備份我的點檔案（主要是CONFIGS）。我想在其中包含每個檔案和檔案夾，除了以.(like.config/和.bashrc)開頭的檔案和檔案夾。

所以我做了一個.gitignore檔案，其內容是：

# Ignore everything
*

# Except these files and folders
!.*

但問題是當我列出所有未跟蹤的檔案 ( git status) 時，.config/由于某種原因它沒有列出目錄。我試著玩弄.gitignore并添加

!*/

顯示所有目錄，包括.config/和也Documents，Downloads等等，我不想有。

而不是添加

!.*/

顯示所有其他目錄下，以一個開始.喜歡.cache/，.vim/等，但由于某些原因.config/沒有顯示出來。

我什至試過

!.config/

和

!.config

它不起作用。唯一有效的是!*/（所有目錄，這不是我想要的）

有什么辦法可以解決這個問題。它真的很煩人。

[已解決]： 這是一個錯誤

該錯誤已在 git 版本 2.34.1 中修復

檢查接受的答案。

uj5u.com熱心網友回復：

TL; 博士

在錯誤修復之后，您將需要在“有點解決”部分中放置的內容或類似內容。我想你會想要我放在“底線”部分的內容，真的：

/*
!/.*

長

正如jthill 在評論中指出的那樣，.gitignore Git 2.34.0中的通配符處理存在錯誤，將在 2.34.1 中修復。在這種情況下，我認為該錯誤使您的通配符比其他情況下更好地作業。??

第一行：

# Ignore everything
*

做他們聲稱的事情：忽略一切。所有檔案和檔案夾（目錄）都將被忽略。后續行插入例外。但是請稍等，忽略的真正含義是什么？為此，我們必須注意 Git 的索引（或暫存區）是什么以及 Git 如何從索引/暫存區進行新提交。

在 Git 中，索引或暫存區是一個核心且關鍵的概念。在不了解索引的作用的情況下嘗試使用 Git 有點像在不了解機翼和發動機的用途的情況下嘗試駕駛飛機。¹ 所以：索引是關于你計劃進行的下一次提交。如果您從不進行任何新提交，則您實際上不需要了解它，但是如果您確實想進行新提交，則需要了解這一點。²

當您第一次提取某個提交時，為了使用和處理它，Git 會填充來自該提交的索引，以便索引包含來自該提交的所有檔案。從這一點開始，您在作業樹中所做的一切，以追求進行新的提交，都與 Git 無關。也就是說，直到您告訴 Git 您希望 Git 將更新的和/或新的檔案復制到 Git 的索引中，它才無關緊要。

該git add命令是關于更新 Git 的索引。你的名字到檔案git add，有git add file1 file2例如，將被復制到Git的指數。如果已經有這兩個檔案的副本，則這些副本將從索引中啟動，并替換為更新的副本。如果沒有，這些檔案將新添加到索引中。

一旦檔案在 index 中，您可以隨時替換它：此時任何.gitignore條目都無關緊要。您還可以從索引中洗掉它，使用git rm，或git add在洗掉作業樹副本后使用：任何一個都將洗掉索引副本。現在它不再在索引中并且.gitignore條目重新起作用。

您可以使用 en-masse git add，如git add .或git add *, ³來讓 Git掃描目錄和檔案并為您添加它們。當你這樣做時，Git 會盡可能地跳過某些目錄和/或檔案，這才是.gitignore真正發揮作用的領域。

¹ “我為什么要關心這些？我只關心將我的乘客和貨物從 A 點送到 B 點，而且這些都在飛機內部，而不是機翼上。”

^{2 進一步}擴展飛機的類比：如果您只是打算將機身用作房屋，那么確實，您不需要關心發動機和機翼。

³請注意，在類 Unix 的 shell 中，git add *完全不同，git add .因為shell會*為 Git擴展：Git 永遠不會看到字面的星號。當 shell 擴展時*，它會在排除點檔案的情況下這樣做，至少默認情況下（特別是 bash 有一個控制旋鈕來改變這種行為）。在某些 CLI 中，字面的星號*會傳遞給 Git，然后Git將展開*，現在它可以像git add .Git 想要的那樣運行。但是輸入更容易git add .（不需要SHIFT密鑰），所以無論如何我總是這樣做，這首先消除了差異。

Git 如何掃描作業樹

如果您運行git add .或等效（再次參見腳注 3），Git 將：

1. 打開目錄.。
2. 打開并讀取.gitignore此級別的任何檔案，將這些規則添加（附加）到忽略規則中。（當我們完成這個目錄時，這些規則就會被洗掉。）
3. 閱讀這個目錄：它包含檔案和子目錄的名稱（“檔案夾”，如果你喜歡這個詞的話）。
4. 在我們閱讀每個檔案和檔案夾名稱時，根據當前有效的所有忽略規則檢查它們。請注意，某些規則僅適用于目錄/檔案夾，而其他規則適用于檔案夾和檔案。僅限檔案夾的規則是以斜杠結尾的規則。此外，有些規則是“積極的”（不要忽略），有些則是“消極的”（不要忽略）。否定規則是以 開頭的規則!。

Git finds the last applicable rule, whatever that is, in the current set of rules, and then obeys that rule. So first, let's define which rules apply to which directory-scan results, and then what the various rules do.

A rule in a .gitignore can be:

• a simple text string with no slashes, such as generated.file;
• a text string with a trailing slash, but no other slashes: somedir/;
• a text string with a leading or embedded slash, with or without a trailing slash: /foo, a/b, /foo/, a/b/, and so on; or
• any of the above with various glob-style wildcard characters.

These can all be negated: if a rule starts with ! it's negated, and we strip off the ! and then use the remaining tests. The two keys tests are these:

• Does the entry end with a literal /? If so, it applies only to directories / folders. Ignore that slash while answering the remaining question.
• Does the entry begin with or contain a slash / character? (The one at the end does not count here.) If so, this entry is anchored or rooted (I like the term anchored myself, but I've seen both terms used).

An anchored entry matches only a file or folder name found at this level. That is, /foo or foo/bar won't match sub/foo or sub/foo/bar, only ./foo and ./foo/bar, where . is the directory (folder) that Git is scanning right now. This means that if the entry has several levels—foo/bar or one/two/three for instance—Git will have to remember to apply this entry when it gets around to scanning bar in foo, or two in one and three in one/two. So we do have to consider "higher level" rules. But since lower level rules get appended, a lower level .gitignore can cancel out the higher level one if it wants to.

An un-anchored entry applies here and—unless overridden—in every sub-directory as well. That is, if we do have ./one/two/three, Git will presumably open and read one to find two, and then open and read two to find three, all while still working on the current directory. Meanwhile any un-anchored entry from this .gitignore will apply within the one and one/two directories, and within one/two/three if that's a directory, and so on.

So, there's already a lot to think about. Now we throw in glob matches.

The usual glob is *: people write foo*bar or *.pyc or whatever. Git allows ** as well, with meaning similar to that in bash: zero or more directories. (I've found ** in Git to be weird and in my opinion slightly buggy, where it sometimes seems to mean "one or more" instead of "zero or more", so I recommend avoiding ** if possible. It's hard to reason about, so it's generally not a great idea in the first place, and Git's ignore rules mostly eliminate any need for **. So if you are going to use it, test it carefully and be prepared to have it shift on you in some future Git, in case the one-or-more ?bug? gets fixed, or affects your use case, or whatever.)

Let's suppose, then, that we have these two entries:

*
!.*

Git opens and reads . and finds the following names:

dir
file
.dir
.file

where dir and .dir are directories (folders) and file and .file are non-directories (files).

The * rule matches all four names. The !.* rule matches the last two names. The !.* rule is later in the .gitignore file, so it overrides the * rule. Git therefore "sees" .dir and .file.

Since .file is a file, this means that git add . "sees" it. It will check whether .file needs to be git add-ed to displace the existing .file file, or added to the index.

Since dir and file are excluded, this scanning pass doesn't see them, and does not try to git add either one. Since dir itself is a directory (not a file), it's never in the index itself. There may be a file in the index named dir/thing, and Git will check to see if that should be updated by this git add ., but Git won't scan dir to see if there are other files in dir.

Since file is an excluded file, the scanning pass does not see it. But if file already exists in the index, Git will check to see if it should be updated by this git add ., even though it didn't get scanned here. In other words, these "existing files already in the index" checks happen outside (either before or after) the "scan the directories" pass.

Meanwhile, since .dir isn't excluded, Git now opens and reads .dir, recursively:

• Git checks for a .dir/.gitignore (the .gitignore that applies to entries found in .dir). If that exists, Git appends those rules.
• Git scans .dir recursively, using all the same methods. Then it's done scanning .dir so Git removes the appended rules.

Let's look now at the rules Git has in effect as it scans .dir.

The appended-to rules

If there is a .dir/.gitignore, Git opens and reads it and appends to the existing rules. If not, we still have the same set of rules in effect:

*     (positive wildcard: ignore every name)
!.*   (negative wildcard: don't ignore dot-names)

What's in .dir? Let's say we have:

file1
dir1
.file2
.dir2

The name file1 matches * so it gets ignored. Git won't git add it to the index if it's not already there. Similarly, dir1 matches *, so it gets ignored. Git won't even scan it to see if there are any files there.

The name .file2 matches *, but also matches .*, so the override negative entry is the rule that applies: Git will git add .dir/.file2. The name .dir2 has the same features, so the override applies and Git will open and read .dir/.dir2. This goes through the same recursion as before: Git looks for .dir/.dir2/.gitignore to append rules, and will use the appended-to rules while scanning .dir/.dir2, and then drop back to our own .dir/.gitignore-appended rule set while continuing to scan .dir, and then return from this recursion level and drop the .dir/.gitignore rules.

The bottom line

In the end, the trick here is that we want the * rule to apply only at the top level. Once we get into, say, .foo/, we don't want to ignore .foo/main_config and .foo/secondary_config. So we want * to apply only at the top level.

Using:

# Ignore everything
*

# Except these files and folders
!.*
!.*/*

gets us closer: we ignore everything, but then—via the negative rules !.* and !.*/*—we carefully don't ignore .foo and the like. Once we get into .foo, we carefully don't ignore .foo/main_config.

The bug, or possible bug, depending on what you really do want, here is ... well, suppose we have .foo/thing1/config and .foo/thing2/config. The .*/* pattern contains an embedded slash, which means it is anchored. It matches .foo/thing1, so that directory gets scanned. But it doesn't match .foo/thing1/config.

We could try something like:

!.*/*
!.*/**/

I particularly hate this one because ** is so tough to reason about. We could also write:

!.*/*
!.*/*/
!.*/**/

in case the ** "one or more" bug bites us (I don't think it will, but it's a consideration). But it's simplest to anchor the original globs, by writing:

/*
!/.*

這使得頂級.gitignore 規則僅適用于頂級作業樹條目。子級.gitignore檔案（如果存在）可以建立子級規則并且不需要覆寫任何頂級規則，因為由于錨定，頂級規則已經不適用于任何子級。

標籤：混帐 配置

上一篇：將gitcurrent分支推送到AzurePipeline中的遠程git

下一篇：無法訪問gitpre-receive鉤子的引數