Git不会重写未跟踪的文件

我对git有意见

我所做的

git pull origin branch_name
git reset --hard origin/branch_name

昨晚深夜，我提交并推送了两份文件。但是已经很晚了，我没有注意到我没有添加一个小文件

所以今天早上在办公室，当我注意到它时，我决定重做这项工作（因为文件很小）。在那之后，我添加了更多的东西，这一次添加并成功地将其推到了remote

我想要什么

现在我在家里，有一个未跟踪的文件和远程存储库中的许多良好更改。我想用当前的更改覆盖我昨晚所做的，但是git并不在意

我尝试的

git pull origin branch_name
git reset --hard origin/branch_name

我可能只是去手动更新文件，添加它并重新提交，但我会觉得很愚蠢。很遗憾，我没有像预期的那样使用git

---

有什么帮助吗？

你的问题从根本上说有点奇怪，我稍后再谈。但是，您不应该期望Git对未跟踪的文件执行任何操作

未跟踪的文件和Git的索引 首先，我们应该定义：在Git中，未跟踪的文件是不在索引中的文件

好的，但是现在我们必须定义Git的索引是什么。索引至少有点神秘，因为没有简单的方法可以看到它；但是在Git中，Git知道并关心的每个文件都有三个副本。最后这句粗体字是了解未跟踪文件的关键。不过，重要的是要认识到，虽然Git总是有索引，但索引中的内容是临时的和可变的。（这与提交不同！）

Git知道的每个文件的一个副本就是当前提交中的副本。此文件副本无法更改，因为它存储在提交中，任何提交的任何部分都无法更改

同一文件的第二个副本现在位于Git的索引中。这个额外副本以Git用于所有文件的相同压缩形式存储。通常，它与当前提交中的完全相同。存储在Git中的重复文件，以Git自己的内部压缩形式，基本上不占用任何磁盘空间。因此，第二个副本不会占用额外的磁盘空间，但第二个副本的存在是Git了解该文件的方式

文件的第三个也是最后一个副本在您的工作树中。第三个副本不是Git的特殊内部Gitty形式。它占用的真实空间和它占用的空间一样多；它一点也不压缩。但这也意味着计算机上的所有其他程序，包括编辑器和编译器等，都可以处理该文件。（特殊的Git表单只对Git本身有用。）

git commit

生成索引的快照 这让我们回到什么是未跟踪文件：它是工作树中的任何文件，但现在不在索引中。此外，它让我们回到索引的一个关键目的，即：索引包含您下一次提交时将要提交的文件。

这就是为什么您必须始终

git add

文件：

git add somefile

将

somefile

的内容复制到存储在索引中的

somefile

版本中。文件现在位于索引中（如果不是以前的），并且与工作树版本匹配（如果不是以前的）。现在，下一个

git commit

将存储该文件的版本

通过运行

git commit

，您可以进行新的提交。新提交中的内容是此时索引中的内容。新提交成为当前提交；指数保持不变；现在索引中的每个文件都与当前提交中的文件副本完全匹配，因为这些文件是从索引中的副本创建的。但这只提交跟踪文件，只提交Git知道的文件

因为根据定义，未跟踪的文件不在索引中，所以Git不知道它。它不会进入下一个你将做出的承诺。它现在不在索引中，因此不会在任何新的提交中

一旦您将它添加到索引中，使它与索引中的所有其他文件连接，它就在那里，并且现在被跟踪。运行

git commit

将使其永久化，并作为新提交的一部分存储；新提交将成为当前提交，文件将继续位于索引中，因此将继续被跟踪

跟踪哪些文件？（再次） 显然，如果您创建一个新文件，然后

git将其添加到索引中并
git commit
，那么提交的文件集已经更改。以前是当前提交的旧提交可能只有几个文件：

$ ls
README  afile   bfile
$ git status
On branch master
nothing to commit, working tree clean
$ echo new file > nfile
$ git add nfile
$ git commit -m 'add new file'
[master 72536ab] add new file
 1 file changed, 1 insertion(+)
 create mode 100644 nfile

现在索引中有四个文件集，
README
，
afile
，
bfile
，和
nfile
。但对于上一次提交，情况并非如此。让我们来看看：

$ git checkout HEAD^
Note: checking out 'HEAD^'.
[snip]
HEAD is now at 311a932... initial
$ ls
README  afile   bfile

文件发生了什么事？它不见了！事实上，它已经从工作树和索引中消失了。但是它作为快照安全地存储在commit
72536ab…
中，这是分支
master
上的最后一次提交，并且是名称
master
指向的提交：

$ git log --all --decorate --oneline --graph
* 72536ab (master) add new file
* 311a932 (HEAD) initial

（这个存储库真的不是很有趣，因为它只有这两个提交）。如果我们再次签出
master
，
nfile
会重新出现：

文件
nfile
现在位于索引中，因此被跟踪

当我们从有
nfile
的提交切换到没有
nfile
的提交时，Git知道从索引和工作树中删除文件

此时，该文件根本不存在。没有“未追踪”的东西，只是不存在

当我们从一个类似于
311a932…
的提交切换到一个类似于
72536ab…的提交时
$ git rm --cached afile
rm 'afile'
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    afile

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        afile

git pull origin branch_name

$ git ls-remote origin

git reset --hard origin/branch_name

git clean -fx