大家好，我是北军。gitstash和gitstashpop等命令用于搁置（隐藏）和恢复我们工作目录中的更改。在本教程中，我们将学习如何恢复Git中的隐藏更改。在工作目录中存储更改在我们的示例中，假设我们已经克隆了一个GitRepo。现在，让我们对README.md文件进行一些更改，只需在末尾添加一行，并检查我们的工作目录的状态。$gitstatusOnbranchmasterYourbranchisuptodatewith'origin/master'.Changesnotstagedforcommit:(use"gitadd..."toupdatewhatwillbecommitted)(使用"gitrestore...”以丢弃工作目录中的更改）修改：README.mdno更改已添加到提交（使用“gitadd”和/或“gitcommit-a”）在这里，我们可以使用gitstash命令暂时将我们的Revise.$gitstashSaved工作目录和索引状态master上的WIP：sdfkdsx更新的pom.xml现在，如果我们再次执行gitstatus，我们会看到我们的工作目录是干净的。$gitstatusOnbranchmaster你的分支是最新的'origin/master'。没有要提交的，工作树清理恢复隐藏的更改并找到哈希让我们看看如何恢复隐藏的更改并找到与隐藏相关的哈希值的提交。将隐藏的更改恢复到我们的工作目录我们可以像这样将隐藏的更改恢复到我们的工作目录。$gitstashpopOnbranchmasterYourbranchisuptodatewith'origin/master'.Changesnotstagedforcommit:(use"gitadd..."toupdatewhatwillbecommitted)(使用"gitrestore...”以丢弃工作目录中的更改）修改：README.mdno更改已添加到提交（使用“gitadd”和/或“gitcommit-a”）删除了引用...正如我们在最后一行中看到的这样，gitstashpop不仅会恢复隐藏的更改，还会删除对其相关提交的引用。在终端打开时定位哈希如果我们的终端仍然打开，我们可以很容易地找到执行gitstashpop后生成的哈希。在我们的例子中，最后一行显示的散列是59861637...。终端关闭后恢复哈希即使我们关闭了终端，我们仍然可以通过以下方式找到我们的哈希。$gitfsck--no-reflogCheckingobjectdirectories:100%(256/256),done.Checkingobjects:100%(302901/302901),done.commit598616...现在我们可以看到丢弃的仓库提交的hash。恢复废弃的存储库通常，一旦我们应用了一个存储库条目，我们就不需要它了。然而，在某些情况下，我们可能希望在丢弃存储库条目后检索它。例如，gitreset-hardHEAD将丢弃我??们工作目录中所有未提交的更改。在这种情况下，我们可能希望回忆起一些早期的隐藏修改，尽管它们已被丢弃。使用散列来恢复隐藏的内容使用散列来处理悬空提交，我们仍然有可能恢复更改。$gitstashapply59861637f...在分支master你的分支是最新的'origin/master'。未暂存提交的更改：（使用“gitadd...”更新将提交的内容）（使用"gitrestore..."todiscardchangesinworkingdirectory)modified:README.mdnochangesaddedtocommit(use"gitadd"and/or"gitcommit-a")我们可以看到我们的工作目录已恢复以前隐藏的更改。查找所有哈希提交如果我们没有准备好哈希，我们可以找到它。gitfsck--no-flog|awk'/commit/{print$3}'在这里，我们将-no-flog选项与awk结合起来，只为我们过滤掉哈希值。总结在这篇文章中，我们看到了gitstash是如何工作的，以及它如何在我们使用它时丢弃一个条目。当我们知道一个被丢弃的条目的哈希值时，我们仍然可以使用它，以及如何找到提交的哈希值。
