從作業樹中洗掉檔案后，.gitignore不會取消跟蹤檔案

我遇到了一個問題，即 .gitignore 不會忽略檔案（'private/config.php'）。

.ignore 檔案如下：

public/uploads/
logs/
private/config.php

該檔案最初包含在跟蹤檔案中，因此我按如下方式將其從分支中洗掉，但正如您將在git ls-tree命令中看到的那樣，它仍顯示在跟蹤檔案串列中...

ubuntu@MYMACHINE:/var/www/gig$ git rm --cached private/config.php
rm 'private/config.php'
ubuntu@MYMACHINE:/var/www/gig$ git ls-tree -r main --name-only
.gitignore
README.md
private/config.php
private/initialize.php
[...]

奇怪的是，我在本地檔案夾中發出命令時遇到了同樣的問題：

ubuntu@MYMACHINE:/var/www/gig/private$ git rm --cached config.php
fatal: pathspec 'config.php' did not match any files
ubuntu@MYMACHINE:/var/www/gig/private$ git rm --cached private/config.php
fatal: pathspec 'private/config.php' did not match any files
ubuntu@MYMACHINE:/var/www/gig/private$ git ls-tree -r main --name-only
config.php
initialize.php

有關如何從跟蹤檔案中清除此檔案的任何線索？

uj5u.com熱心網友回復：

列出一個檔案.gitignore 永遠不會導致它不被跟蹤。

檔案要么被跟蹤，要么未被跟蹤。此屬性由對單個問題的回答決定：

• 該檔案當前是否在 Git 的索引中？

如果答案為“是”，則跟蹤檔案。如果答案為“否”，則檔案未跟蹤。¹

¹如果您的作業樹中也缺少該檔案，大多數人只會稱其為“不存在”，但確實所有不存在的未跟蹤檔案也未跟蹤。不存在的檔案“zaphod_beeblebrox”現在未被跟蹤。

關于 Git 的索引

現在，這里真正棘手的部分與 Git 的索引有關。索引——這在 Git 中是很重要的；你需要知道這一切——很難看到。您主要通過對比“看到”索引。但是索引是什么很容易描述，盡管這遺漏了一些細微差別：

Git 的索引保存您提議的下一次提交。

所有提交，一旦完成，就完全是只讀的，并且一直被及時凍結。任何現有提交的任何部分都不能更改。

您通過以下方式進行新的提交：

• 提取一些現有的提交（到您的作業樹中，它為您提供可以更改的普通讀/寫檔案）；
• 在那里做一些作業，使用您可以查看和使用的檔案；和
• 最終，git commit用于進行新的提交。

在大多數版本控制系統中，他們的“提交”動詞采用當時作業樹中的任何內容，并使用它來進行新的提交。Git 是……不同的。當您運行時，Git 會忽略您的作業樹git commit，而是使用 Git 存盤在 Git索引中的所有檔案。

由于 Git 實際上從索引檔案構建提交，因此索引中的檔案至關重要。然后，您需要知道提取提交（如中所示git checkout somebranch）會填充來自該提交的Git 索引。

一旦從某個提交填充索引，并從提交中提取檔案，所有三個活動副本都匹配. 在當前提交中，您有一個實際上無法更改的檔案。您在 Git 的索引中存盤了另一個同名檔案。您有該檔案的第三個副本作為作業樹中的常規讀/寫檔案。

一旦你改變了你的作業樹了一些檔案，你需要運行git add。這會將檔案從您的作業樹復制回 Git 的索引。

因此，Git 還使用術語暫存區作為索引。索引副本被稱為“暫存以進行提交”。運行會git commit提交索引中的任何內容——無論是檔案的原始副本（之前提取的），還是更新后的副本（從最近的git add.

如果您從 Git 的索引中洗掉檔案，該檔案將不會出現在下一次提交中。這git rm就是關于。

唉，如果你運行git rm somefile，Git會洗掉該檔案somefile從兩個Git的索引和你的作業樹。所以現在真的沒了。當然，它也沒有被跟蹤，但是如果沒有作業樹副本，它就完全消失了。

因此，您可以git rm --cached：這僅洗掉索引副本，而單獨保留作業樹副本。現在該檔案未被跟蹤（不會在下一次提交中），但仍存在于作業樹中。

Once you make the new commit, extracting the new commit won't extract the file, as it's not in that commit. But remember, extracting the old commits—those that have the file—will extract the file, both to Git's index and your working tree. So the file will magically—actually, rather un-magically—become tracked at that point. Switching to a new commit that lacks the file will now remove the file from both Git's index and your working tree, and now it's untracked—but also gone from your working tree.

Ultimately, this means that having committed a file, then removing it and committing the removal, sets up a trap: if you git rm --cache the file so that you commit the removal without erasing the working tree copy, you're still left with:

• old commit has the file
• new commit lacks the file
• so switching from old to new removes the file

which means you must now be very careful every time you go back to the old commits.

(See also IMSoP's answer.)

uj5u.com熱心網友回復：

您似乎在這里混淆了幾個概念：

• “快取”git rm --cached指的是“快取”、“索引”或“暫存區”，它基本上是要包含在下一次提交中的檔案集。
• “main” ingit ls-tree -r main指的是名為“main”的分支——或者更具體地說，指的是提交所指向的檔案樹，由名為“main”的分支參考所指向。換句話說，它列出了您在該分支上所做的最后一次提交的檔案。

因此，從下一次提交中洗掉某些內容不會改變現有提交中的內容也就不足為奇了。您需要創建一個不包含該檔案的提交。

標籤：混帐 gitignore

上一篇：gitignore全域配置究竟有什么作用？

下一篇：Heroku推送不會更新GitHub存盤庫