这似乎是一个显而易见的问题，但我在任何地方都找不到需要的答案。
我的本地计算机上有一个文件夹。我想使用Git在本地进行跟踪。
当我推送到GitHub时，我不想跟踪/推送该文件夹。
这可能吗/我该怎么做？
答案 0 :(得分：2)
已跟踪，表示索引中的 。 1 这样只能跟踪文件，不是文件夹，因为Git不存储文件夹。 2
那么：“索引”到底是什么呢？嗯，这最终变得很复杂-索引具有许多不同的角色，在合并过程中使用了一个复杂的角色-但简单地说，在Git中，索引保存您的建议的下一次提交。
索引开始保存来自某些提交的所有文件的副本 3 。也就是说，您选择使用git checkout name或git checkout hash-id进行“检出”的提交。此 commit 包含一堆文件。 Git将所有这些文件 all 复制（请参阅脚注3）到索引中，然后再复制到您的工作树中。
工作树或工作树是您在Git中查看和 use 文件的位置。但是您的工作树中的文件实际上根本不在Git中！
Git保存的是 commits 。每个提交都有自己的唯一哈希ID。当您进行新的提交或任何人进行任何提交时，Git会分配提交自己新的唯一哈希ID的代码，从此以后，那个哈希ID表示那个提交。这些提交一旦完成就无法更改。它们是全有还是全无：您要么在Git中具有该哈希ID，在这种情况下，您就拥有那个提交，或者根本没有那个提交。
这使得归档非常适合归档：您或任何人曾经保存的每个文件的每个版本都可以用于将来检查或永远重复使用！ 4 为节省空间和其他好处原因是，它们以特殊的只读，仅Git压缩格式存储。只有Git本身可以提取，当然，由于是只读的，没有人可以更改。
因此，这意味着对于完成任何实际的 工作而言，提交本身是无用的。您必须在某个地方让Git 提取提交，以便您可以在上面和/或上面进行处理。
那个某处是您的工作树。
由于您的工作树是您的您的，因此您可以将Git 没有保存在任何提交中的文件粘贴到其中。您用git checkout选择一些提交，并让Git将其所有文件提取到您的工作树中，然后添加一些 other 文件，其中不是提交。 例如，在您的情况下，您首先创建一个名为drafts/的文件夹，然后在此drafts/文件夹中创建一个文件。现在有一些文件：
drafts/README或其他任何内容。根据定义，即未跟踪的文件。
如果您告诉Git通过将该文件复制到索引中来跟踪该文件，则该文件将在您的 next 提交中。并且，其名称为code_fodder said ，就是共享的 commits 。当您使用git push将Git连接到其他Git时，您的Git会将其部分或全部提交发送给他们的Git，即您拥有，没有，希望拥有的那些。您不能在此过程中选择文件。您要么向他们提交整个提交（包括其所有文件的完整快照），要么就不给他们。
这意味着对您问题的简短回答只是“否”。无法跟踪文件-这意味着文件会进入您每次提交的 new make –却将您的Git传递给另一个Git，而您不是进行的某些提交，其中不包含该文件。
虽然有更长的答案。您可以进行执行保存drafts/*文件的提交，而其他进行不保存保存的提交。然后，您可以小心地仅推送从未出现过drafts/*个文件 的提交链。
但是，如果您不小心推送了drafts/*文件要做出现的提交之一，则很难将其收回：Git将提交视为相当宝贵（请参阅脚注） 4）并倾向于将 all 提交给随之出现并提出要求的每个其他Git。也就是说，如果您不小心将提交提交给到GitHub，而又出现了其他人并向GitHub询问该存储库中的任何新提交，则其他人将获得此提交提交，现在您必须恳求其他人放弃。即使您让GitHub删除了意外提交，另一个人现在也有一个副本。
这也是一个很大的痛苦。如果您提交了{em> 中包含a123456...的{{1}}（一些大的丑陋哈希ID），并提交了drafts/file1.txt（其他一些不同的大丑陋的哈希ID） 没有里面有b789abc...，那么每次您从drafts/file1.txt切换到b789abc...时，Git都会删除 {{ 1}}来自索引和您的工作树。从a123456...切换回drafts/file1.txt时，Git会将文件从a123456...复制回索引和工作树中，这是必须的；您的索引将保留建议的 next 提交，并且您的工作树应该匹配，至少对于所有跟踪的文件都应匹配。
通常，正确的方法是拥有一个单独的Git存储库，您可以在其中存储这些内容。也就是说，在b789abc...内部，只需创建一个新的Git存储库。包含所有其他文件的外部Git将所有b789abc...文件留给内部Git。然后，您可以根本不将这个Git存储库交给其他任何人。如果您想让某个托管服务器保留一份副本，则可以单独进行复制，而不必让人们访问那里的单独存储库。
1 好，这意味着当我们指的是文件时。 Git有时还会说建立了一个分支来“跟踪”另一个分支。
2 发生的事情是，当Git遇到提交并且提交包含名为drafts/的文件时，Git告诉计算机创建名为drafts/*的文件< / em>。为此，如果计算机需要（显然是您需要的），Git将创建名为a/b/c.txt的文件夹，然后 create 在{{1}内名为a/b/c.txt的文件夹中，以便它可以在a内b内创建名为a的文件。但是对于其余的Git，这只是一个名为c.txt的文件。它从未保存“文件夹b”或“文件夹a”，仅保存了文件。
3 从技术上讲，索引为每个文件保存对内部Git blob对象的引用。但是，在此级别上，仅考虑索引就好像它拥有每个Git格式文件的副本一样，效果很好。
4 有可能 摆脱提交。实际上，这很容易，直到您自己进行以后的提交和/或其他人的提交，才使依赖于该提交的事情（在Git中表示“更多提交”）成为可能。然后，它变得更加困难。因此，提交是完全是只读的-没有人，没有东西，甚至Git都不能更改它们-但是，如果提交的内容不好，则可以停止使用它。如果您不使用它，并进行了设置，使您不能再次使用它，并且没有人可以使用它，Git最终会为您清理它。
答案 1 :(得分：1)
该文件夹是您存储库的一部分，或者不是。您推送完全提交，其中每个提交是特定时间您存储库中所有文件的状态。如果您将一个文件夹添加到您的仓库中并提交，那么它现在已成为您仓库的一部分。如果您将其推入，则无论您将其推到何处，它都可以到达。
以下是一些选项（可能还有其他选项）：
也许您可以解释用例，通常回购是一整套东西-例如，如果您不想推送它，那么听起来它不应该成为您回购的一部分（这是一个概括-因此听到您的用例将会很有趣）...
答案 2 :(得分：1)
没有明显的答案，因为git分支并不意味着这种方式。将本地分支推送到远程时，正是版本控制的目的。
如果要跟踪两组不同的文件（例如，一个分支（不包括文件夹）），则可以使用两个分支，一个分支仅保留在本地，而另一个则远程推送。通过执行此注释，您不会获得仅本地分支的任何备份副本。您可以制作一个脚本，使其提交到仅本地分支，也可以提交到该分支（不包括将被推送的文件夹）。