更改分支时不要删除 .gitignore 中的本地文件
Don't remove local file which is in .gitignore while change branch
我有一个名为 A 的分支，我创建了一些文件和文件夹，这些文件和文件夹在将它们推送到 repo 之前添加到 .gitignore 文件中。
我想在更改到不包含这些文件和文件夹的新分支 B 时将它们保留在我的编辑器中。
谁能帮我实现这个目标？
我试着逐点回答你。
I have a branch named A and I created some files and folders which added to the .gitignore file before pushing them into repo.
你说你在推送到远程之前忽略了一些文件和文件夹，所以你在本地将它们作为 untracked。对吗？
I wanna keep them in my editor while I change to the new branch B which doesn't contain these files and folders.
如果我在上一点中的回答是您有一些未跟踪的项目。在那种情况下，您可以自由切换分支而不会丢失它们，从而使它们在编辑器中保持打开状态。
Can anyone help me how to achieve this goal?
如果我的猜测是正确的，你应该简单地发出 git checkout B.
让我知道没关系。
编辑：
再试一次：
git stash save -u
git checkout B
git stash pop
在 .gitignore 中列出文件对 Git 是否删除它没有影响。这就是关于 that 的全部内容，但是您的问题的其余部分显示出对 Git 如何工作的大量混淆：
文件未存储在 b运行ches 中。文件存储在 commits.
文件未“推送到存储库”。回购或存储库是 提交 的集合。这些提交然后包含文件。 B运行ches——或者更准确地说，b运行ch names——帮助你（和Git）找到你认为特别有趣的特定提交因为某些原因。通常这个原因是“因为这是那个 b运行ch 的最新提交”，但重要的是要记住 b运行ch 名称只是定位那个特定的提交，并且还提供多一项服务（见下文）。
您在 工作树 中的文件实际上并不 在 Git 中。您的工作树 和 在您的编辑器中打开的文件正在由您的 OS 和您的编辑器处理。
检出一个提交，使用git checkout或git switch，意味着select一个提交成为当前提交。对于 是 当前提交的提交，Git 需要 提取其所有文件 。提交中的这些文件被复制到两个地方：
文件被复制到Git的索引AKA暂存区.这是同一事物的两个名称。 （它甚至还有一个名字，缓存，尽管现在已经过时了。）
这些文件也会被复制到您的 工作树 。
我们稍后会详细介绍其中的每一个。
要从当前提交切换到其他提交，Git 必须从 Git 的索引 AKA 暂存区中 删除 ，每个现在存在的文件。当 Git 删除每个这样的文件时，它也会删除您的工作树中的副本。
因此，您的 工作树 中将被成功 git checkout 或 git switch 删除的文件是 Git的索引。然后，这些文件将被您正在切换 到 的提交中的文件替换，然后成为您当前的提交：现在您的索引和工作树与新的当前提交匹配，而不是旧的当前提交。
你的工作树是你的，随心所欲。 某些 Git 命令，例如 git checkout 和 git reset , 告诉 Git 对你的工作树文件做一些事情，但在任何时候，你的工作树都是你计算机上的一个普通目录（或文件夹，如果你喜欢这个术语），包含普通文件。每个处理普通文件的普通计算机程序都处理这些文件。
存储在 Git 提交中的文件是特殊的：它们是 read-only、压缩的和 de-duplicated。只有 Git 可以 读取 它们，实际上什么都不能 覆盖 它们，甚至 Git 本身也不能。 de-duplication 方面很重要，因为 每次提交都会存储每个文件的完整副本 。但是如果你有 3000 个文件，并且连续提交 1000 次，每次只更改 一个 个文件，每次提交只是 re-uses 2999 个较早的文件。所以 1000 个新提交不会每次都添加 3000 个文件：它们只添加 一个 个文件，或者可能是零个文件。 （一个新的提交将文件恢复到它之前出现的样子，可以结束 re-using 来自一个或多个早期提交的旧文件，因此根本不使用 space 来存储文件——除了对于一些小的开销，就是这样。）
这种特殊的存储格式意味着 Git 的提交充当永久存档。 只要您有提交，您总是可以取回每个旧版本。但这也意味着它们 对完成任何新工作完全没用 因为它们 read-only! （即便如此，只有 Git 可以找到并阅读它们：它们在 .git/objects 目录中，以无法识别的形式称为 松散对象 和 打包对象.)
这就是为什么 Git 必须从 提交中提取文件 。以正常的日常形式提取的文件位于您的工作树中，因此您可以查看它们并对其进行处理。
但是，这并不能解释 Git 索引的必要性。事实上，其他版本控制系统没有索引 / staging-area（或者如果它们确实有类似的东西——大多数确实有，在内部——它们会保密，这样你就不必知道了).但是 Git 的原作者 Linus Torvalds 选择强迫你学习他指数。你真的必须这样做：你可以暂时不了解它而离开，但不知道它最终会咬你的屁股，因为像“哪些文件被删除”这样的问题。
那么：索引究竟是什么？它有多种作用，例如用于处理合并冲突。但是主要作用，也是我们在这里关注的作用，是 Git 的索引保存您的 提议的下一次提交 。在索引中，Git 存储了每个将进入 next 提交的文件。这些文件是 pre-compressed 和 pre-de-duplicated，因此它们已准备就绪。因为它们 是 pre-de-duplicated，所以它们开始不占用 space：它们是提交内容的副本，所以它们是重复的，所以他们 de-duplicated 离开了。
当你运行git add更新一个文件在Git的索引时，Git会在这点，读取工作树副本。 Git 将压缩它，准备好成为 Git 的内部对象之一，并检查它是否重复。如果它 是 副本，Git 更新索引副本以引用副本。如果它 不是 副本，Git 更新索引副本以引用新的 ready-to-commit 版本。无论哪种方式，文件现在都可以提交了。 提议的下一次提交现在不同了[=319=]，因为您在 Git 的索引中创建了一个（或多个）文件与工作树中的相应文件相匹配。
这意味着在任何时候，Git 的索引都会保存您建议的下一次提交。（当存在冲突时，此建议的下一次提交标记为“可以't commit this", 所以现在说它是提议的下一次提交可能有点夸张。但这仍然是 会 提交的， 如果你可以提交.)
当你做最后运行 git commit, Git:
- 打包其索引中的所有文件：这将是新快照；
- 添加 元数据 ，例如您的姓名和电子邮件地址以及当前日期和时间，以在新提交中使用；
- 实际上使那个新提交，current-at-the-moment提交作为这个新提交的父；然后
- 通过将新提交的新的、唯一的哈希 ID 写入 current b运行ch name[=292= 来切换 到 新提交].
这意味着提交行为使 新 提交 成为当前提交。它根据 Git 的索引 / the-staging-area / 你提议的下一次提交的内容进行提交：你现在提议的下一次提交 是 一个提交，并且提交和索引 / staging-area 匹配，就像它们通常在您第一次 签出 某些提交时所做的那样。 这是 b运行ch 名称的特殊功能： 在 b运行ch automatically 更新 b运行ch 名称中的哈希 ID，以便它继续是那个 b运行ch 上的 latest 提交。
要从 Git 的索引中 删除 文件而不更改提交，您可以使用 git rm。请注意，这会将文件从 Git 的索引 和 中从您的工作树中删除，因此它从两个地方都消失了。但是，您可以使用 git rm --cached：这会指示 Git 从 Git 的索引中删除文件，但不会从您的工作树中删除。无论哪种方式，建议的 next 提交不再有该文件。
这给我们带来了案例列表：Git 不会 从您的工作树中删除文件的时间，无论您是否打开它一些编辑器。
Non-removal 例
请记住，从 current 提交切换到某些 other（目标）提交的基本思想是 Git将：
- 从其索引和您的工作树中删除 当前 提交中的文件；
- 将来自 target 提交的文件插入其索引和您的工作树中。
由于 Git 有并公开了它的索引，Git 知道当前提交的哪些文件 出来了 的方法是查看它的索引指数。这意味着您可以 阻止 Git 删除文件 ，即使它确实来自此提交，通过将其从 Git 的索引中删除，而无需首先从你的工作树中删除它：
git rm --cached file.ext
既然文件 不在 Git 的索引中，Git 表示 工作树版本 是一个 未跟踪的文件 。实际上，这是未跟踪文件的定义。 未跟踪的文件是存在于您的工作树中但不在 Git 的索引中的文件。
这是smplest 方法，但它有几个注意事项：
你必须记住每次需要时运行 git rm --cached。如果有任何东西——比如成功的 git checkout——将 file.ext 的副本再次放入 Git 的索引中，现在它是 跟踪个文件。
你必须记住，如果文件在某个 commit 中，检查提交会将文件放回 Git 的索引中.这使得第 1 步成为必要。
其他人也必须记住所有这一切：如果他们有一个工作树，并且检查了一些提交，他们 Git 有一个索引跟踪 他们的 工作树文件。如果 他们 从此提交切换到其他提交，他们 Git 将删除 他们工作树副本也是如此。这只是从他们的角度重述的规则 1 和 2，但牢记这一点至关重要：仅仅因为 you 知道 运行 git rm --cached 不知道这并不意味着 他们 知道这样做。
这里还有一个特例。假设您要求 Git 从提交 a123456 切换到提交 b789abc。现在，这两个提交中的每一个都包含一组归档文件。进一步假设：
a123456（当前提交）中有一个 file.ext。b789abc（目标提交）也里面有一个file.ext。- 此外，这两个提交中的两个副本完全相同。
在这种情况下，从一个提交切换到另一个提交并不真的需要Git删除当前提交并放入另一个提交。事实上，如果工作树中的文件 匹配 Git 索引中的文件和当前提交中的文件。
所以Git不打扰。而且，因为 它不会打扰，这意味着您可以从一个提交切换到另一个提交，即使该文件在您的工作树中被“修改”了。这里的细节变得很棘手；如果您想阅读它们，请参阅 Checkout another branch when there are uncommitted changes on the current branch。
删除不会打扰一些编辑
有些编辑比其他编辑更聪明 and/or less-annoying。
假设您在工作树中打开一个文件并开始编辑它。然后某物或某人——Git 或不是——路过，出于某种原因，删除或以其他方式更改文件。但是您的编辑器打开了文件的副本！
您的编辑可能会注意到该文件已被删除或更改。如果是这样，它可能会自动 丢弃您所做的所有工作而不给您保存它的机会 。这是非常不友好，如果可能，您应该停止使用该编辑器。然后你会有一个编辑器，如果文件被删除，你仍然可以将它保存在某个地方（在你的工作树内部或外部；那部分取决于你和你的编辑器）。
更多关于 .gitignore
.gitignore 文件不是 要忽略的文件列表。因此，很明显 mis-named。但是正确的名字会很笨重。
我们已经提到 未跟踪的文件 是存在于您的工作树中但不在 Git 的索引中的文件 现在。这是怎么发生的？也许 Git 从当前提交中提取文件，然后你 运行 git rm --cached。也许文件 不是 在当前提交中，并且您最近自己创建了它并且没有 运行 git add。 无论如何发生，现在是真的：该文件存在于您的工作树中，但不在 Git 的索引中，因此未被跟踪。 运行 git status 将 将此文件的名称 列为未跟踪文件。
git status 命令应该有用。如果每次你 运行 它列出 50,000 个未跟踪的文件，以至于任何 有用的 信息都无法找到，那有什么好处？所以，Git 有办法让 git status 关闭一些未跟踪的文件。为此，您在 .gitignore 文件中列出这些文件的名称或“glob 模式”，如 *.o 或 *.pyc。 status 命令然后关闭这些。
git add 命令应该使用方便。您可以 运行 git add . 添加工作树中当前工作目录中的每个文件，以及该目录中文件夹中的所有文件。但是，如果这里有一堆未跟踪的文件应该 保持 未跟踪怎么办？这不是很有帮助。因此，要告诉 git add not 自动 en-masse 添加某些现有的未跟踪文件，您可以在 [=11= 中列出这些文件的名称或 glob 模式] 文件。然后 add 命令不会 auto-add 这些。
但是，如果名义上 .gitignore 编辑的文件 已经在 Git 的索引中、Git 将 不会忽略它 。因此，.gitignore 文件并不是真正要忽略 的文件。它应该命名为 .git-do-not-complain-about-these-files-if-they-are-untracked-and-if-they-are-untracked-do-not-auto-add-them-with-en-masse-git-add-operations-either-because-they-should-stay-untracked，或类似的名称。但是这个名字很荒谬，所以 .gitignore 它是。
底线
最后，从 tip-of-branch-A 处的提交 C1453（或其他）切换到提交 C9782（或其他） tip-of-branch-B 将更新 Git 的 index。所以你关心的是现在 Git 的索引中的内容，以及 branch-B 末尾的提交中的内容。当它更新 Git 的索引时，它也会更新工作树文件。
git checkout 和 git switch 命令通常对此非常有用：如果您有未提交的工作 在 这些文件中，并且 Git 将删除它们（从而破坏您未提交的工作），Git 将 告诉您 并中止 checkout/switch 操作。 Git 将删除文件而不抱怨 if 它们 committed。由于提交是永久性的（大多数情况下——通过大量的工作，您有时可以摆脱一些提交）和 read-only（完全），如果您在切换后需要返回文件，只需告诉 Git从另一个提交中提取一个或多个文件。
请注意 Git 还允许您创建 额外的工作树 。每个新添加的工作树都带有 自己单独的索引 / staging-area。这允许您有两个不同的提交，来自两个不同的 b运行ch 名称，签出到两个不同的工作树中。一棵工作树将是 on branch-A（如 git status 所示），一棵将是 on branch-B.
我有一个名为 A 的分支，我创建了一些文件和文件夹，这些文件和文件夹在将它们推送到 repo 之前添加到 .gitignore 文件中。
我想在更改到不包含这些文件和文件夹的新分支 B 时将它们保留在我的编辑器中。
谁能帮我实现这个目标？
我试着逐点回答你。
I have a branch named
Aand I created some files and folders which added to the.gitignorefile before pushing them into repo.
你说你在推送到远程之前忽略了一些文件和文件夹，所以你在本地将它们作为 untracked。对吗？
I wanna keep them in my editor while I change to the new branch
Bwhich doesn't contain these files and folders.
如果我在上一点中的回答是您有一些未跟踪的项目。在那种情况下，您可以自由切换分支而不会丢失它们，从而使它们在编辑器中保持打开状态。
Can anyone help me how to achieve this goal?
如果我的猜测是正确的，你应该简单地发出 git checkout B.
让我知道没关系。
编辑：
再试一次：
git stash save -u
git checkout B
git stash pop
在 .gitignore 中列出文件对 Git 是否删除它没有影响。这就是关于 that 的全部内容，但是您的问题的其余部分显示出对 Git 如何工作的大量混淆：
文件未存储在 b运行ches 中。文件存储在 commits.
文件未“推送到存储库”。回购或存储库是 提交 的集合。这些提交然后包含文件。 B运行ches——或者更准确地说，b运行ch names——帮助你（和Git）找到你认为特别有趣的特定提交因为某些原因。通常这个原因是“因为这是那个 b运行ch 的最新提交”，但重要的是要记住 b运行ch 名称只是定位那个特定的提交，并且还提供多一项服务（见下文）。
您在 工作树 中的文件实际上并不 在 Git 中。您的工作树 和 在您的编辑器中打开的文件正在由您的 OS 和您的编辑器处理。
检出一个提交，使用
git checkout或git switch，意味着select一个提交成为当前提交。对于 是 当前提交的提交，Git 需要 提取其所有文件 。提交中的这些文件被复制到两个地方：文件被复制到Git的索引AKA暂存区.这是同一事物的两个名称。 （它甚至还有一个名字，缓存，尽管现在已经过时了。）
这些文件也会被复制到您的 工作树 。
我们稍后会详细介绍其中的每一个。
要从当前提交切换到其他提交，Git 必须从 Git 的索引 AKA 暂存区中 删除 ，每个现在存在的文件。当 Git 删除每个这样的文件时，它也会删除您的工作树中的副本。
因此，您的 工作树 中将被成功 git checkout 或 git switch 删除的文件是 Git的索引。然后，这些文件将被您正在切换 到 的提交中的文件替换，然后成为您当前的提交：现在您的索引和工作树与新的当前提交匹配，而不是旧的当前提交。
你的工作树是你的，随心所欲。 某些 Git 命令，例如 git checkout 和 git reset , 告诉 Git 对你的工作树文件做一些事情，但在任何时候，你的工作树都是你计算机上的一个普通目录（或文件夹，如果你喜欢这个术语），包含普通文件。每个处理普通文件的普通计算机程序都处理这些文件。
存储在 Git 提交中的文件是特殊的：它们是 read-only、压缩的和 de-duplicated。只有 Git 可以 读取 它们，实际上什么都不能 覆盖 它们，甚至 Git 本身也不能。 de-duplication 方面很重要，因为 每次提交都会存储每个文件的完整副本 。但是如果你有 3000 个文件，并且连续提交 1000 次，每次只更改 一个 个文件，每次提交只是 re-uses 2999 个较早的文件。所以 1000 个新提交不会每次都添加 3000 个文件：它们只添加 一个 个文件，或者可能是零个文件。 （一个新的提交将文件恢复到它之前出现的样子，可以结束 re-using 来自一个或多个早期提交的旧文件，因此根本不使用 space 来存储文件——除了对于一些小的开销，就是这样。）
这种特殊的存储格式意味着 Git 的提交充当永久存档。 只要您有提交，您总是可以取回每个旧版本。但这也意味着它们 对完成任何新工作完全没用 因为它们 read-only! （即便如此，只有 Git 可以找到并阅读它们：它们在 .git/objects 目录中，以无法识别的形式称为 松散对象 和 打包对象.)
这就是为什么 Git 必须从 提交中提取文件 。以正常的日常形式提取的文件位于您的工作树中，因此您可以查看它们并对其进行处理。
但是，这并不能解释 Git 索引的必要性。事实上，其他版本控制系统没有索引 / staging-area（或者如果它们确实有类似的东西——大多数确实有，在内部——它们会保密，这样你就不必知道了).但是 Git 的原作者 Linus Torvalds 选择强迫你学习他指数。你真的必须这样做：你可以暂时不了解它而离开，但不知道它最终会咬你的屁股，因为像“哪些文件被删除”这样的问题。
那么：索引究竟是什么？它有多种作用，例如用于处理合并冲突。但是主要作用，也是我们在这里关注的作用，是 Git 的索引保存您的 提议的下一次提交 。在索引中，Git 存储了每个将进入 next 提交的文件。这些文件是 pre-compressed 和 pre-de-duplicated，因此它们已准备就绪。因为它们 是 pre-de-duplicated，所以它们开始不占用 space：它们是提交内容的副本，所以它们是重复的，所以他们 de-duplicated 离开了。
当你运行git add更新一个文件在Git的索引时，Git会在这点，读取工作树副本。 Git 将压缩它，准备好成为 Git 的内部对象之一，并检查它是否重复。如果它 是 副本，Git 更新索引副本以引用副本。如果它 不是 副本，Git 更新索引副本以引用新的 ready-to-commit 版本。无论哪种方式，文件现在都可以提交了。 提议的下一次提交现在不同了[=319=]，因为您在 Git 的索引中创建了一个（或多个）文件与工作树中的相应文件相匹配。
这意味着在任何时候，Git 的索引都会保存您建议的下一次提交。（当存在冲突时，此建议的下一次提交标记为“可以't commit this", 所以现在说它是提议的下一次提交可能有点夸张。但这仍然是 会 提交的， 如果你可以提交.)
当你做最后运行 git commit, Git:
- 打包其索引中的所有文件：这将是新快照；
- 添加 元数据 ，例如您的姓名和电子邮件地址以及当前日期和时间，以在新提交中使用；
- 实际上使那个新提交，current-at-the-moment提交作为这个新提交的父；然后
- 通过将新提交的新的、唯一的哈希 ID 写入 current b运行ch name[=292= 来切换 到 新提交].
这意味着提交行为使 新 提交 成为当前提交。它根据 Git 的索引 / the-staging-area / 你提议的下一次提交的内容进行提交：你现在提议的下一次提交 是 一个提交，并且提交和索引 / staging-area 匹配，就像它们通常在您第一次 签出 某些提交时所做的那样。 这是 b运行ch 名称的特殊功能： 在 b运行ch automatically 更新 b运行ch 名称中的哈希 ID，以便它继续是那个 b运行ch 上的 latest 提交。
要从 Git 的索引中 删除 文件而不更改提交，您可以使用 git rm。请注意，这会将文件从 Git 的索引 和 中从您的工作树中删除，因此它从两个地方都消失了。但是，您可以使用 git rm --cached：这会指示 Git 从 Git 的索引中删除文件，但不会从您的工作树中删除。无论哪种方式，建议的 next 提交不再有该文件。
这给我们带来了案例列表：Git 不会 从您的工作树中删除文件的时间，无论您是否打开它一些编辑器。
Non-removal 例
请记住，从 current 提交切换到某些 other（目标）提交的基本思想是 Git将：
- 从其索引和您的工作树中删除 当前 提交中的文件；
- 将来自 target 提交的文件插入其索引和您的工作树中。
由于 Git 有并公开了它的索引，Git 知道当前提交的哪些文件 出来了 的方法是查看它的索引指数。这意味着您可以 阻止 Git 删除文件 ，即使它确实来自此提交，通过将其从 Git 的索引中删除，而无需首先从你的工作树中删除它：
git rm --cached file.ext
既然文件 不在 Git 的索引中，Git 表示 工作树版本 是一个 未跟踪的文件 。实际上，这是未跟踪文件的定义。 未跟踪的文件是存在于您的工作树中但不在 Git 的索引中的文件。
这是smplest 方法，但它有几个注意事项：
你必须记住每次需要时运行
git rm --cached。如果有任何东西——比如成功的git checkout——将file.ext的副本再次放入 Git 的索引中，现在它是 跟踪个文件。你必须记住，如果文件在某个 commit 中，检查提交会将文件放回 Git 的索引中.这使得第 1 步成为必要。
其他人也必须记住所有这一切：如果他们有一个工作树，并且检查了一些提交，他们 Git 有一个索引跟踪 他们的 工作树文件。如果 他们 从此提交切换到其他提交，他们 Git 将删除 他们工作树副本也是如此。这只是从他们的角度重述的规则 1 和 2，但牢记这一点至关重要：仅仅因为 you 知道 运行
git rm --cached不知道这并不意味着 他们 知道这样做。
这里还有一个特例。假设您要求 Git 从提交 a123456 切换到提交 b789abc。现在，这两个提交中的每一个都包含一组归档文件。进一步假设：
a123456（当前提交）中有一个file.ext。b789abc（目标提交）也里面有一个file.ext。- 此外，这两个提交中的两个副本完全相同。
在这种情况下，从一个提交切换到另一个提交并不真的需要Git删除当前提交并放入另一个提交。事实上，如果工作树中的文件 匹配 Git 索引中的文件和当前提交中的文件。
所以Git不打扰。而且，因为 它不会打扰，这意味着您可以从一个提交切换到另一个提交，即使该文件在您的工作树中被“修改”了。这里的细节变得很棘手；如果您想阅读它们，请参阅 Checkout another branch when there are uncommitted changes on the current branch。
删除不会打扰一些编辑
有些编辑比其他编辑更聪明 and/or less-annoying。
假设您在工作树中打开一个文件并开始编辑它。然后某物或某人——Git 或不是——路过，出于某种原因，删除或以其他方式更改文件。但是您的编辑器打开了文件的副本！
您的编辑可能会注意到该文件已被删除或更改。如果是这样，它可能会自动 丢弃您所做的所有工作而不给您保存它的机会 。这是非常不友好，如果可能，您应该停止使用该编辑器。然后你会有一个编辑器，如果文件被删除，你仍然可以将它保存在某个地方（在你的工作树内部或外部；那部分取决于你和你的编辑器）。
更多关于 .gitignore
.gitignore 文件不是 要忽略的文件列表。因此，很明显 mis-named。但是正确的名字会很笨重。
我们已经提到 未跟踪的文件 是存在于您的工作树中但不在 Git 的索引中的文件 现在。这是怎么发生的？也许 Git 从当前提交中提取文件，然后你 运行 git rm --cached。也许文件 不是 在当前提交中，并且您最近自己创建了它并且没有 运行 git add。 无论如何发生，现在是真的：该文件存在于您的工作树中，但不在 Git 的索引中，因此未被跟踪。 运行 git status 将 将此文件的名称 列为未跟踪文件。
git status 命令应该有用。如果每次你 运行 它列出 50,000 个未跟踪的文件，以至于任何 有用的 信息都无法找到，那有什么好处？所以，Git 有办法让 git status 关闭一些未跟踪的文件。为此，您在 .gitignore 文件中列出这些文件的名称或“glob 模式”，如 *.o 或 *.pyc。 status 命令然后关闭这些。
git add 命令应该使用方便。您可以 运行 git add . 添加工作树中当前工作目录中的每个文件，以及该目录中文件夹中的所有文件。但是，如果这里有一堆未跟踪的文件应该 保持 未跟踪怎么办？这不是很有帮助。因此，要告诉 git add not 自动 en-masse 添加某些现有的未跟踪文件，您可以在 [=11= 中列出这些文件的名称或 glob 模式] 文件。然后 add 命令不会 auto-add 这些。
但是，如果名义上 .gitignore 编辑的文件 已经在 Git 的索引中、Git 将 不会忽略它 。因此，.gitignore 文件并不是真正要忽略 的文件。它应该命名为 .git-do-not-complain-about-these-files-if-they-are-untracked-and-if-they-are-untracked-do-not-auto-add-them-with-en-masse-git-add-operations-either-because-they-should-stay-untracked，或类似的名称。但是这个名字很荒谬，所以 .gitignore 它是。
底线
最后，从 tip-of-branch-A 处的提交 C1453（或其他）切换到提交 C9782（或其他） tip-of-branch-B 将更新 Git 的 index。所以你关心的是现在 Git 的索引中的内容，以及 branch-B 末尾的提交中的内容。当它更新 Git 的索引时，它也会更新工作树文件。
git checkout 和 git switch 命令通常对此非常有用：如果您有未提交的工作 在 这些文件中，并且 Git 将删除它们（从而破坏您未提交的工作），Git 将 告诉您 并中止 checkout/switch 操作。 Git 将删除文件而不抱怨 if 它们 committed。由于提交是永久性的（大多数情况下——通过大量的工作，您有时可以摆脱一些提交）和 read-only（完全），如果您在切换后需要返回文件，只需告诉 Git从另一个提交中提取一个或多个文件。
请注意 Git 还允许您创建 额外的工作树 。每个新添加的工作树都带有 自己单独的索引 / staging-area。这允许您有两个不同的提交，来自两个不同的 b运行ch 名称，签出到两个不同的工作树中。一棵工作树将是 on branch-A（如 git status 所示），一棵将是 on branch-B.