修改版本与回退
Git修改
我们修改一下readme.txt
文件:
然后我们使用git status
查看一下仓库的状态。
因为这个readme.txt受Git所管理,所以一旦修改之后,查看git仓库的状态就能显示出来修改记录(上图标红处),然后通过
git diff
来查看修改前后的差异:
从上面可以看到修改是多加了个"distributed"。
接着,我们再add
一下修改后的readme.txt
,然后在commit
之前查看一下仓库的状态
然后commit,并查看status,发现当前没有需要提交的修改,且工作目录是clean的
Git版本回退
我们可以通过git log
来查看git 日志,加上--pretty=oneline
可以更加简洁看到git历史日志。
从上图可以看到,每一条记录前都有一串数字+字母的号,这个就是commit id
。
然后我们通过git reset -- hard Head^
回退到前一个版本,Head^
表示回退一个版本,那么Head^^
表示回退两个版本,若想回退多个版本(举例10),就用Head~10
。
如果我们还想回到最新的版本,因为 append GPL的commit id为如下:
所以可指定回到未来的某个版本,版本号没必要写全,前几位(4位)就可以了,Git会自动去找。
当用 git reset --hard HEAD^
回退到add distributed版本时,再想恢复到append GPL,就必须找到append GPL的commit id。Git提供了一个命令git reflog
用来记录你的每一次命令:
工作区和暂存区
之前我们已经提到了这两个概念,接下来具体来了解一下这些概念。
这个就是我们的工作区:
而这个文件夹里有一个.git
就是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master
,以及指向master
的一个指针叫HEAD
。
我们试图去.git里找一下HEAD文件。
打开可以看到:
然后我们打开refs/heads/master
:
可以发现HEAD就是指向当前的Commit id。
而我们之前的两个操作add
和commit
的指示图如下:
add
:将文件修改添加到暂存区stage中。commit
:把暂存区的所有内容提交到当前分支。
当我们创建Git版本库时,Git会自动创建了唯一的一个master分支,所以,现在,git commit就是往master分支上提交更改。而需要提交的文件修改都放到暂存区中,再一次性commit这些修改。
我们修改一下readme.txt
,并增加一个LICENSE
文件,然后查看一下status。
可以发现LICENSE没有被添加,所以状态是Untracked
。然后我们add一下这两个文件,再查看一下status。
这样暂存区的状态变成了这样:
所以,git add
实际上是把要提交的所有修改放到暂存区(Stage),然后,执行git commit
就可以一次性把暂存区的所有修改提交到分支。
这样整个状态如下:
管理修改
Git管理的不是文件,而是修改。
修改readme.txt
为如下:
然后git add readme.txt
,并git status
:
再修改 readme.txt
如下:
然后 git commit
一下并查看状态:
从红色提示的字可以发现第二次的修改并没有提交,那么操作过程其实是这样的:
第一次修改 --> git add
–> 第二次修改 --> git commit
,所以只add了一次,所以第二次修改并没有放到暂存区,那么commit自然也不会把第二次的修改提交上去。
我们用 git diff HEAD --readme.txt
命令来查看工作区和版本库里面最新版本的区别。
若我们 add
一下,并再一次 commit
,便可以发现 diff
没有结果显示了:
撤销修改
当我们不注意修改成一个错误的内容,当在提交这个修改之前,我们可以很容易地纠正它。你可以删掉最后一行,手动把文件恢复到上一个版本的状态。如果用 git status
查看一下:
即我们可以用 git restore file
来丢弃工作区中的修改,但有两种情况:
readme.txt
从修改之后就没有被放到暂存区中,撤销修改就回到和版本库一模一样的状态。readme.txt
已经add
到暂存区中,又作了修改,撤销修改就回到添加到暂存区后的状态。
我们先修改一下 readme.txt
:
然后我们不 add
其到暂存区,尝试一下 restore
一下
然后就发现已经回到修改前的状态了。
但如果我们 add
这个修改,但庆幸没有commit,所以我们再 commit
之前查看一下状态:
可以发现使用 git restore --staged file
可以把暂存区的修改撤销掉(unstage),重新放回工作区。
然后再使用 git restore file
来撤销到修改前的工作区状态
可以发现修改已经没了。
总结一下:
- 没有add修改时,使用
git restore file
撤销修改; - 已经add修改,还未commit修改,使用
git restore --staged file
撤销修改到原来暂存区状态,然后再git restore file
撤销修改到原来工作区的状态。
删除文件
我们新建一个 test.txt
文件,然后 add, commit
,接着我们使用 rm test.txt
删除这个文件(即相当于直接在文件),再来查看一下状态:
可以发现,工作区和版本库不一致:因为已经add并commit了,所以版本库中有test.txt,而工作区没有了。
接下来有两种选择:
- 确认要删除,则把版本库中的也删除,使用
git rm
删除并git commit
:
- 删错了,因为版本库里还有呢,所以可以使用
git restore file
把误删的文件恢复到最新版本(即撤销删除这个修改)。