当前位置:首页 » 网络管理 » git怎么恢复删除文件
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

git怎么恢复删除文件

发布时间: 2023-04-15 05:39:44

Ⅰ 如何回复在Git中误操作删除的文件

$ git checkout – readme.txt
checkout命令就是放弃当下在工作区中的修改,回复到之前的状态链山,如果删除的文件,一下子就找回来。
另外一种情况就是刚才做的修改,如果你对此文件也适用了checkout操作,对不起,您的修改内容就会被回滚。
这里来总结一下checkout的用法和作用:
* 一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
* 一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到衡纯暂存区后的状态。
在了解了git checkout的用法之后,就不用棚拦中担心无删除的文件找补回来的问题了。

Ⅱ git 恢复本地误删的文件或文件夹

如果不小心误删了某个文件或文件夹时,可以通过git操作来恢复。
1.git status
查看本地改动的状态,如下图所示,误删了坦正文件夹升友"approving"吵信槐 (文件"information.vue")

2.git reset HEAD 被删除的文件或文件夹

以这个为例,先后执行这两个:
git reset HEAD src/views/crm/components/approved/index.vue
git checkout src/views/crm/components/approved/index.vue
以下就是恢复的文件

Ⅲ git如何恢复本地删除的文件

直接从本地把文件checkout出来就可以了,用不着从远程服务器上基塌pull下来,因为,所有的历史版本你的本地都有的。 具体做法 git checkout file 同时恢备册复多个被删除的文件:仿锋宏

Ⅳ XCode某个文件被物理删除了git恢复方法

在XCode的项目树中删除一个文件,不小心点了 Move to Trash。

这样这个文件就被物理删除了,还好有 git 大法

绿色文字就是删除的记录,git其实自带智配枯能提示,上面那一行就是恢复的命令

执行完后,发现deleted信哗春息已不见了培芦洞

发现文件回来了。

Ⅳ git找回本地误删除的文件

首先git status查看状态

然后想要具体恢复那个文件,就可以依次执行如下两个命正芦搭令:

1、git reset HEAD   文件路径

2、git checkout 文件路径

然后被你误删的文件就举拿会成功找哗好回了。

Ⅵ Git:恢复一个已经在提交中被删除的文件

我的博客的源地址,希望大家照顾一岁返下~

这里要研究的问题是,如果我们在之前的某一个灶雀滑提交中删除了一个文件,如何使用git将此文件恢复出来。

首先我们要做的是找到当时删除的这个文件对应的提交。比较简便的方法是使用一些图形化的Git软件,可以直接浏览找到对应的提交。这隐腊些软件包括SourceTree,Github Desktop等。纯命令行的环境可以使用如下的命令:

在找到对应的提交后,使用如下命令:

注意一下,这里的 $commit 指的是对应的commit id。后面的 ~n 是git的一种语法,表明追溯某个提交的第 n 个祖先。详情可以参考 Git Treeishes Considered Awesome 。那这里的意思就是检出删除这个文件的提交的上一个提交(届时那个文件还存在)中的对应文件。

参考链接

Ⅶ git删除文件夹在回收站找不到

在主页上恢复即可。
1、电脑运行失易得数据恢复,在主页上选择“误删除烂塌文件”功能进入。
2、电脑运行失易得数据恢复,在主页上选择“误删除文件”功能进入。
3、扫描结束后,找到我们要恢复的文件,点击侍历散预览,确认文件能正常预览才可以恢复,确认无误老氏后,勾选要恢复的文件,点击恢复按钮,选择路径保存即可成功恢复到电脑上。

Ⅷ 已删除的文件如何恢复

如果数据丢失后,我们又对保存该文件的磁盘进行了写入操作,发生数据覆盖的直接后果是搜索不到丢失的文件或是恢复后的文件打不开、乱码、空白、系统提示已经损坏等。数据写入具有随机性,具体哪些文件被覆盖是不可控的,所以在数据被成功恢复之前应尽量避免一切写入操作。此外,我们还需要了解自己电脑里的硬盘是固态盘还是机械盘。由于固态硬盘默认自带并开启TRIM指令,此特性致使删除的文件难以恢复。从备份中扰指还原丢失的文件是最理想的文件恢复方式,但是很多用户没有备份数据的习惯。没有备份的时候,我们就需要借助数据恢复软件找回丢失的文件。这里提示一下大家,虽然文件在删除前是可以正常打开的,但这不代表丢失后文件一直是正常的。在不确定数据是唤李袜否被覆盖了以及是否有损坏的时候,可以先用软件搜索到文件后通过预览文件判断文件的可恢复性。以下分享电脑删除文件恢复具体过程(以嗨格式数据恢复大师为例):步骤1:首先在电脑中运行【嗨格式和激数据恢复大师】这个专业数据恢复软件,打开后就可以看到主页中有多个恢复功能,点击其中的“误删除恢复”功能;步骤2:选择好模式后,还需要选择被删除文件原来的保存位置,选好点击“开始扫描”按钮;步骤3:这样嗨格式数据恢复大师软件开始扫描电脑数据,扫描好找到并选中恢复文件,点击“恢复”就可以。

Ⅸ git底层原理以及丢失文件找回和坑爹案例(一招干没我2个月的项目)

为啥要写这篇文章呢?因为 2017-03-28日清 晨 的一次情趣使然的提交干掉了我2个月的项目。。。

为啥能干掉2个月的?因为是个人没事做着玩的所以2个月一直没提交过。

工作环境 是 win10+sourcetree+git+unreal工程

记得那是一个朦朦胧胧的清晨(雾霾),我兴奋的从床上跳了起来(我的项目终于告一段落)。我打开电脑,打开sourcetree提交一下以免夜长梦多。

我整理了文件并且对比了变化。把整理过的文件add了一下,然后成功的commit(都TMD的是错觉 sourcetree bug了根本没add成功)之后我点击了push。。然后sourcetree 提示了一堆异常,其中有一条叫我用终端执行  git reset --hard 理由是我的工作区有垃圾文件,叫我清空下!

我不由自主的考虑了一下,

听sourcetree的,你说执行就执行~

然后我打开了终端执行了那条命令之后突然感觉哪里不对

我打开工作目录发现git清空了我2个月的项目,什么都没有了,真TMD的干净。

然后我去网上搜索如何找回。发现了好多方法,猛塌比如git reflog 这样就能看见自己的所有commit

然后在 git reset  --hard 后面写上你想要的commit id  就能找到文件

然后我执行完 git reflog后 发现根本没有我最后的那次提交。突然间恍然大悟,刚刚sourcetree 可能bug了导致commit失败了

然后我发现了另一条命令 git fsck --lost-found  执行后会出现一堆文件 在 .git/lost-found  文件夹里 不过是这个样子的

网上老哥说了 用 git show 就能看见内容

原来 2进制的文件看不见

然后我再次发现了新命令 find .git/objects -type f | xargs ls -lt | sed 110q    q前面是你要打印的行

这个命令已经脱离git了,他是终端的一个 查找命令 就是查找 .git/objects 文件夹下的普通文件 按照时间排序后 打印在终端里 sed 110q 是你要打印多少行。

要看懂这个命令就需要了解git底层的工作原理

讲一下git 原理

GIT对象模型

SHA

所有用来表示项目历史信息的文件,是通过一个40个字符的(40-digit)“对象名”来索引的,对象名看起来像这样:



你会在Git里到处看到这种“40个字符”字符串。每一个“对象名”都是对“对象”内容做SHA1哈希计算得来的,(SHA1是一种密码学的哈希算法)。这样就意味着两个不同内容的对象不可能有相同的“对象名好拦”。

这样做会有几个好处:

Git只要比较对象名,就可以很快的判断两个对象是否相同枝袜圆。

因为在每个仓库(repository)的“对象名”的计算方法都完全一样,如果同样的内容存在两个不同的仓库中,就会存在相同的“对象名”下。

Git还可以通过检查对象内容的SHA1的哈希值和“对象名”是否相同,来判断对象内容是否正确。

对象

每个对象(object) 包括三个部分: 类型 , 大小 和 内容 。大小就是指内容的大小,内容取决于对象的类型,有四种类型的对象:"blob"、"tree"、 "commit" 和"tag"。

“blob” 用来存储文件数据,通常是一个文件。

“tree” 有点像一个目录,它管理一些 “tree” 或是 “blob” (就像文件和子目录)

一个 “commit” 只指向一个"tree",它用来标记项目某一个特定时间点的状态。它包括一些关于时间点的元数据,如时间戳、最近一次提交的作者、指向上次提交(commits)的指针等等。

一个 “tag” 是来标记某一个提交(commit) 的方法。

几乎所有的Git功能都是使用这四个简单的对象类型来完成的。它就像是在你本机的文件系统之上构建一个小的文件系统。

与SVN的区别

Git与你熟悉的大部分版本控制系统的差别是很大的。也许你熟悉Subversion、CVS、Perforce、Mercurial 等等,他们使用 “增量文件系统” (Delta Storage systems), 就是说它们存储每次提交(commit)之间的差异。Git正好与之相反,它会把你的每次提交的文件的全部内容(snapshot)都会记录下来。这会是在使用Git时的一个很重要的理念。

Blob对象

一个blob通常用来存储文件的内容.

你可以使用 git show 命令来查看一个blob对象里的内容。假设我们现在有一个Blob对象的SHA1哈希值,我们可以通过下面的的命令来查看内容:

$ git show 6ff87c4664

Note that the only valid version of the GPL as far as this project

is concerned is _this_ particular version of the license (ie v2, not

v2.2 or v3.x or whatever), unless explicitly otherwise stated.

...

一个"blob对象"就是一块二进制数据,它没有指向任何东西或有任何其它属性,甚至连文件名都没有.

因为blob对象内容全部都是数据,如两个文件在一个目录树(或是一个版本仓库)中有同样的数据内容,那么它们将会共享同一个blob对象。Blob对象和其所对应的文件所在路径、文件名是否改被更改都完全没有关系。

Tree 对象

一个tree对象有一串(bunch)指向blob对象或是其它tree对象的指针,它一般用来表示内容之间的目录层次关系。

git show 命令还可以用来查看tree对象,但是 git ls-tree 能让你看到更多的细节。如果我们有一个tree对象的SHA1哈希值,我们可以像下面一样来查看它:

$ git ls-tree fb3a8bdd0ce

100644 blob    .gitignore

100644 blob    .mailmap

100644 blob    COPYING

040000 tree    Documentation

100755 blob    GIT-VERSION-GEN

100644 blob    INSTALL

100644 blob    Makefile

100644 blob    README

...

就如同你所见,一个tree对象包括一串(list)条目,每一个条目包括:mode、对象类型、SHA1值 和名字(这串条目是按名字排序的)。它用来表示一个目录树的内容。

一个tree对象可以指向(reference): 一个包含文件内容的blob对象, 也可以是其它包含某个子目录内容的其它tree对象. Tree对象、blob对象和其它所有的对象一样,都用其内容的SHA1哈希值来命名的;只有当两个tree对象的内容完全相同(包括其所指向所有子对象)时,它的名字才会一样,反之亦然。这样就能让Git仅仅通过比较两个相关的tree对象的名字是否相同,来快速的判断其内容是否不同。

(注意:在submoles里,trees对象也可以指向commits对象. 请参见 Submoles 章节)

注意:所有的文件的mode位都是644 或 755,这意味着Git只关心文件的可执行位.

Commit对象

"commit对象"指向一个"tree对象", 并且带有相关的描述信息.

你可以用 --pretty=raw 参数来配合 git show 或 git log 去查看某个提交(commit):

$ git show -s --pretty=raw 2be7fcb476

commit

tree

parent

author Dave Watson  1187576872 -0400

committer Junio C Hamano  1187591163 -0700

Fix misspelling of 'suppress' in docs

Signed-off-by: Junio C Hamano

你可以看到, 一个提交(commit)由以下的部分组成:

一个 tree 对象: tree对象的SHA1签名, 代表着目录在某一时间点的内容.

父对象 (parent(s)): 提交(commit)的SHA1签名代表着当前提交前一步的项目历史. 上面的那个例子就只有一个父对象; 合并的提交(merge commits)可能会有不只一个父对象. 如果一个提交没有父对象, 那么我们就叫它“根提交"(root commit), 它就代表着项目最初的一个版本(revision). 每个项目必须有至少有一个“根提交"(root commit). 一个项目可能有多个"根提交“,虽然这并不常见(这不是好的作法).

作者 : 做了此次修改的人的名字,还有修改日期.

提交者 (committer): 实际创建提交(commit)的人的名字, 同时也带有提交日期. TA可能会和作者不是同一个人; 例如作者写一个补丁(patch)并把它用邮件发给提交者, 由他来创建提交(commit).

- 注释 用来描述此次提交.

注意: 一个提交(commit)本身并没有包括任何信息来说明其做了哪些修改; 所有的修改(changes)都是通过与父提交(parents)的内容比较而得出的. 值得一提的是, 尽管git可以检测到文件内容不变而路径改变的情况, 但是它不会去显式(explicitly)的记录文件的更名操作.(你可以看一下 git diff 的 -M参数的用法)

一般用 git commit 来创建一个提交(commit), 这个提交(commit)的父对象一般是当前分支(current HEAD),同时把存储在当前索引(index)的内容全部提交.

对象模型

现在我们已经了解了3种主要对象类型(blob, tree 和 commit), 好现在就让我们大概了解一下它们怎么组合到一起的.

如果我们一个小项目, 有如下的目录结构:

$>tree

.

|-- README

`-- lib

|-- inc

|   `-- tricks.rb

`-- mylib.rb

2 directories, 3 files

如果我们把它提交(commit)到一个Git仓库中, 在Git中它们也许看起来就如下图:

你可以看到: 每个目录都创建了 tree对象 (包括根目录), 每个文件都创建了一个对应的 blob对象 . 最后有一个 commit对象 来指向根tree对象(root of trees), 这样我们就可以追踪项目每一项提交内容.

标签对象

一个标签对象包括一个对象名(译者注:就是SHA1签名), 对象类型, 标签名, 标签创建人的名字("tagger"), 还有一条可能包含有签名(signature)的消息. 你可以用 git cat-file 命令来查看这些信息:

$ git cat-file tag v1.5.0

object

type commit

tag v1.5.0

tagger Junio C Hamano  1171411200 +0000

GIT 1.5.0

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)



nLE/L9aUXdWeTFPron96DLA=

=2E+0

-----END PGP SIGNATURE-----

点击 git tag , 可以了解如何创建和验证标签对象. (注意: git tag 同样也可以用来创建 "轻量级的标签"(lightweight tags), 但它们并不是标签对象, 而只一些以 "refs/tags/" 开头的引用罢了).

然后我从这一堆文件里整理出了 tree文件 并且总结出了规律

运行  find .git/objects -tpe f | xargs ls -lt | sed 100q 后会得到最近改动的100个文件

-r--r--r-- 1 qipaworld 197608     57103 3月  25 07:23 .git/objects/31/  文件以这种形式显示在终端里

git cat-file -t 31 就能看见文件类型   把最后一个/去掉 复制从objects/ 后面的所有东西放在-t后面

然后找到tree类型的文件

每个红框框选的区域里的类型应该是同一种,选一个cat 一下看看就行了

找到tree后 git cat-file -p ^{tree}

就能看见tree里面的结构

然后就能知道 哪个blob对应哪个文件了。是不是很屌?

我搞了一晚上终于找到了某个tree并且跟到了文件目录。然后发现并没有我的项目文件,当时已经是半夜12点多了,我静静的看着屏幕

我连add都没成功就提示我commit成功了

以后谁叫你 reset --hard你就干他,别问我为什么

最终结果就是项目消失了,但是还好unreal 有自动保存功能,而自动保存的文件目录被我加到了git忽略列表里。找回了一部分

最后加一些git常用命令

查看、添加、提交、删除、找回,重置修改文件

git help  # 显示command的help

git show # 显示某次提交的内容 git show $id

git co --  # 抛弃工作区修改

git co . # 抛弃工作区修改

git add  # 将工作文件修改提交到本地暂存区

git add . # 将所有修改过的工作文件提交暂存区

git rm  # 从版本库中删除文件

git rm  --cached # 从版本库中删除文件,但不删除文件

git reset  # 从暂存区恢复到工作文件

git reset -- . # 从暂存区恢复到工作文件

git reset --hard # 恢复最近一次提交过的状态,即放弃上次提交后的所有本次修改

git ci  git ci . git ci -a # 将git add, git rm和git ci等操作都合并在一起做git ci -am "some comments"

git ci --amend # 修改最后一次提交记录

git revert <$id> # 恢复某次提交的状态,恢复动作本身也创建次提交对象

git revert HEAD # 恢复最后一次提交的状态

查看文件diff

git diff  # 比较当前文件和暂存区文件差异 git diff

git diff  # 比较两次提交之间的差异

git diff .. # 在两个分支之间比较

git diff --staged # 比较暂存区和版本库差异

git diff --cached # 比较暂存区和版本库差异

git diff --stat # 仅仅比较统计信息

查看提交记录

git log git log  # 查看该文件每次提交记录

git log -p  # 查看每次详细修改内容的diff

git log -p -2 # 查看最近两次详细修改内容的diff

git log --stat #查看提交统计信息

tig

Mac上可以使用tig代替diff和log,brew install tig

Git 本地分支管理

查看、切换、创建和删除分支

git br -r # 查看远程分支

git br  # 创建新的分支

git br -v # 查看各个分支最后提交信息

git br --merged # 查看已经被合并到当前分支的分支

git br --no-merged # 查看尚未被合并到当前分支的分支

git co  # 切换到某个分支

git co -b  # 创建新的分支,并且切换过去

git co -b   # 基于branch创建新的new_branch

git co $id # 把某次历史提交记录checkout出来,但无分支信息,切换到其他分支会自动删除

git co $id -b  # 把某次历史提交记录checkout出来,创建成一个分支

git br -d  # 删除某个分支

git br -D  # 强制删除某个分支 (未被合并的分支被删除的时候需要强制)

分支合并和rebase

git merge  # 将branch分支合并到当前分支

git merge origin/master --no-ff # 不要Fast-Foward合并,这样可以生成merge提交

git rebase master  # 将master rebase到branch,相当于: git co  && git rebase master && git co master && git merge

Git补丁管理(方便在多台机器上开发同步时用)

git diff > ../sync.patch # 生成补丁

git apply ../sync.patch # 打补丁

git apply --check ../sync.patch #测试补丁能否成功

Git暂存管理

git stash # 暂存

git stash list # 列所有stash

git stash apply # 恢复暂存的内容

git stash drop # 删除暂存区

Git远程分支管理

git pull # 抓取远程仓库所有分支更新并合并到本地

git pull --no-ff # 抓取远程仓库所有分支更新并合并到本地,不要快进合并

git fetch origin # 抓取远程仓库更新

git merge origin/master # 将远程主分支合并到本地当前分支

git co --track origin/branch # 跟踪某个远程分支创建相应的本地分支

git co -b  origin/ # 基于远程分支创建本地分支,功能同上

git push # push所有分支

git push origin master # 将本地主分支推到远程主分支

git push -u origin master # 将本地主分支推到远程(如无远程主分支则创建,用于初始化远程仓库)

git push origin  # 创建远程分支, origin是远程仓库名

git push origin : # 创建远程分支

git push origin : #先删除本地分支(git br -d ),然后再push删除远程分支

Git远程仓库管理

GitHub

git remote -v # 查看远程服务器地址和仓库名称

git remote show origin # 查看远程服务器仓库状态

git remote add origin git@ github:robbin/robbin_site.git # 添加远程仓库地址

git remote set-url origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址(用于修改远程仓库地址) git remote rm  # 删除远程仓库

创建远程仓库

git clone --bare robbin_site robbin_site.git # 用带版本的项目创建纯版本仓库

scp -r my_project.git git@ git.csdn.net:~ # 将纯仓库上传到服务器上

mkdir robbin_site.git && cd robbin_site.git && git --bare init # 在服务器创建纯仓库

git remote add origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址

git push -u origin master # 客户端首次提交

git push -u origin develop # 首次将本地develop分支提交到远程develop分支,并且track

git remote set-head origin master # 设置远程仓库的HEAD指向master分支

也可以命令设置跟踪远程库和本地库

git branch --set-upstream master origin/master

git branch --set-upstream develop origin/develop

点击这里可以看到作者的其他文章

Ⅹ git找回一个已经从远程仓库删除的文件

通过下面这个命令我们可以查看在哪个 commit 中删除了哪些文闭漏件。

执行这并首个命令后效果如下:

比如我想恢复 ic_selected.png 这个文件,我们可以看到删除该文件对应的 commit id :

接下来我们执行下面这个命令

这个命令会检出该绝态数 commit 的上一个提交中的文件,因为我们是在该 commit 中删除的文件,所以需要在上一个 commit 才能恢复出文件。

执行该命令后的效果

可以看到,执行完我们已经恢复了我们需要的文件。