未跟踪的工作树文件?

时间:2018-04-12 14:31:40

标签: git github

我遇到一个问题,我尝试git pull来更新我的计算机上的分支从repo到我的计算机,我遇到了这个问题。

realloc()

我创建了一个.gitignore文件来忽略这个文件夹及其在回购时的推送和拉出内容,但我猜它不起作用。什么被认为是解决这个问题的最佳实践,所以每当我尝试git pull来更新分支时它都不会中止? (通过终端)

2 个答案:

答案 0 :(得分:1)

  

我创建了一个.gitignore文件来忽略这个文件夹及其在推送和拉出回购时的内容...

这不是.gitignore的含义或做法。我确信名称(即"忽略")是这里很多混淆的根源,因为.gitignore中列出的文件是实际上并没有忽略。不幸的是,实际上并没有一个好名字:它叫做#34; .git-don-t-keep-complaing-about-these-files-if-and-when-they-are-some-some -untracked"不完全是wieldy名称。

首先,让我们从Git对未跟踪文件的定义开始:当且仅当文件不在索引中时,文件才会被跟踪。该索引还有两个名称:它也称为临时区域,有时也称为缓存。这是因为它在Git中起着非常重要的作用,所以你必须始终至少模糊地意识到它。在某种程度上,它实际上比您的工作树更重要,因为它是每个新提交的来源。运行git commit打包当时索引中的任何内容,并将其用作源树快照。 (因此名称​​暂存区域:使用git add从工作树复制文件,覆盖索引中已有的副本,以便索引一个是更新,或者#34;分阶段#34;,用于新提交。)

现在,问题的根源在于提交 - 至少其中一些 - 实际上包含文件。请记住,Git不存储文件,它存储提交。确实提交拖拽文件 - 这是每次提交的一半以上 - 但操作单元,实际上是一次提交一次。 git pushgit fetch命令传输整个提交,而不是提交的一部分。 (正在运行git pull只会运行git fetch,然后是git merge;它实际上是失败的git merge步骤。)

如果提交包含文件,并且您检查了该提交,则还会检出该文件。这会将提交的文件版本复制到索引中。 checkout命令意味着从提交复制到索引,然后从索引复制到工作树。一旦文件在索引中,它就是跟踪的文件 - 与之相反未跟踪文件。永远不会忽略跟踪文件。

我们选择一个文件路径名作为示例,例如binaries/foo.exe

因此,假设您成功检出了binaries/foo.exe存在的提交。因此,Git将其写入索引和工作树:现在跟踪。假设您要做的下一件事是检查文件存在的其他提交。因此,Git 从索引和工作树中删除 binaries/foo.exe。现在文件没有被跟踪,但它也甚至没有,所以我们不会说binaries/foo.exe未被跟踪,即使它已经没有了真实的。

此时,您不拥有 binaries/foo.exe,但也许您的下一步是运行创建的构建流程 {{1 }}。 现在你的工作树中有 binaries/foo.exe但你的索引/登台区域没有。现在,我想,所有人都会同意binaries/foo.exe 未跟踪; 现在Git会说 - 或者我们应该说,抱怨 - binaries;foo.exe未跟踪。

现在 binaries/foo.exe个文件的内容开始发挥作用:现在工作树中存在.gitignore > index ,Git会不断抱怨它。您可以通过在binaries/foo.exe中列出binaries/foo.exebinaries/*来关闭Git。该文件仍然未跟踪,但现在也被忽略

.gitignore中列出binaries/foo.exe的另一个不错的效果是"添加所有内容"像.gitignore这样的命令将跳过未跟踪的文件,而不是将其添加到索引中,而不会抱怨。但是如果文件由于某种原因已经索引中,那么这个好的效果就会消失。它已被跟踪,git add .无效。

您可以从索引中删除文件:

.gitignore

这也会将其从工作树中删除。现在您可以进行 new 提交,并且由于新提交是由索引中的任何内容提交的,因此该提交中的文件。当然,缺点是它也会将其从工作树中删除。

您可以将其从索引中删除,然后将其保留在工作树中:

git rm binaries/foo.exe

现在,下一次提交不会拥有该文件,该文件现在是未跟踪文件,因为它位于工作树中,但不在索引中。 (它可能也可能不会被忽略。)但是这些都不会影响现有的提交,或其他人的提交 取消索引文件。如果git rm --cached binaries/foo.exe 的其他提交包含该文件,则git fetch会将该文件放入索引和工作树中,覆盖未跟踪的文件。

这也适用于git checkout:如果您有未跟踪的git merge,并且您要求合并的提交会添加 new binaries/foo.exe,Git需要将该文件复制到索引和工作树中。这将覆盖您现有的未跟踪文件。这是binaries/foo.exe列表的最后一个功能(或错误?)发挥作用的地方:有时,但并非总是如此,在.gitignore中列出文件会让Git随意< em> clobber 该文件。 (关于Git更令人抓狂的事情之一就是很难确切地说明这一点。)

无论如何,一般来说,解决方案是确保您想要未跟踪和忽略的任何文件都不会进入任何提交。如果已经已经进入某些提交,则只要您检查其中一个提交,就会跟踪该文件。这个问题没有很好的治疗方法。您可以调查&#34;重写历史记录&#34;替换具有不具有提交的文件的提交;或者您可以避免使用具有该文件的提交。当您遇到此类提交时,您可以移开未跟踪的文件,检查提交(跟踪文件),删除文件并提交(进行新的和改进的提交,否则文件更长),然后将文件移回。这不好玩,而且不是自动的,但确实有效。

答案 1 :(得分:0)

最佳做法是将文件重命名或移动到其他地方,因为git正试图将文件放在完全相同的位置。

根据您管理远程仓库的方式,您也可以从遥控器中删除binaries/*下的文件。