1.1 持续集成的基础概念
-
持续集成: 持续集成(Continuous integration),简称: CI 持续集成是频繁的(一天多次)将代码集成到主干部分,它的好处有两个.
- 1.发现错误,每完成一次更新,就会集成到主干中,以便于发现错误,定位错误,且比较容易.
- 2.防止分支大幅度偏离主干. 如果不是经常集成,主干又在不断更新,会导致后续集成难度变大,甚至难以集成.
- 3.持续集成,可以让产品快速迭代,同时保持高质量.
持续交付:
持续交付(Continuous delivery)指的是,频繁的将软件的新版本交给质量团队或者用户,以供评审,如果评审通过,代码就进入生产阶段.
持续交付可以看作是持续集成的下一步,他强调的是: 不管怎么更新,软件是随时随地的交付的,通过测试阶段无法直接上生产环境。
-
持续部署:
持续部署(continuous deployment) 是持续交付的下一步,指的是代码通过评审后,自动部署到生产环境.
持续部署的目标是: 代码在任何时候都是可部署的,可以进入生产阶段. 持续部署的前提是能自动化完成测试,构建,部署等步骤.
注意: 持续交付不等于持续集成,区别如下图:
1.2 持续集成的一般流程
持续集成的设计: 从代码提交到生产,他的过程分为以下步骤:
- 第一步: 开发者向代码仓库提交代码,所有后面的步骤,都始于本地代码的 第一次提交(commit)
- 第二步: 代码仓库对 commit操作配置好了钩子(hook),只要提交代码或者合并主干,就会启动自动化测试和构建(build)通过第一轮测试,代码就可以合并进主干,就算作可以交付了
- 第三步: 第二轮测试, 交付代码后,会先进行构建(bulid),然后才会进入第二轮测试,所谓构建,指的是将代码转换为可以运行的实际代码,比如安装依赖,配置各种资源(样式表,js脚本,图片)等等. "常见的构建工具: Jenkins Travis,codeship等"
- 第四步: 第三轮测试. 如果第二轮已经涵盖了所有测试内容,那么第三轮测试就可以省略,当然,这时构建步骤也要移到第一轮测试的前面.第三轮测试是全面测试,单元测试和集成测试都会走一遍,有条件的话也要做端对端测试,所有测试以自动化为主,少数无法自动化测试的需要人工测试.通过第三轮测试,当前代码就是一个可以直接部署的版本 (artifact). 将这个版本的所有文件打包存档,发布到生产服务器.生产将服务器打包文件,解包成本地的一个目录,再将运行的路径符号连接指向这个目录,然后重新启动应用,这里面的部署工具有:
Ansible,Chef,Puppet
等.- 版本回滚: 一旦当前版本发生问题,就要回滚到上一个版本的构建结果,最简单的就是修改一下符号链接,指向上一个版本的目录.
1.3 认识Devops
1.3.1 DevOps是啥?
DevOps 是 Development和Operations的组合. 突出重视软件开发人员和运维人员的沟通合作,通过自动化流程 来使得软件构建,测试,发布更加快捷,频繁,可靠 强调: Devops 是一个框架,一种方法论,并不是一套工具,他包括一系列的基本原则和实践.
1.3.2 为什么需要DevOps呢?
- 产品的迭代需要在显示工作中,我们用户新建立一个项目的时候,他并不知道他需要什么,只能进行简单的描述幻想.但是一旦程序设计人员设计出一个初稿产品后,他会告诉我们,他们不需要什么,这样我们产品需要反复迭代,而且过程可能会很曲折,面临这个我么提,我们有什么办法能过解决快速交付,灵活响应用户需求变化呢? 答案就是: Devops,因为DevOps是面向业务目标,助力业务成功的最佳实践.
- 技术革新 现在IT技术架构随系统不断更新迭代,从最初期服务都在一个系统中到现在的微服务架构集群,从手工到自动化部署,从单机时代到集群云平台时代.产品和技术都在不断更新.
1.3.3 DevOps涉及的技术
- 敏捷管理工具: Trello/Teambition/worktile/tower
- 产品与质量管理:confluence/禅道
- 代码仓库管理:git/gitlab/github
- 自动化构建脚本:Gradle/maven/SBT/ANT
- 虚拟化与容器化:VMware/virtualBox/Vagrant/Docker/Kubernetes
- 持续集成(ci) 持续部署(cd):jenkins/Hudson/Travis CI/Circle CI
- 监控工具:Zabbix/cacti/Nagois
- 日志管理:ELK
2.版本控制系统
2.1 为什么需要版本控制系统
将文件变化进行管理控制,能够自动生成备份,能够对比文件修改内容,能够及时回退.
常见版本控制系统: SVN(集中式版本控制系统) GIT(分布式版本控制系统)
2.2 Git 分布式版本控制系统
2.2.1 Git 简介
Git是一个开源的分布式版本控制系统,用于敏捷搞笑处理任何或大或小的项目. Git与常用的版本控制工具(CVS,Subversion)不同,它采用了分布式版本库的方式,不必服务器端软件支持.另外他是Linux教父 托瓦兹 写的. 重点是: 这是托瓦兹使用 "C语言" "两周时间" 编写的版本控制系统. 如今Git已经成为了常用的版本控制系统之一
2.2.2 Git 与 SVN的区别
- GIT是分布式的,SVN不是的,这是最核心的区别
- GIT把内容按照元数据方式存储的,SVN是按照文件形式的. 所有资源控制系统都是把文件元信息淫才在一个类似 .svn .cvs的文件夹里的.
- Git分支和SVN分支不同: SVN的分支表现形式就是一个目录
- GIT没有一个全局版本号,SVN有的, 这是GIT的缺点之一.
- GIT的内容完整性要优于SVN: GIT的内容存储使用的是 SHA-1 哈希算法,能够确保代码的完整性
2.2.3 Git 安装
# 推荐安装epel仓库
rpm -ivh http://mirrors.aliyun.com/epel/epel-release-latest-7.noarch.rpm
git安装准备注意:
#selinux 关闭
setenforce 0
getenforce
#系统时间设置准确
yum install -y ntpdate
ntpdate ntp1.aliyun.com
#防火墙关闭
systemctl stop firewalld #关闭防火墙
systemctl disable firewalld #开机不启动防火墙
#yum安装方式:
yum install -y git
#git版本查看
[root@node1 ~]# git --version
git version 1.8.3.1
2.2.4 Git配置
# 1. 用户配置[常用]
git config --global 用户配置
示例配置步骤:
git config --global user.name ddhh8023
git config --global user.email xganfeni@gmail.com
以上两句命令执行完毕后,当前文件夹就会多出一个 .gitconfig 文件
查看里面的内容:
[root@node1 ~]# cat .gitconfig
[user]
name = ddhh8023
email = xganfeni@gmail.com
除了这个方式,还有命令可以查看到配置项:
[root@node1 ~]# git config --list
user.name=ddhh8023
user.email=xganfeni@gmail.com
一般我们部署git需要执行的操作:
[root@node1 ~]# git config --global user.name ddhh8023 #创建个人信息
[root@node1 ~]# git config --global user.email xganfeni@gmail.com #创建个人信息,创建完成后会在家目录生成 .gitconfig 文件
# 2. 系统配置
git config --system [命令] 系统配置指令
# 3. 全局仓库配置
git config --local 仓库层面配置
git config --global -l #查看配置
# 3.1 修改全局配置
[root@node1 ~]# git config --global --edit
[user]
name = ddhh8023
email = xganfeni@gmail.com
--edit 可以简写为 -e
2.2.5 Git initialization
[root@node1 ~]# mkdir -p /root/git_test/
[root@node1 ~]# cd /root/git_test/
[root@node1 git_test]# git init
Initialized empty Git repository in /root/git_test/.git/
我们看看隐藏文件夹有什么:
[root@node1 .git]# ls -al
total 32
drwxr-xr-x 2 root root 4096 Oct 23 00:04 branches
-rw-r--r-- 1 root root 92 Oct 23 00:04 config
-rw-r--r-- 1 root root 73 Oct 23 00:04 description
-rw-r--r-- 1 root root 23 Oct 23 00:04 HEAD
drwxr-xr-x 2 root root 4096 Oct 23 00:04 hooks #钩子脚本
drwxr-xr-x 2 root root 4096 Oct 23 00:04 info
drwxr-xr-x 4 root root 4096 Oct 23 00:04 objects #git实际管理的数据
drwxr-xr-x 4 root root 4096 Oct 23 00:04 refs
总结: 拿到git后我们需要做的步骤:
1. 创建git目录 mkdir /master
cd /master
2. 初始化git目录 git init
3. 配置完成后会生成一个 .git 的目录 通过 ll -a 查看
4. 检查 .git 目录
[root@node1 master]# cd .git/
[root@node1 .git]# tree
.
├── branches
├── config
├── description
├── HEAD
├── hooks #---- 存储钩子脚本
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── post-update.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample
│ ├── prepare-commit-msg.sample
│ ├── pre-push.sample
│ ├── pre-rebase.sample
│ └── update.sample
├── info
│ └── exclude
├── objects #真实数据存在这个文件夹中.
│ ├── info
│ └── pack
└── refs
├── heads
└── tags
#第一次暂存文件后, 会生成一个index的文件作为暂存区.
2.2.6 Git repo
git仓库分为4个区域:
远程仓库 # 公共的远程仓库如: github gitlab
本地仓库 # .git文件夹,就是本地仓库
暂存区域 # 这个目录在第一次暂存文件就就会创建.git/index
工作目录 # 工作目录就是创建的目录
当文件在本地仓库后,文件增删改查都会被记录
git的四种状态:
Untracked : 未修改状态,未跟踪,就在工作目录中,没有被git管理(只出现在工作区)
Unmodified: 未修改状态,文件在本地仓库中.被跟踪 [出现在本地区域,出现在暂存区,工作区,本地仓库都有一份,数据也一致]
Modified: 如果在本地仓库中修改过,状态就会被改为 Modified状态. [受git管理的文件被修改了就是Modified状态]
Staged: 一个未被跟踪的文件,添加到暂存区后它的状态就是 Staged 状态
2.2.7 Git Zones
远程仓库 #[remote] 暂存区
本地仓库 #[Repository] add提交后会到仓库.
暂存区 #[index/staged] 临时存放改动过的文件或目录 commit提交后会同步到本地仓库
# 暂存区可以做 删除 修改 查看状态
工作目录 #[workspace] 存放项目代码的地方, 工作目录就是我们通过 git init 初始化的目录
百度的资料:
新建文件 ---> Untracked
使用add命令将新建的文件加入到暂存区 ---> Staged
使用commit命令将暂存区的文件提交到本地仓库 ---> Unmodified
如果对Unmodified状态的文件进行修改 ---> modified
如果对Unmodified状态的文件进行remove操作 ---> Untracked
git命令快速使用:
git add [文件名] 文件提交到暂存区
git rm --cached [文件名] 文件从暂存区移除
rm -f [文件名] 从本地删除文件
删除还有更快捷的方式,不用从暂存区删除然后删除本地文件:
git rm -f [文件名]
该命令是直接将暂存区和本地文件一起删除.
1. 首先初始化一个代码目录[git init]
2. 提交代码会首先放到暂存区[git add ] 暂存区就相当于 .git/ 目录下的文件.
该命令会让一个文件从未修改状态变为修改状态 从图中来看它会从Untracked状态转变为Staged状态.
git add * 可以将当前本地工作目录所有文件提交到"暂存区"
3. 暂存区[index]修改后会同步到本地仓库 [git commit -m "commit a"],提交后才会真正的被仓库管理,还可以使用:git rm --cached [文件名] 清除暂存区文件,移动回工作目录,并且暂存区也会清除 c 文件
通过示例来看:
[root@master master]# git rm --cached c
rm 'c'
[root@master master]# git status
...
...
# (use "git rm --cached <file>..." to unstage)
#
# new file: a
# new file: b
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# c
#可以看出 C 文件已经从暂存区移除.变成未跟踪状态,相当于回到工作目,录回到了初始状态.
除了清除缓存区文件还可以对缓存区文件进行修改名称: git mv [文件名] [新文件名]
4. 本地仓库
如果需要从暂存区删除,从本地也删除文件,可以直接使用 git rm -f [文件名]
2.2.8 Git 增删改查
git add a ## 把一个文件从本地工作目录提交到暂存区(./git/index目录中)
git status ##查看git仓库状态, 这是进入初始化好的git仓库后,第一次的时候就要检查这个仓库的状态,这是必备命令.
[root@node1 git_test]# git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)
# 你可以对这个仓库进行 创建,复制文件,或者使用 git add跟踪文件.
创建文件后继续检查:
[root@node1 git_test]# git status
# On branch master
#
# Initial commit
#
# Untracked files: ---# 新创建的文件,没有被git管理,所以在Untracked files中
# (use "git add <file>..." to include in what will be committed)
#
# a
# b
# c
nothing added to commit but untracked files present (use "git add" to track)
# 提交文件到暂存区:
[root@node1 git_test]# git add a ##提交新文件到暂存区
[root@node1 git_test]# git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: a ##这里会提示新的文件
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# b ##这里还是会显示未提交过的文件,未跟踪状态
# c
这上面的操作就是将一个文件从工作目录提交给暂存区
命令为: git add a
提交多个文件到暂存区:
git add . ##当前目录的所有文件
# 文件移出暂存区到本地目录:
git rm --cached [文件名] #移回提交到暂存区的文件到本地工作目录.
[root@node1 git_test]# git rm --cached c
rm 'c'
移动到暂存区后再次查看状态:
[root@node1 git_test]# git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: a
# new file: b
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# c #-----可以看到 c这个文件又重新变回了 Untracked 状态,存留在本地目录了
当你使用git status命令得到的结果是:
[root@master master]# git status
# On branch master
nothing to commit, working directory clean
说明你的 暂存区 本地仓库 本地工作目录 保存的文件都是一致的.且都有一份
# 删除 暂存区和工作目录中的文件.
1. 如果文件在暂存区 那么先要从暂存区移除 git rm --cached [文件名]
2. 然后删除文件 rm -f c
这样,这个文件就会被彻底删除.
# 同时删除工作目录和暂存区文件:
git rm -f c
结果:
[root@master master]# git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: 1.txt
# new file: a
# new file: b
#提交文件到本地git仓库:
[root@node1 git_test]# git commit -m "commit a"
[master (root-commit) a79daaf] commit a
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
create mode 100644 b
注意,只有把文件提交到本地git远程仓库,这个文件才会这正被git管理.
#改名
git中的改名相当于删除了原有文件,创建了一个新文件.改名后,需要删除暂存区文件
git rm --cached a
git也提供了一个改名命令
git mv [文件名] [新文件名]
# 提交文件到本地仓库并改名
git还可以使用 git commit -m "rename 1.txt to 2.txt"
整理知识: 本地工作目录 git add ----> 暂存区 git commit ----> 本地仓库 ---> 远程仓库 git add ----> git commit ---->本地仓库 #这样操作后,3个区域都保存了提交的文件,数据也一致 本地仓库删除了,暂存区删除了, git commit后,就会直接删除文件了. 不过还可以通过commit找回
流程整理:
- 创建一个git目录
- 通过 git init 初始化目录 [本地仓库]
- 创建文件
- git add 添加到暂存区 5. g
- it commit 提交到本地git仓库[快照]
2.2.9Git 快照与回退
1. 将暂存区恢复到本地工作目录.
2. 将本地仓库恢复到暂存区
3. 暂存区恢复到本地工作目录.
4. 跳转到某一次快照
1. 创建实验文件 33.txt
[root@master master]# touch xqf
[root@master master]# echo 888 > xqf #添加文件内容
[root@master master]# git add xqf #提交到暂存区
[root@master master]# echo 000 >> xqf #添加内容
[root@master master]# git diff xqf
[root@master master]# git diff xqf #对比文件,查看变化
diff --git a/xqf b/xqf
index dc6a988..c349552 100644
--- a/xqf
+++ b/xqf
@@ -1 +1,2 @@
888
+000 <<--- 添加了 000 这行
#现在问题,我添加了这一行我觉得多了我想回退到 000 这行
#做法:
[root@master master]# git checkout -- xqf #没有输出则证明正确.
#检查是否回退:
[root@master master]# cat xqf #可以看到 000 这一行消失了
888
#以上说的是回退一行,那要是很多行呢?
[root@master master]# echo 111 >> xqf
[root@master master]# echo 222 >> xqf
[root@master master]# git add .
2.2.9.1 回退的几种情况与回退方案:
了解: git快照会保存仓库的状态,在出现故障的时候通过状态来恢复以前的状态.
1. 第一种情况:
当在改动本地工作目录,暂存区和本地仓库没有改动,此时发现错了,需要改回.
解决: 通过暂存区来[覆盖]的方式恢复本地工作目录
暂存区 --> 本地工作目录
git checkout
2. 第二种情况:
在本地工作目录改好了,发现没问题就提交到了暂存区,当提交到暂存区后发现有问题,现在的状况是本地工作目录和暂存区数据都是错的,只有本地仓库是正确的.
解决方法: 本地仓库 -->覆盖 --> 暂存区, 暂存区 -->覆盖 -->本地工作目录.
本地仓库 --> 暂存区 --> 本地工作目录
3. 第三种情况:
已经对本地仓库进行修改了,自己也不知道自己做了什么,中间也有过commit提交暂存区操作.现在觉得有问题,但是又无法改回去.
解决办法: 记住一次正确的,直接回退到正确的.
2.2.9.2 回退模拟实战
1. 暂存区 -- > 本地工作目录 的回退操作
1. 第一种情况:
当在改动本地工作目录,暂存区和本地仓库没有改动,此时发现错了,需要改回.
解决: 通过暂存区来覆盖的方式恢复本地工作目录
暂存区 --> 本地工作目录
-----------------------------git回退操作---------------------------------
1. 配置git目录
mkdir /777
cd /777
2. 初始化git目录 git init
git init
3. 配置完成后会生成一个 .git 的目录 通过 ll -a 查看
[root@master 777]# ll -a
drwxr-xr-x 3 root root 18 Dec 9 16:54 .
dr-xr-xr-x. 18 root root 255 Dec 9 16:54 ..
drwxr-xr-x 7 root root 119 Dec 9 16:54 .git
4. 生成测试数据
[root@master 777]# echo aaa >a
[root@master 777]# echo bbb >>a
[root@master 777]# echo ccc >>a
[root@master 777]# git add a #提交数据
5. 提交后 在进行对比
[root@master 777]# echo ddd >a
[root@master 777]# git diff a
diff --git a/a b/a
index 1802a74..1d60b70 100644
--- a/a
+++ b/a
@@ -1,3 +1 @@
-aaa
-bbb
-ccc
+ddd ## 提示 ddd 被添加进去了
[root@master 777]# cat a #直接查看内容更直观的看到 ddd 已经添加进了a这个文件中.
aaa
bbb
ccc
ddd <----- ddd已经被添加进了文件中.
6. 回退[发现有错,不该添加ddd]
--------------------------------------------------------------------------------
[root@master 777]# git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: a
#
# 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: a
--------------------------------------------------------------------------------
发现帮助: use "git checkout -- <file>..." to discard changes in working directory
你可以通过使用 git checkout [文件名] 来回退操作.
6. 开始回退:
[root@master 777]# git checkout a #回退a这个文件.
[root@master 777]# cat a
aaa
bbb
ccc
#这里发现我们添加的 ddd 已经不存在文件中了
-----------------------------git回退操作---------------------------------
2. 暂存区 -- > 本地工作目录 的回退操作
本地工作目录设置为了 /777
[root@master 777]# touch a
[root@master 777]# echo "aaa" >a
[root@master 777]# echo "bbb" >>a
[root@master 777]# git add .
[root@master 777]# git commit -m "commit a"
[root@master 777]# git status
# On branch master
nothing to commit, working directory clean
## 以上为制造演示数据,可不看
[root@master 777]# cat a #现在 a 文件中已经有了 两行数据
aaa
bbb
[root@master 777]# echo "ccc" >>a #追加一行进去
[root@master 777]# 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: a
#
no changes added to commit (use "git add" and/or "git commit -a")
[root@master 777]# git add . #添加到暂存区
[root@master 777]# git diff --cached #对比数据
diff --git a/a b/a
index dbee026..1802a74 100644
--- a/a
+++ b/a
@@ -1,2 +1,3 @@
aaa
bbb
+ccc # 可以看出 ccc 是新增数据.
#通过 git status 来看:
[root@master 777]# git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: a
# 使用仓库状态覆盖暂存区:
[root@master 777]# git reset HEAD a
Unstaged changes after reset:
M a
[root@master 777]# cat a
aaa
bbb
ccc
[root@master 777]# git diff a #检查改动
diff --git a/a b/a
index dbee026..1802a74 100644
--- a/a
+++ b/a
@@ -1,2 +1,3 @@
aaa
bbb
+ccc
[root@master 777]# git diff --cached a
#进行撤回恢复.
#检查没有输出说明 本地工作目录做了改动,暂存区和本地仓库没有做改动,此时又一次回到了我们第一次实验的环境,我们只需要使用 git checkout -- a
撤回完成后通过 git diff a 再一次查看a文件的改动情况:
[root@master 777]# git diff a #这时候他已经没有输出了.说明和之前一样 没有做过改动 ccc应该也不在了.我们可以通过 cat a 来查看
[root@master 777]# cat a #可以看到 ccc 已经被撤回了.文件没有被改动了.
aaa
bbb
流程记录:
1. 追加数据后使用了 git add . 添加了
2. git diff --cached 来检查对比本地仓库添加了哪些数据
3. git reset HEAD a 通过本地仓库文件覆盖暂存区文件,这句是最重要的回退命令
4. cat a 检查是否回退.
- 修改了文件内容,且做过commit提交后的回退操作
关键命令: git reset --hard [commit标识符]
案例现场还原:
[root@master 777]# cat a
aaa
bbb
[root@master 777]# echo ccc >>a
[root@master 777]# cat a
aaa
bbb
ccc
[root@master 777]# git add . #提交了更改
回退:
查看git commit历史:
[root@master 777]# git log a
commit fa4e4b2480edef44c0f0062f02b3703a58c44395
Author: chenmaster <xganfeni@gmail.com>
Date: Mon Dec 9 17:23:34 2019 +0800
commit a
....
....
...
commit 68fec000d8f4327dc4d6bbea675a731d7572defc
Author: chenmaster <xganfeni@gmail.com>
Date: Mon Dec 9 17:21:27 2019 +0800
commit a
#---------------------------------------------
可以看到很多commit的历史. 找到错误之前额历史实践 获取 commit 的串号唯一标识符,前几位即可
回退到指定commit时间点:
[root@master 777]# git reset --hard 68fec000d8
HEAD is now at 68fec00 commit a
[root@master 777]# cat a
aaa
bbb
ccc
ddd
#如果跳错了呢? 没关系可以通过 git reflog 来查看最近提交的id
[root@master 777]# git reflog
e1ebcce HEAD@{0}: reset: moving to e1ebcce13b51
68fec00 HEAD@{1}: reset: moving to 68fec000d8
fa4e4b2 HEAD@{2}: commit: commit a ----#这就是我们最后一次 commit的ID,通过这个来查看
68fec00 HEAD@{3}: commit: commit a
e1ebcce HEAD@{4}: commit: commit a
3b65d3a HEAD@{5}: commit: commit a
202ba55 HEAD@{6}: commit: commit a
#回退:
[root@master 777]# git reset --hard fa4e4b2 # 从仓库回退到工作目录
HEAD is now at fa4e4b2 commit a
[root@master 777]# cat a #回退成功
aaa
bbb
2.2.10 git diff 与 git diff --cached 比较
git diff 会让本地工作目录和暂存区文件进行对比
git diff --cached 会让暂存区和本地/远程仓库进行对比
实践:
git diff 作用:
[root@master master]# touch 666 ##创建文件
[root@master master]# git add 666 ##添加到暂存区
[root@master master]# git diff 666 ##本地文件和暂存区文件进行对比
[root@master master]# echo 123 >666 ## 修改666这个文件
[root@master master]# git diff 666 ## 本地文件和暂存区对比
diff --git a/666 b/666
index e69de29..190a180 100644
--- a/666
+++ b/666
@@ -0,0 +1 @@
+123
[root@master master]# git diff --cached 666 #使用--cached参数对比,只提示有新文件.
diff --git a/666 b/666
new file mode 100644
index 0000000..e69de29
提交文件:
[root@master master]# git commit -m "modify 666"
[master f4e2f59] modify 666
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 666
使用git diff --cached进行对比:
git diff --cached 作用: 暂存区和本地仓库进行对比
[root@master master]# git diff --cached 666
#这里可以看出,git diff 是让本地工作目录[工作区]和暂存区文件进行对比,提交后在对比就没有输出.所以说 git diff 只是让本地仓库和暂存区文件进行对比.
#总结:
未commit提交的数据可以用 git diff 进行对比
已commit提交的数据则使用 git diff --cached 进行对比
git diff HEAD #查看工作区和版本库中的最新提交的不同
git reset HEAD a #回退 a 文件的数据,从暂存区回退到工作区.
2.2.11 git commit 是什么
git commit 相当于为一个文件做了一次类似于虚拟机的快照
查看commit历史: git log
[root@master xqf]# git log
commit 0a668049b87412385acd6639c8aa76ef196ed192
Author: ddhh8023 <xganfeni@gmail.com>
Date: Mon Dec 9 14:01:40 2019 +0800
110
commit f4e2f59f28a6d7ae7639902970e8fbc5eb1c567c
Author: ddhh8023 <xganfeni@gmail.com>
Date: Mon Dec 9 13:41:20 2019 +0800
modify 666