文章目录
- 修改文件
- 版本回退
- git reset语法规则
- 注意
- 撤销修改
- 情况1:工作区的代码还未add
- 情况2:工作区的代码已经add 但未commit
- 情况3:工作区的代码已经add 并且已经 commit
- 删除文件
修改文件
Git⽐其他版本控制系统设计得优秀,Git跟踪并管理的是修改,不是文件
何为修改?
新增了⼀⾏/删除了⼀⾏/更改了某些字符/删了⼀些⼜加了⼀些/创建⼀个新⽂件 也算修改
比如:将ReadMe⽂件进⾏⼀次修改
那么此时仓库中的ReadMe和我们⼯作区的ReadMe是不同的,可以使用git status
查看仓库的状态,查看在你上次提交之后是否有对⽂件进⾏再次修改
上⾯的结果告诉我们,ReadMe被修改过了,但还没有完成添加与提交。⽬前,我们只知道⽂件被修改了,如果能知道具体哪些地⽅被修改了就更好了。
- 可以使用
git diff 文件名
命令显示暂存区和工作区文件的差异,显示的格式正是Unix通用的diff格式 - 也可以使用
git diff HEAD -- 文件名
:查看版本库和⼯作区文件的区别
此时git add之后,然后再使用git commit
版本回退
Git能够管理⽂件的历史版本,这也是版本控制器重要的能⼒。如果有⼀天你发现之前的⼯作做的出现了很⼤的问题,需要在某个特定的历史版本重新开始,这个时候,就需要版本回退的功能。可以使用git reset
命令用于版本回退,可以指定退回某⼀次提交的版本
注意:回退”本质是要将版本库中的内容进行回退,工作区或暂存区是否回退由命令参数决定 ,也就是说不管使用什么参数,版本库的内容是一定会回退的
git reset语法规则
git reset [--soft 或者 --mixed 或者 --hard] [HEAD]
--mixed
:是默认选项,使⽤时可以不⽤带该参数。该参数将暂存区的内容退回为指定提交版本内容,⼯作区⽂件保持不变
--soft
:该选项对于⼯作区和暂存区的内容都不变,只是将版本库回退到某个指定版本
--hard
:该选项将暂存区与⼯作区都退回到指定版本
- 注意!!!!!:如果⼯作区有未提交的代码时不要使用
--hard
选项,因为此时工作区会回滚,而没有提交的代码就再也找不回了,所以使⽤该参数前⼀定要慎重
HEAD说明:
- 可直接写成commit id(版本号),表示指定退回的版本
- HEAD 表示当前master最新版本
方式1:
-
HEAD^ 表示上⼀个版本
-
HEAD^^ 上上⼀个版本
-
以此类推…
方式2:
HEAD~0
表示当前版本HEAD~1
表示上⼀个版本- 以此类推…
例子:更新3个版本的test文件,并分别进⾏3次提交
查看历史提交记录
假设在提交完version3后,发现version3编写错误,想回退到version2,此时的做法为:
- 在这⾥希望的是将工作区的内容也回退到到version2版本,所以需要使用
--hard
选项,
此时test文件的内容已经回退到version2了,再次⽤ git log
查看⼀下提交⽇志,发现 HEAD 指向了version2
但是现在如果我后悔了,想再回到version3怎么办? 此时可以继续使⽤git reset
命令回退到version3
版本,但是必须要拿到version3的版本号(commit id)去指定回退的版本,但是此时使用git log
并不能打印出version3的版本号,运⽓好的话我们可以从终端上去找找之前的记录,运⽓不好的话version3的版本号已经被搞丢了
git提供了一个git reflog
命令用户记录本地的每⼀次命令,就可以很方便的找到所有操作记录了
此时这个 4927c33
就是version3的版本号的一部分,git回退的时候也可以使用部分的来代表目标版本
注意
Git的版本回退速度非常快,因为Git在内部有个指向当前分⽀master的HEAD指针,在.git
目录下的 refs/heads/master
文件当中保存当前master分支的最新的版本号(commit id),当我们进行回退版本的时候,Git仅仅是给refs/heads/master
存储一个特定的版本号,可以简单理解成如下⽰意图:
撤销修改
例如:如果我们在我们的⼯作区写了很⻓时间代码,越写越写不下去,觉得⾃⼰写的实在是垃圾代码,想恢复到上⼀个版本
情况1:工作区的代码还未add
此时可以直接删掉你⽬前在⼯作区新增的代码。但是可能写了3天⼀直都没有提交代码,此时就很难删除新增的代码,当然了也可以使用git diff filename
看看差别再删,但是这样⼜要花3天时间删代码了,并且很⼤的概率还会改出bug
解决办法:可以使用git checkout -- 文件名
命令让⼯作区的对应文件回到最近⼀次add 或者 commit时的状态。切记:此时的 --
不能丢弃,否则该命令就是其它含义
情况2:工作区的代码已经add 但未commit
工作区的代码已经add到暂存区当中 ==>此时可以使用<font color='blue'>git reset
命令进行版本回退,
- 第一步:将暂存区的内容退回为指定的版本内容,而但⼯作区⽂件保持不变 ==>使用
--mixed
选项,而--mixed
是默认参数,所以可以省略 - 第二步:丢弃当前工作区的代码,回到最近⼀次add 或者 commit的状态
第一步:使用git reset --mixed file
回退暂存区的版本内容
第二步:使用git check -- 文件名
:丢弃该文件在⼯作区中的修改
情况3:工作区的代码已经add 并且已经 commit
此时:可以使用 git reset --hard HEAD^
将暂存区与⼯作区都回退到上一个版本,而版本库是肯定会回退的。此时HEAD^ :表示上⼀个版本。当然这是有前提的:还没有把本地版本库推送到远程,才能回退到上一个版本。并且使用git reset的时候,版本库是肯定会回退的
删除文件
对工作区的修改包括:在工作区新增, 删除,修改文件
下面例子的前提是: file文件已经add 和 commit,如果一个文件还没有进行add和commit就直接删除,那就不可能恢复了!
例子:删除file文件
直接使用rm删除是没有作用的, git status会⽴刻告诉你哪些⽂件被删除了
此时⼯作区和版本库的内容就不⼀致了,要删文件,除了要删⼯作区的⽂件,还要清除版本库的⽂件。当然了,有两种情况:
- case1:不小心删除了
此时可以使用git checkout --文件名
进行恢复,让⼯作区的对应文件回到最近⼀次add 或者 commit时的状态
- case2:确实要从版本库中删除该⽂件
使用rm只删除了⼯作区的⽂件,此时可以使用命令:git rm 文件名:将文件从暂存区和工作区中删除,并且执行命令之后还需要再次commit
现在,⽂件就从版本库和暂存区中被删除了