git reset后删除目录--hard @ {u}

Question

我从github克隆了一个空的repo（我们命名为repoA），并在本地在其中添加了一个目录（命名结果）（所以repoA / results）

然后我做了一个git add results将结果目录添加到仓库中。 然后git commit -m "add results directory" 。 终于git push

在推送过程中，由于文件太大而导致我出错，我忘记删除了：

Total 5660 (delta 2779), reused 0 (delta 0)
remote: Resolving deltas: 100% (2779/2779), done.
remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: error: Trace: 7b1b7d4f8a8e398ef7184a6410f06c66
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File results/quality/R1.linker.fastq is 360.01 MB; this exceeds GitHub's file size limit of 100.00 MB
To https://github.com/XXX/repoA.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: impossible de pousser des références vers 'https://github.com/XXX/repoA.git'

所以我在本地删除了大文件。 然后git commit -m "delete big file"我再次尝试git push但我有同样的错误。

我尝试git reset和git checkout没有影响。

然后我做了git reset --hard @{u}

HEAD is now at 78022b7 Initial commit

但是现在/ results目录从我的计算机上消失了，并且没有在github上推送...有什么办法可以修复我的（愚蠢的）错误。 这些结果对我来说很有价值。

非常感谢

编辑

如建议我做了git reset 2f6116c ：

Modifications non indexées après reset :
D   results/benchmarkBlast/benchmarkBlast.R
D   results/benchmarkBlast/benchmark_blast_bowtie_01092017.jpg
D   results/benchmarkBlast/benchmark_blast_bowtie_01092017.pdf
D   results/benchmarkBlast/bowtie2_10000000_1_LTR.txt
D   results/benchmarkBlast/results/BLV/blast_1000000_10_10_BLV.txt
D   results/benchmarkBlast/results/BLV/blast_1000000_10_1_BLV.txt
D   results/benchmarkBlast/results/BLV/blast_1000000_10_2_BLV.txt
etc..

仍然没有我的目录？ D图形/基准冲击/结果/BLV/blast_1000000_10_3_BLV.txt

编辑

我通过做解决：

git reset -- results
git checkout -- results

Answer 1

TL; DR：新建一个分支名称以恢复您现有的提交

您可以使用git branch做到这一点。

详细说明

1. “不要惊慌” :-)

2. 意识到在Git中的提交是一个永久性的，不可更改的快照，它是您在Git中称为索引 ， 暂存区或缓存 （同一词的三个词）的所有内容的快照。

每个提交都会记住其先前的（或父 ）提交。 您进行了两次提交（可能在创建存储库期间通过GitHub提交了一次，但是效果是相同的）。 第一个没有父级，因为它没有父级：这是第一次提交。 （我们将此提交称为根提交。）

然后，您进行了第二次提交，但是由于此提交具有先前的提交，因此Git使得第二次提交使用第一个提交作为其父提交。 如果我们将第一个提交A而不是它的实际名称称为A而不是它的实际名称， 78022b7...诸如78022b7...这样的一些难以理解的哈希ID，然后将其称为第二个提交B （而不是2f6116c... ），我们可以得出这样的情况：

A <-B

提交B （ 2f6116c... ）让Git查找提交A （ 78... ），因为B存储了A的ID。 但是Git需要某种方式来首先找到B ，因为它们的哈希ID与您进行提交的顺序没有关系。 这是像master这样的分支名称出现的地方：

A <-B   <-- master

我们说名称master 指向提交B ，因为它为我们找到了提交B

git reset所做的事情很复杂，但它始于移动分支名称

最初，您在存储库中有这两个提交， master指向B ，然后尝试git push失败。

然后，您运行git reset --hard @{u} 。 这完成了三件事，但是让我们首先担心第一件事：它移动了分支名称 。

提交是永久且不可更改的。 git reset不会影响提交，因为不会 。 但这确实会影响名称（在本例中为master因为名称不是永久的并且可以更改。

提交序列A<-B保留在您的存储库中，但让我们作一些不同的绘制，以便可以将master指向A ：

A   <-- master
 \
  B   [abandoned]

现在，如果我们是Git，我们首先查看master ，找到并显示提交A ，然后提交A是根提交（没有父项），因此我们停止。

提交B仍在其中，没有名称。 幸运的是，只要reflog条目保持存在（默认情况下至少为30天）， reflog （您现在已经看到）保存其哈希ID，并保存该哈希ID。

重置会执行一，二或三件事

记得上面我说过git reset --hard @{u}做过三件事。 移动分支名称只是这三个名称之一。

git reset可以完成的另外两件事，以及--hard可以做到的：

• 重新设置索引。

  最好将索引（也称为暂存区或缓存）描述为“ 下一次提交时将进行什么操作”。

• 重新设置工作树 。

  实际上，工作树是这些事情中唯一显而易见的事情：它是您进行工作的地方。 在工作树中，文件具有其通常的格式，并且所有正常计算机程序都可以使用它们。 索引和内部提交中的内容采用特殊的仅Git形式。

您只需做一件事就可以让Git停止： git reset --soft 。 这将移动分支名称，并且不会触及索引和工作树。

完成以下两项操作后，您可以停止Git： git reset --mixed 。 这将移动分支名称，并重新设置索引。

或者，您可以让Git做所有三件事： git reset --hard 。 这将移动分支名称，重新设置索引，并重新设置工作树。

您可能想拥有的是这样的东西：

A   <-- master
 \
  B   <-- recovery

这将为两个现有提交提供两个分支名称。

如果您当前有名称master指向提交A ，则只需添加一个新的分支名称recovery指向提交B ：

git branch recovery 2f6116c

会做到的。

如果名称master当前指向提交B ，则可以执行另一个git reset使其再次指向提交A 您可以创建名称recovery 第一 ，不必拼出B的哈希ID：

git branch recovery
git reset 78022b7

每次这样运行git reset ，都会将当前分支名称（ git status表明您所在的分支）移至给定的提交。 如果使用--mixed （默认设置），则还将重置索引。 如果使用--hard ，那么还将重置工作树。 但是，无论您提供什么提交哈希，都将移动当前分支名称以指向该提交。

提交者将自己留在原处，并且保持不变。 发生了什么变化：

• 您的分支机构名称；
• 您的索引/暂存区； 和
• 您的工作树。

只要有分支名称，您就可以使用git commit保存的所有内容永久不变地存储，只要您可以使用该分支名称查找该提交或引用日志条目，否则该废弃的提交仍然有效。 只有在reflog条目开始过期约一个月之后，被放弃的提交才真正消失。

重置实际上可以做更多的事情

我花了足够长的时间回答这个问题，才想到git reset -- results 。 这是git reset可以做的另一件事：它将当前分支名称“移动”到现在的位置，这没有任何作用，然后将一些特定的索引条目或条目重新设置为新的当前提交中的任何内容。 然后，您可以运行git checkout将索引条目提取到工作树中。

（您也可以直接从提交中提取内容，该提交首先复制到索引中，然后复制到工作树中。记住，Git始终在处理每个文件的三个副本是一个好主意： HEAD提交，一个在索引中，另一个在工作树中！）

Answer 2

• git reflog将给您完成的操作
• 从那里找到硬重置之前完成的操作哈希
• git reset <commithash>
• 如果由于未指向正确的操作哈希值而导致在删除文件时reset （如您的情况）使您返回，则可能需要执行git checkout -- . 为了恢复它们。