我如何从Windows中的git仓库中删除现有的和未来的pycahce文件？我在网上找到的命令不起作用，例如，当我发送命令“git rm -r --cached __pycache__“时，我得到了命令“pathspec '__pycache__' did not match any files“。
git rm -r --cached __pycache__
pathspec '__pycache__' did not match any files
mbjcgjjk1#
你现在看到的__pycache__文件夹并不在你当前和未来的Git提交中。由于Git的内部工作方式--Git强迫你了解它，至少如果你要理解它的话--* 理解 * 这是一个有点棘手的问题，即使我们在你的评论中看到了“目录/文件夹混淆”。我相信，正确的起点是在顶部。Git不是*文件（甚至是文件和文件夹/文件和目录）。那些刚接触Git的人把它看作是存储文件，所以他们认为它是关于文件的，但这并不是真的。或者，他们注意到分支背后思想的重要性，认为Git是关于分支的，但这也不是真的，因为人们把一种“分支”（这很重要）和分支名称（这不重要）搞混了。那么，首先要知道的是，**Git实际上是关于提交的。这意味着您确实需要了解：
__pycache__
（这两个部分是重叠的，但并不完全相同）。由于篇幅的原因，我们在这里不讨论commit * 是什么 *，但让我们来看看commit为你做的主要事情：每次提交都会存储每个文件的完整快照。现在我们需要稍微偏离一下主题，看看Git和你的操作系统在文件组织方式上有何不同。你的电脑坚持一个 file 的名字类似file.ext，并且存放在一个 folder 或 directory 中--这两个术语是可以互换的--比如to，它又存放在另一个文件夹中，比如path。这就产生了path/to/file.ext或，在Windows上为path\to\file.ext。相比之下，Git只有 files，它们的名称总是使用正斜杠，并包含斜杠。名为path/to/file.ext的文件实际上就是 file，具有该名称。但Git理解您的计算机要求文件夹中的文件格式，并会根据需要来回转换。如果Git需要提取一个名为some/long/file/name.ext的文件，Git会在必要的时候自动创建some、some/long等文件夹。奇怪的副作用是，因为Git只存储 * 文件 *，而不存储文件夹，Git无法存储 * 空文件夹 *。这种区别实际上发生在Git的索引，也就是暂存区，我们不会详细讨论，但它解释了这个问题，其答案在How do I add an empty directory to a Git repository?中给出在任何情况下，提交都会使用这些路径名来存储文件。每个提交都有每个文件的完整副本--但文件的内容是以一种特殊的、Git化的、只读的、只适用于Git的格式存储的，其中的内容是 * 去重复的 *。因此，如果一百万个提交存储了一个特定文件的一个特定版本，那么实际上只有一个副本。Git之所以能做到这种共享，是因为与你电脑上的普通文件不同，在Git中，保存在一个提交中的文件实际上是无法更改的。现在回到提交：每次提交都包含了 * 每个 * 文件的完整快照（当你或任何人提交时它所拥有的）。但是这些文件是只读的--它们实际上 * 不能 * 被替换它们的内容，这就是共享的原因--而且只有Git本身才能 * 读取 * 它们。这使得它们对实际完成任何工作都毫无用处。它们作为归档文件很好，但对真实的工作没有好处。这个问题的解决方案很简单（和几乎所有其他版本控制系统一样）：当你选择某个提交来处理时，Git会从该提交中提取文件。这会在普通文件夹中创建普通文件，在一个普通的区域中让你可以做你的工作（无论是普通的、不合格的还是示范性的工作--这都取决于你，而不是Git😀）。这意味着你在一个工作树或工作树中做你的工作（Git可以互换使用这两个术语）。更重要的是，它的意思是：**你看到的文件并不在Git中 *。**它们可能只是被Git * 从某个提交中提取出来的。但现在它们是普通的文件，你在Git不知道你在做什么的情况下使用它们。由于Git已经将这些文件解压缩到了普通的文件夹中，所以你可以创建新的文件和/或新的文件夹。当你运行Python程序时，Python会在不同的时间创建__pycache__文件夹，并将*.pyc和/或*.pyo文件放入其中。Python会在Git不知道或不理解的情况下完成这些操作。因为这些文件是 * 由 * Python基于源代码生成的，并且只是用来加速Python，所以最好 * 避免将它们放到提交中 *。没有必要保存这些文件的永久快照，特别是因为格式和内容可能取决于特定的Python版本（例如，Python 3.7会生成*.cpython-37.pyc文件，Python 3.9会生成*.cpython-39.pyc文件，以此类推）。1.不要抱怨工作树中存在这些特定的 untracked 文件。
file.ext
to
path
path/to/file.ext
path\to\file.ext
some/long/file/name.ext
some
some/long
*.pyc
*.pyo
*.cpython-37.pyc
*.cpython-39.pyc
1.当我使用像git add .这样的全体“添加所有内容”操作时，不要将这些文件 * 添加 * 到索引/临时区域，这样它们也不会进入下一次提交。我们通常会对.gitignore文件（名字很糟糕）这样做。在.gitignore中列出文件名并不会让Git ignore 它;相反，它具有完成我在这里列出的两件事的效果。这里使用了Git特有的术语 untracked file，它有一个简单的定义，但有一个复杂的背景故事。**untracked file就是工作树中当前不在Git索引中的任何文件（staging area）.*由于我们不打算在这里讨论Git的索引，我们必须暂时到此为止，但是我们不允许__pycache__文件进入Git的索引，这样它们就不会被跟踪，Git就不会提交它们，Git就不会把它们放到Git的索引中。这有点像循环，如果你不小心把这些文件放到了Git的索引中， 这就是 * 需要git rm -r --cached __pycache__命令的时候。既然这个命令失败了，那就意味着你没有这个命令要解决的问题。
git add .
.gitignore
m3eecexj2#
你的git仓库中不需要__pycache__文件，你最好把__pycache__/添加到你的.gitignore文件中，忽略所有相关的文件。
__pycache__/
2条答案
按热度按时间mbjcgjjk1#
你现在看到的
__pycache__文件夹并不在你当前和未来的Git提交中。由于Git的内部工作方式--Git强迫你了解它，至少如果你要理解它的话--* 理解 * 这是一个有点棘手的问题，即使我们在你的评论中看到了“目录/文件夹混淆”。我相信，正确的起点是在顶部。Git不是*文件（甚至是文件和文件夹/文件和目录）。那些刚接触Git的人把它看作是存储文件，所以他们认为它是关于文件的，但这并不是真的。或者，他们注意到分支背后思想的重要性，认为Git是关于分支的，但这也不是真的，因为人们把一种“分支”（这很重要）和分支名称（这不重要）搞混了。那么，首先要知道的是，**Git实际上是关于提交的。
这意味着您确实需要了解：
（这两个部分是重叠的，但并不完全相同）。由于篇幅的原因，我们在这里不讨论commit * 是什么 *，但让我们来看看commit为你做的主要事情：每次提交都会存储每个文件的完整快照。
现在我们需要稍微偏离一下主题，看看Git和你的操作系统在文件组织方式上有何不同。你的电脑坚持一个 file 的名字类似
file.ext，并且存放在一个 folder 或 directory 中--这两个术语是可以互换的--比如to，它又存放在另一个文件夹中，比如path。这就产生了path/to/file.ext或，在Windows上为path\to\file.ext。相比之下，Git只有 files，它们的名称总是使用正斜杠，并包含斜杠。名为
path/to/file.ext的文件实际上就是 file，具有该名称。但Git理解您的计算机要求文件夹中的文件格式，并会根据需要来回转换。如果Git需要提取一个名为some/long/file/name.ext的文件，Git会在必要的时候自动创建some、some/long等文件夹。奇怪的副作用是，因为Git只存储 * 文件 *，而不存储文件夹，Git无法存储 * 空文件夹 *。这种区别实际上发生在Git的索引，也就是暂存区，我们不会详细讨论，但它解释了这个问题，其答案在How do I add an empty directory to a Git repository?中给出
在任何情况下，提交都会使用这些路径名来存储文件。每个提交都有每个文件的完整副本--但文件的内容是以一种特殊的、Git化的、只读的、只适用于Git的格式存储的，其中的内容是 * 去重复的 *。因此，如果一百万个提交存储了一个特定文件的一个特定版本，那么实际上只有一个副本。Git之所以能做到这种共享，是因为与你电脑上的普通文件不同，在Git中，保存在一个提交中的文件实际上是无法更改的。
现在回到提交：每次提交都包含了 * 每个 * 文件的完整快照（当你或任何人提交时它所拥有的）。但是这些文件是只读的--它们实际上 * 不能 * 被替换它们的内容，这就是共享的原因--而且只有Git本身才能 * 读取 * 它们。这使得它们对实际完成任何工作都毫无用处。它们作为归档文件很好，但对真实的工作没有好处。
这个问题的解决方案很简单（和几乎所有其他版本控制系统一样）：当你选择某个提交来处理时，Git会从该提交中提取文件。这会在普通文件夹中创建普通文件，在一个普通的区域中让你可以做你的工作（无论是普通的、不合格的还是示范性的工作--这都取决于你，而不是Git😀）。这意味着你在一个工作树或工作树中做你的工作（Git可以互换使用这两个术语）。更重要的是，它的意思是：**你看到的文件并不在Git中 *。**它们可能只是被Git * 从某个提交中提取出来的。但现在它们是普通的文件，你在Git不知道你在做什么的情况下使用它们。
由于Git已经将这些文件解压缩到了普通的文件夹中，所以你可以创建新的文件和/或新的文件夹。当你运行Python程序时，Python会在不同的时间创建
__pycache__文件夹，并将*.pyc和/或*.pyo文件放入其中。Python会在Git不知道或不理解的情况下完成这些操作。因为这些文件是 * 由 * Python基于源代码生成的，并且只是用来加速Python，所以最好 * 避免将它们放到提交中 *。没有必要保存这些文件的永久快照，特别是因为格式和内容可能取决于特定的Python版本（例如，Python 3.7会生成
*.cpython-37.pyc文件，Python 3.9会生成*.cpython-39.pyc文件，以此类推）。1.不要抱怨工作树中存在这些特定的 untracked 文件。
1.当我使用像
git add .这样的全体“添加所有内容”操作时，不要将这些文件 * 添加 * 到索引/临时区域，这样它们也不会进入下一次提交。我们通常会对
.gitignore文件（名字很糟糕）这样做。在.gitignore中列出文件名并不会让Git ignore 它;相反，它具有完成我在这里列出的两件事的效果。这里使用了Git特有的术语 untracked file，它有一个简单的定义，但有一个复杂的背景故事。**untracked file就是工作树中当前不在Git索引中的任何文件（staging area）.*由于我们不打算在这里讨论Git的索引，我们必须暂时到此为止，但是我们不允许
__pycache__文件进入Git的索引，这样它们就不会被跟踪，Git就不会提交它们，Git就不会把它们放到Git的索引中。这有点像循环，如果你不小心把这些文件放到了Git的索引中， 这就是 * 需要git rm -r --cached __pycache__命令的时候。既然这个命令失败了，那就意味着你没有这个命令要解决的问题。
m3eecexj2#
你的git仓库中不需要
__pycache__文件，你最好把__pycache__/添加到你的.gitignore文件中，忽略所有相关的文件。