GIT是否会在本地文件从存储库中删除后自动删除它们？

GIT是否会在本地文件从存储库中删除后自动删除它们？在我的例子中，如下所述，答案似乎是否定的。那么有什么诀窍呢？这是否取决于文件的删除方式

我的情况；我让一个同事克隆了我们的主repo，然后他创建了一个分支，然后他删除了一个包含数百个文件的目录。然后他提交了一个请求，我合并到master，然后我检查了master repo的web视图，那个目录就不见了。太好了

但接下来，我尝试同步我的分支，我尝试从主目录更新，那个目录仍然在我的本地文件系统中。GitHub desktop说我的分支与master同步。好啊也许是的。但是为什么Git不从我的本地文件夹中删除这些文件呢？它们不再在存储库中

Git不会删除任何文件。您可以从给定的提交中删除特定文件，但它们将保留在repo中，除非您使用git filter branch或类似的工具（例如）完全删除它们

要验证您是否具有最新版本，请使用以下命令：

git log ^master origin/master

如果未与远程服务器完全同步，它将显示提交

但下一步，我尝试同步我的分支，我尝试从Master更新

---

假设您使用git pull origin master，那么这两个分支之间不应该有任何更改，因此上面的命令不应该返回任何内容。

要了解这一切是如何工作的，以及git何时以及为什么删除文件，您必须同时记住三个想法：

Git将提交存储在存储库中

每次提交都是一个工作树的快照；见下文。它本身是完整的。一旦你做出承诺，它永远不会改变。它的数学设计是不可能改变的：任何提交的真实名称是该提交内容的加密校验和。这意味着，如果您在提交中更改任何文件的哪怕是一个位，或者添加任何新文件或删除任何旧文件，您将得到一个新的、不同的提交，并使用不同的名称

Git存储库有一个工作树

提交中的文件格式只有Git自己可以使用。如果Git从不允许您编辑、查看或以其他方式使用您的文件，那么它将毫无用处。因此，每个存储库都有一个工作树，基本上是Git将这些文件扩展为其正常形式的地方，这样计算机上的所有其他程序和您自己都可以使用它们

Git存储库有一个索引

工作树和提交是完全不同的，但是您可以将工作树转换为提交，或者将提交转换为工作树。Git的索引是工作树和提交之间的中间位置。Git在公开这个东西方面是不寻常的：其他版本控制系统有时有一些类似于Git索引的东西，但大多数都将其隐藏起来。Git没有

无论如何，索引是所有这些的关键

如果您正在编写新的提交，描述和思考索引的最佳方式是，它是您构建下一个提交的地方。这有很多原因，其中一些原因比其他原因好，许多原因与提取旧提交或进行新提交的速度有关。然而，Git通过索引提供了几个关键特性，这迫使您了解它是什么以及如何使用它

特别是，在许多计算系统中，我们希望或需要在工作树中保存永远不会提交的文件。例如，对于编译语言，我们有源代码，然后是编译器输出文件。项目可能具有特定于站点的配置。有很多很好的理由希望将未版本化的文件与版本化的文件混合在一起。在某些情况下，它们甚至可能是版本化的，但与源Git分开在这里并没有多大帮助

因此，索引是一种中间人，位于永久提交和临时提交之间，但对Git工作树以外的事物有用。不过，除了让您为下一次提交暂存文件外，索引还跟踪您从当前提交中提取的文件。更准确地说，它跟踪您拥有的每个文件的版本，这是Git尽可能快的方法之一

以下是关于删除内容的答案 当您从一个提交移动到另一个提交时，就像您使用git签出当前提交以外的其他提交一样，所谓的快速前进git merge git将从您的工作树中删除以下任何文件：

在索引中 但新提交的索引版本是否错误 然后，它会将以下文件添加到工作树中：

在新的提交中 但您的索引中还没有该版本 换句话说，索引不仅可以让您构建下一次提交，还可以记住工作树中的内容。如果您从以前的当前提交坏账转移到 新提交的当前提交faceacafe，并且您的索引显示您有文件zorg.py的deadc0de3版本，该版本随badc0ffee一起提供，但新提交的faceacafe没有zorg.py，Git将删除zorg.py

要使所有这些都起作用，在更改索引之前，索引必须与当前索引匹配

奇特的GUI前端可能会对您隐藏或试图隐藏索引。这通常是一个错误，因为它是正确Git操作的核心

一些额外的旁注 上述内容掩盖了Git在您修改称为脏工作树或脏索引的文件时为您提供的关于签出提交的保护。假设您不这样做，您永远不会修改某些工作树文件，然后，故意或意外地，无法转移git添加和/或提交它们，您的索引将始终与当前提交相匹配。要更改提交，Git会更改索引中的文件；在此过程中，它会更改这些文件，并且只更改工作树中的文件

---

如果您故意设置一个脏索引和/或工作树，Git将尝试让您更改提交。只有当新提交中存储的文件版本与您弄脏的文件版本相同时，此操作才会成功。这正是因为Git只更新那些在新提交的索引中出错的文件。有关这方面的更多信息，请参阅。

哦。。。在回购协议中？他们还在那里。。。作为修订的一部分或许多修订的一部分，最有可能。如果您签出其中一个存在文件的修订版本，您将在签出过程中获得它们，因此它们位于repo中。现在，它们不在树枝的顶端吗？那我们就谈谈。如果您签出远程分支主机，文件是否存在？我已从主机repo中删除。这些东西都不见了。如果我从master同步我的分支或更新我的分支，则从master repo中删除的文件仍位于我的本地文件夹中。看起来我必须手动删除它们。你的git状态的输出是什么？我认为这里有一个语义问题。同步可能意味着大量的东西只是获取而没有合并，获取/合并，在另一个分支上工作时拉，在本地分支主节点上工作时拉，等等。我希望您尝试的是一些简单的东西，没有歧义：如果您没有这样做，请获取并签出远程分支主机，因为删除的文件已经在那里合并，并让我们知道文件是否会在您的FS上，它们不应该在那里；我正在查看MASTER和一个我刚刚提交给MASTER的文件，其中包含我所做的更改。然后在GitHub桌面中，我从MASTER创建了一个新分支。然后我将其发布到remote，这就是GitHub桌面选项的读取方式。之后，我会在web视图中看到我的新分支。该url用于主回购协议。分支计数增加了。我点击查看所有分支；我看到了我的新的。然后我看到了树枝。我对文件所做的更改不在那里。哇！这个Git的东西对我不起作用。注意，我没有使用任何命令行命令。我使用GitHub桌面完成所有这些。因此，澄清一下，您是说Git在从指向本地文件系统的存储库中删除文件后不会从本地文件系统中删除这些文件吗？如果这是真的，很高兴知道。好的。。。它确实会删除文件。我想我遇到了一个延迟，因为删除了大量的文件，而且我的wifi连接速度很慢。大约30分钟后，在从Master更新然后同步之后，我注意到在git存储库Master和branch的WEB视图中，在Master和branch的GitHub桌面视图中，以及在我的本地文件系统上，删除的文件都不见了。是的，即使是在我的本地文件系统被其他开发人员删除后。信息太多。。。存储库工具不应该这么复杂。我在做一些很简单的事情。。。更改文件，提交请求。其他人批准并合并。同时，在我的本地文件系统上，对我更改的文件的更改以某种方式被恢复。哇，对不起，但版本控制并不是那么简单。你可以用它做一些简单的事情，但是当它出了问题，而且很明显，它出了问题，你必须至少理解一些基本元素来解决问题，因为版本控制本身并不是那么简单，分布式系统甚至不那么简单，你把两者混为一谈。这可能不是你正在做的事情造成的问题，但问题是，你想修复它吗？我的意思是，它的使用应该非常复杂。当然，在引擎盖下，在Git，甚至在SVN，可能会有很多事情发生。但与Git相比，SVN使用起来很简单。不幸的是，我被迫使用Git。我永远不会推荐它。是的，SVN有一个中央服务器，这会带来很多复杂性。当然，这也有其自身的缺点。