企业🤖AI智能体构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
***** **版本控制** [TOC=6] # 3. 版本操作 ## 3.1 时光机穿梭 我们已经成功地添加并提交了一个readme.txt文件,现在,是时候继续工作了,于是,我们继续修改readme.txt文件,改成如下内容: ~~~ 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 学习时光机的使用。 ~~~ 现在,运行`git status`命令看看结果: ~~~ $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") ~~~ `git status`命令可以让我们时刻掌握仓库当前的状态,上面的命令输出告诉我们,`readme.txt`被修改过了,但还没有准备提交的修改。 虽然Git告诉我们`readme.txt`被修改了,但如果能看看具体修改了什么内容,自然是很好的。比如你休假两周从国外回来,第一天上班时,已经记不清上次怎么修改的`readme.txt`,所以,需要用`git diff`这个命令看看: ~~~ $ git diff readme.txt diff --git a/readme.txt b/readme.txt index c0c9a69..78d8036 100644 --- a/readme.txt +++ b/readme.txt @@ -1,3 +1,4 @@ 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 +学习时光机的使用。 ~~~ `git diff`顾名思义就是查看difference,显示的格式正是Unix通用的diff格式,可以从上面的命令输出看到,我们在最后一行添加了`学习时光机的使用。`一句话。 知道了对`readme.txt`作了什么修改后,再把它提交到仓库就放心多了,提交修改和提交新文件是一样的两步,第一步是`git add` ~~~ $ git add readme.txt ~~~ 同样没有任何输出。在执行第二步`git commit`之前,我们再运行`git status`看看当前仓库的状态: ~~~ $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: readme.txt ~~~ `git status`告诉我们,将要被提交的修改包括`readme.txt`,下一步,就可以放心地提交了: ~~~ $ git commit -m "add content" [master 5d25890] add content 1 file changed, 1 insertion(+) ~~~ 提交后,我们再用`git status`命令看看仓库的当前状态: ~~~ $ git status On branch master nothing to commit, working tree clean ~~~ Git告诉我们当前没有需要提交的修改,而且,工作目录是干净(working tree clean)的。 ## 3.2 小结 * 要随时掌握工作区的状态,使用`git status`命令。 * 如果`git status`告诉你有文件被修改过,用`git diff`可以查看修改内容。 ## 3.3 版本回退 现在,你已经学会了修改文件,然后把修改提交到Git版本库,现在,再练习一次,修改readme.txt文件如下: ~~~ 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 学习时光机的使用。 学习版本回退。 ~~~ 然后尝试提交: ~~~ $ git add readme.txt $ git commit -m "add content2" [master 513da34] add content2 1 file changed, 1 insertion(+) ~~~ 像这样,你不断对文件进行修改,然后不断提交修改到版本库里,就好比玩RPG游戏时,每通过一关就会自动把游戏状态存盘,如果某一关没过去,你还可以选择读取前一关的状态。有些时候,在打Boss之前,你会手动存盘,以便万一打Boss失败了,可以从最近的地方重新开始。Git也是一样,每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”,这个快照在Git中被称为`commit`。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个`commit`恢复,然后继续工作,而不是把几个月的工作成果全部丢失。 现在,我们回顾一下`readme.txt`文件一共有几个版本被提交到Git仓库里了: 版本1:wirte a readme file ~~~ 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 ~~~ 版本2:add content ~~~ 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 学习时光机的使用。 ~~~ 版本3:add content2 ~~~ 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 学习时光机的使用。 学习版本回退。 ~~~ 当然了,在实际工作中,我们脑子里怎么可能记得一个几千行的文件每次都改了什么内容,不然要版本控制系统干什么。版本控制系统肯定有某个命令可以告诉我们历史记录,在Git中,我们用`git log`命令查看: ~~~ $ git log commit 513da34713063be978f959507df8b17c62acdf6c (HEAD -> master) Author: zhaoliang <2668645098@qq.com> Date: Thu May 9 10:11:47 2019 +0800 add content2 commit 5d25890b8323df20f8a30a50701a51b2bbeb4856 Author: zhaoliang <2668645098@qq.com> Date: Thu May 9 10:03:47 2019 +0800 add content commit 30c0ddf65b656122d5383c86832b1e3ef7ee746c Author: zhaoliang <2668645098@qq.com> Date: Thu May 9 09:40:33 2019 +0800 wirte a readme file ~~~ `git log`命令显示从最近到最远的提交日志,我们可以看到3次提交,最近的一次是`add content2`,上一次是`add content`,最早的一次是`write a readme file`。 如果嫌输出信息太多,看得眼花缭乱的,可以试试加上`--pretty=oneline`参数: ~~~ $ git log --pretty=oneline 513da34713063be978f959507df8b17c62acdf6c (HEAD -> master) add content2 5d25890b8323df20f8a30a50701a51b2bbeb4856 add content 30c0ddf65b656122d5383c86832b1e3ef7ee746c wirte a readme file ~~~ 需要友情提示的是,你看到的一大串类似`513da3...`的是`commit id`(版本号),和SVN不一样,Git的`commit id`不是1,2,3……递增的数字,而是一个SHA1计算出来的一个非常大的数字,用十六进制表示,而且你看到的`commit id`和我的肯定不一样,以你自己的为准。为什么`commit id`需要用这么一大串数字表示呢?因为Git是分布式的版本控制系统,后面我们还要研究多人在同一个版本库里工作,如果大家都用1,2,3……作为版本号,那肯定就冲突了。 每提交一个新版本,实际上Git就会把它们自动串成一条时间线。如果使用可视化工具查看Git历史,就可以更清楚地看到提交历史的时间线: ![](https://box.kancloud.cn/14f39f1cfdff4cf5b240bdbda4d2ac57_2014x418.png) 好了,现在我们启动时光穿梭机,准备把`readme.txt`回退到上一个版本,也就是`add content`的那个版本,怎么做呢? 首先,Git必须知道当前版本是哪个版本,在Git中,用`HEAD`表示当前版本,也就是最新的提交`513da3...`(注意我的提交ID和你的肯定不一样),上一个版本就是`HEAD^`,上上一个版本就是`HEAD^^`,当然往上100个版本写100个`^`比较容易数不过来,所以写成`HEAD~100`。 现在,我们要把当前版本` add content2`回退到上一个版本`add content`,就可以使用`git reset`命令: ~~~ $ git reset --hard HEAD^ HEAD is now at 5d25890 add content ~~~ `--hard`参数有啥意义?这个后面再讲,现在你先放心使用。 看看`readme.txt`的内容是不是版本`add content`: ~~~ $ cat readme.txt 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 学习时光机的使用。 ~~~ 果然被还原了。 还可以继续回退到上一个版本`write a readme file`,不过且慢,然我们用`git log`再看看现在版本库的状态: ~~~ $ git log commit 5d25890b8323df20f8a30a50701a51b2bbeb4856 (HEAD -> master) Author: zhaoliang <2668645098@qq.com> Date: Thu May 9 10:03:47 2019 +0800 add content commit 30c0ddf65b656122d5383c86832b1e3ef7ee746c Author: zhaoliang <2668645098@qq.com> Date: Thu May 9 09:40:33 2019 +0800 wirte a readme file ~~~ 最新的那个版本`add content2`已经看不到了!好比你从21世纪坐时光穿梭机来到了19世纪,想再回去已经回不去了,肿么办? 办法其实还是有的,只要上面的命令行窗口还没有被关掉,你就可以顺着往上找啊找啊,找到那个`add content2`的`commit id`是`513da3...`,于是就可以指定回到未来的某个版本: ~~~ $ git reset --hard 513da3 HEAD is now at 513da34 add content2 ~~~ 版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。 再小心翼翼地看看`readme.txt`的内容: ~~~ $ cat readme.txt 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 学习时光机的使用。 学习版本回退。 ~~~ 果然,我胡汉三又回来了。 Git的版本回退速度非常快,因为Git在内部有个指向当前版本的`HEAD`指针,当你回退版本的时候,Git仅仅是把HEAD从指向`add content2`: ~~~ascii ┌────┐ │HEAD│ └────┘ │ └──> ○ add content2 │ ○ add content │ ○ write a readme file ~~~ 改为指向`add content`: ~~~ascii ┌────┐ │HEAD│ └────┘ │ │ ○ add content2 │ │ └──> ○ add content │ ○ write a readme file ~~~ 然后顺便把工作区的文件更新了。所以你让`HEAD`指向哪个版本号,你就把当前版本定位在哪。 现在,你回退到了某个版本,关掉了电脑,第二天早上就后悔了,想恢复到新版本怎么办?找不到新版本的`commit id`怎么办? 在Git中,总是有后悔药可以吃的。当你用`$ git reset --hard HEAD^`回退到`add content`版本时,再想恢复到`add content2`,就必须找到`add content2`的commit id。Git提供了一个命令`git reflog`用来记录你的每一次命令: ~~~ $ git reflog 513da34 (HEAD -> master) HEAD@{0}: reset: moving to 513da 5d25890 HEAD@{1}: reset: moving to HEAD^ 513da34 (HEAD -> master) HEAD@{2}: commit: add content2 5d25890 HEAD@{3}: commit: add content 30c0ddf HEAD@{4}: commit (initial): wirte a readme file ~~~ 终于舒了口气,从输出可知,`add content2`的commit id是`513da34`,现在,你又可以乘坐时光机回到未来了。 ## 3.4 小结 现在总结一下: * `HEAD`指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令`git reset --hard commit_id`。 * 穿梭前,用`git log`可以查看提交历史,以便确定要回退到哪个版本。 * 要重返未来,用`git reflog`查看命令历史,以便确定要回到未来的哪个版本。 ## 3.5 工作区和暂存区 Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。 先来看名词解释。 ### 工作区(Working Directory) 就是你在电脑里能看到的目录,比如我的`shopcode`文件夹就是一个工作区: ![](https://box.kancloud.cn/85464138eafb54524ab1ae71f1efcd7c_2002x1096.png) ### 版本库(Repository) 工作区有一个隐藏目录`.git`,这个不算工作区,而是Git的版本库。 Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支`master`,以及指向`master`的一个指针叫`HEAD`。 ![git-repo](https://www.liaoxuefeng.com/files/attachments/919020037470528/0) 分支和`HEAD`的概念我们后面再讲。 前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的: 第一步是用`git add`把文件添加进去,实际上就是把文件修改添加到暂存区; 第二步是用`git commit`提交更改,实际上就是把暂存区的所有内容提交到当前分支。 因为我们创建Git版本库时,Git自动为我们创建了唯一一个`master`分支,所以,现在,`git commit`就是往`master`分支上提交更改。 你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。 俗话说,实践出真知。现在,我们再练习一遍,先对`readme.txt`做个修改,比如加上一行内容: ~~~ 1612B 班 大家好吗? 非常好! 那好,我们来学习git添加文件。 学习时光机的使用。 学习版本回退。 学习暂存区。 ~~~ 然后,在工作区新增一个`LICENSE`文本文件(内容随便写)。 先用`git status`查看一下状态: ~~~ $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt Untracked files: (use "git add <file>..." to include in what will be committed) LICENSE no changes added to commit (use "git add" and/or "git commit -a") ~~~ Git非常清楚地告诉我们,`readme.txt`被修改了,而`LICENSE`还从来没有被添加过,所以它的状态是`Untracked`。 现在,使用两次命令`git add`,把`readme.txt`和`LICENSE`都添加后,用`git status`再查看一下: ~~~ $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: LICENSE modified: readme.txt ~~~ 现在,暂存区的状态就变成这样了: ![git-stage](https://www.liaoxuefeng.com/files/attachments/919020074026336/0) 所以,`git add`命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行`git commit`就可以一次性把暂存区的所有修改提交到分支。 ~~~ $ git commit -m "understand how stage works" [master d3b13e7] understand how stage works 2 files changed, 2 insertions(+) create mode 100644 LICENSE ~~~ 一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的: ~~~ $ git status On branch master nothing to commit, working tree clean ~~~ 现在版本库变成了这样,暂存区就没有任何内容了: ![git-stage-after-commit](https://www.liaoxuefeng.com/files/attachments/919020100829536/0) ## 3.6 小结 ![](https://box.kancloud.cn/9ec2f22e3c142ce9632e62dbfd1681d0_650x292.jpg) 暂存区是Git非常重要的概念,弄明白了暂存区,就弄明白了Git的很多操作到底干了什么。 没弄明白暂存区是怎么回事的童鞋,请向上滚动页面,再看一次。 跟上 ![](https://box.kancloud.cn/33a11cb79e81437dd3c9afe72398eda4_500x333.jpeg)