计算机基础（二）——Git的底层原理，reverse和reset的区别，rebase作用

已于 2023-03-08 10:58:39 修改
阅读量2.6k 收藏 5
点赞数 3
CC 4.0 BY-SA版权
分类专栏： 计算机基础 文章标签： git reset reverse rebase 变基
于 2021-05-10 21:05:18 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/iaiti/article/details/116586882
本文深入探讨Git的基础概念，包括工作区、暂存区、版本库等分区介绍，blob、tree、commit三种主要对象的关系及实例演示。此外，还详细解析了branch与tag的区别、reset与reverse的不同之处，以及rebase的作用及其与merge的区别。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

目录

1、分区

2、对象

3、对象实例演示

4、branch和tag

5、reset和reverse区别

6、rebase作用

7、rebase再探究竟，rebase和merge区别

这一篇其实不属于计算机基础的，但是随着大家平时工作还有开源一些项目的版本控制的使用，使用叫多的git。
回过头来，有时在思考reverse和rebase区别，回归到底层的一些原理的时候，就有茅塞顿开的感觉了。

1、分区

首先Git有分三个区，工作区,暂存区和版本库。

2、对象

Git当中一共有3种主要的对象:blob，tree，commit


git add 多一个blob文件，repository的一个文件，内容为文件内容
git add 再多一个blob文件
git commit后 会有两个tree 一个commit
tree，存储blob对象和子tree对象，这类型的对象在Git里面代表的就是一个文件夹，而这个对象的内容就是面向它所包含的文件夹和文件的指针。
commit对象，包含了一个面向根目录tree对象的指针，而且还包含了committer的个人信息还有commit的注释。

三个对象之间关系。总结就是
commit 指向 tree 指向 tree 或者 blob

3、对象实例演示

查看对象内容可以参考官方文档，Git - git-cat-file Documentation
git cat-file --batch-check --batch-all-objects
the SHA-1, type, and size of each object is printed on stdout
sha1跟md5类似是一个摘要值，然后就是对象类型，大小
 

#查看git版本
C:\Users>git --version
git version 2.20.1.windows.1

#创建测试目录
D:\>mkdir gittest

D:\>cd gittest

#git 初始化
D:\gittest>git init
Initialized empty Git repository in D:/gittest/.git/

#创建文件index.txt
D:\gittest>echo "version 1" > index.txt

# index.txt加入暂存区
D:\gittest>git add index.txt

# 查看所有对象内容
D:\gittest> git cat-file --batch-check --batch-all-objects
6c58b76a52188643965f3a6704166e8e0424b7fe blob 13

# 查询sha-1对应的文件内容，该对象对应的内容就是index.txt内容
D:\gittest>git cat-file -p 6c58b76a52188643965f3a6704166e8e0424b7fe
"version 1"

# 创建文件index2.txt
D:\gittest>echo "version 2" > index2.txt
# index2.txt加入暂存区
D:\gittest>git add index2.txt
# 查看所有对象内容
D:\gittest> git cat-file --batch-check --batch-all-objects
6c58b76a52188643965f3a6704166e8e0424b7fe blob 13
8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 blob 13

# 查询sha-1对应的文件内容，该对象对应的内容就是index2.txt内容
D:\gittest>git cat-file -p 8231f0fdc862f06b2bd7b7bfd2f42082d3086b71
"version 2"

#创建新文件夹
D:\gittest>mkdir dir

#创建新文件夹中的新文件
D:\gittest>echo "version 1, inside" > ./dir/inside.txt
 
# inside.txt加入暂存区
D:\gittest>git add ./dir/inside.txt

# 查看所有对象内容
D:\gittest> git cat-file --batch-check --batch-all-objects
6c58b76a52188643965f3a6704166e8e0424b7fe blob 13
8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 blob 13
bf97e71de76bcff2bd8aba44710aa5e665eacb99 blob 21

# 查询sha-1对应的文件内容，该对象对应的内容就是inside.txt内容
D:\gittest>git cat-file -p bf97e71de76bcff2bd8aba44710aa5e665eacb99
"version 1, inside"

#提交到本地仓库
D:\gittest>git commit


D:\gittest> git cat-file --batch-check --batch-all-objects
39bdea2300491cc90f47551887bfe9503cd4a9d9 tree 38
6c58b76a52188643965f3a6704166e8e0424b7fe blob 13
8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 blob 13
bf97e71de76bcff2bd8aba44710aa5e665eacb99 blob 21
d5c2b878425995af5ddc5202f7058a1ff372b3f3 tree 105



D:\gittest>git commit
[master (root-commit) 629a4cf] commit 1
 3 files changed, 3 insertions(+)
 create mode 100644 dir/inside.txt
 create mode 100644 index.txt
 create mode 100644 index2.txt

# 查看所有对象内容,commit之后多了两个tree和一个commit
D:\gittest> git cat-file --batch-check --batch-all-objects
39bdea2300491cc90f47551887bfe9503cd4a9d9 tree 38
629a4cf0fdb33390ad5774b10244512e3d400407 commit 169
6c58b76a52188643965f3a6704166e8e0424b7fe blob 13
8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 blob 13
bf97e71de76bcff2bd8aba44710aa5e665eacb99 blob 21
d5c2b878425995af5ddc5202f7058a1ff372b3f3 tree 105

#查看一个commit
D:\gittest>git cat-file -p 629a4cf0fdb33390ad5774b10244512e3d400407
tree d5c2b878425995af5ddc5202f7058a1ff372b3f3
author  iaiti<xx@qq.com> 1617247696 +0800
committer  iaiti<xx@qq.com> 1617247696 +0800

# 查看其中一个tree
D:\gittest>git cat-file -p d5c2b878425995af5ddc5202f7058a1ff372b3f3
040000 tree 39bdea2300491cc90f47551887bfe9503cd4a9d9    dir
100644 blob 6c58b76a52188643965f3a6704166e8e0424b7fe    index.txt
100644 blob 8231f0fdc862f06b2bd7b7bfd2f42082d3086b71    index2.txt


# 更改文件内容
D:\gittest>echo "version 2" > index.txt

D:\gittest>git add index.txt

D:\gittest>echo "version 1 new" > index.txt

D:\gittest>git add index.txt

D:\gittest> git cat-file --batch-check --batch-all-objects
0b596a83945ca790976a10bbf005262f1cefe4cc blob 17   		(version 1 new)
39bdea2300491cc90f47551887bfe9503cd4a9d9 tree 38   		(inside.txt)
629a4cf0fdb33390ad5774b10244512e3d400407 commit 169 	(commit)
6c58b76a52188643965f3a6704166e8e0424b7fe blob 13   		(version 1)
8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 blob 13   		(version 2)
bf97e71de76bcff2bd8aba44710aa5e665eacb99 blob 21   		(version 1, inside)
d5c2b878425995af5ddc5202f7058a1ff372b3f3 tree 105  		(dir index.txt  index2.txt)

D:\gittest>git cat-file -p 0b596a83945ca790976a10bbf005262f1cefe4cc
"version 1 new"


#提交第二次
D:\gittest>git cat-file -p beaeb2b94a88d6cf03c096f667859239065d1ba8
tree 4fca214cabbc6f8c6a7243f9ea780b66ee895993
parent 629a4cf0fdb33390ad5774b10244512e3d400407
author iaiti <xx@git.com> 1617247963 +0800 
committer iaiti <git@xx.com> 1617247963 +0800

Commit 2

多次更改和提交两次后，所有对象的对应关系

4、branch和tag

branch 其实就是一个指向某个commit的指针文件，一般被存放在./.git/refs/heads里面，所以branch只是跨commit而已，按照上图所指示出来的，指向的其实就是master分支
head指向最新commit
tag相当于是静态的 branch ，被存储在./.git/refs/tags里面的文件中。它并不跟随HEAD移动。通常用于标记一个特定的commit，例如某个版本的代码，以方便checkout。

5、reset和reverse区别

reset是记录重设，有三种模式

git reset 17cf9ea15f6c63ec04f232c5cd72e0c1b3f657fd
--hard  commit记录重设，但是如果远程仓库已经commit，可以使用git push --force
--mixed commit记录重设，工作区文件修改，暂存区的记录会重置，相当于没到git add阶段，相当于撤销add
--soft   commit记录重设，工作区文件修改和暂存区的记录都会保存

三种模式总结来说就是，相当于做了版本回退，并控制文件是否回退到暂存区前

而reverse，也是回退，但是不是重置commit，而是多出一条commit ，提醒其他的开发者或者公司同事，这里有恢复操作。可以
和reset对比结合看。

问题来了，reverse还有commit，reset的话中间的commit就不见了， 我要回滚怎么操作？

git reflog记录操作，回滚回之前重置的commit记录。

D:\gittest>git ls-files --stage
100644 bf97e71de76bcff2bd8aba44710aa5e665eacb99 0       dir/inside.txt
100644 0b596a83945ca790976a10bbf005262f1cefe4cc 0       index.txt
100644 8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 0       index2.txt
D:\gittest>
D:\gittest>echo "version test index" > index.txt
D:\gittest>
D:\gittest>git ls-files --stage
100644 bf97e71de76bcff2bd8aba44710aa5e665eacb99 0       dir/inside.txt
100644 0b596a83945ca790976a10bbf005262f1cefe4cc 0       index.txt
100644 8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 0       index2.txt

D:\gittest>git add index.txt

D:\gittest>git ls-files --stage
100644 bf97e71de76bcff2bd8aba44710aa5e665eacb99 0       dir/inside.txt
100644 be06e3be42f6a2955d61750c86646b7869177f47 0       index.txt
100644 8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 0       index2.txt
D:\gittest>


D:\gittest>echo "version test index" > index.txt

D:\gittest>git add index.txt

git commit -m comit3

D:\gittest>git log
commit b3a0d90be0da1862b4c82fb6beafffaf4113148e (HEAD -> master)
Author: <E8><94><A1><E5><9D><A4><E6><89><BF> <xx.com>
Date:   Thu Apr 29 19:51:51 2021 +0800

    Revert "comit3"

    This reverts commit 6fccca25df481aa1d53ad60075bb37d5e87d8593.

commit 6fccca25df481aa1d53ad60075bb37d5e87d8593
Author: <E8><94><A1><E5><9D><A4><E6><89><BF> <xx.com>
Date:   Thu Apr 29 19:51:21 2021 +0800

    comit3

6、rebase作用

变基，Git - git-rebase Documentation 可以查看相关指令信息，

git rebase -i  [startpoint]  [endpoint] 给用户交互界面进行操作

挑选变基的commit

git rebase -i 674c40b

然后移除多余的commit信息，s的话是合并前面的提交

从这里可以看到，变基可以合并我前面提交无用的记录。让整个提交的历史更加的简洁，之前有网友举例，vue作者尤雨溪就有这样的处理。

rebase分支不要使用在公共分支上。

7、rebase再探究竟，rebase和merge区别

除了合并提交信息，让其更简洁外，是不是还有其他作用，都是合并，那和merge区别是什么，需要这样思考。

假如我有一条功能分支比较久没同步线上代码，或者主分支其实多人合作合并频繁的时候，按照平时的操作都是拉一条分支，然后将master merge到自己分支

结果是这样的


而变基能让自己的一条分支形成直线，不受其他的干扰。

总结来说，merge是当前开发分支领先于要合并的分支，那就merge过去，比如开发功能和测试完毕想合并到线上，就是用merge。

如果当前分支许久没拉下来，落后master的，就用rebase，就只把当前的内容合并到自己分支上，而不用理会是什么分支合并过来的。master主分支才需要查看谁合了什么上去。

Git 分支 5- 变基
u_my_heart的博客
08-14 1050
电子书链接： 变基 在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。 在本节中我们将学习什么是“变基”，怎样使用“变基”，并将展示该操作的惊艳之处，以及指出在何种情况下你应避免使用它。 变基的基本操作 请回顾之前在 分支的合并 中的一个例子，你会看到开发任务分叉到两个不同分支，又各自提交了更新。 之前介绍过，整合分支最容易的方法是 merge 命令。 它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交
git-rebase revert reset原理
Alaskan_Husky的博客
12-03 1020
用于创建新的提交，以撤销之前某次提交的更改。它不会改变原有的提交历史，而是添加一个新的提交，该提交的更改与要撤销的提交相反。它会将当前分支的提交逐个地移动到目标分支的最后，使得提交历史更为线性。创建了一个新的提交，用于撤销之前某次提交的更改，而不修改原提交历史。选项，这会将工作目录保留为原样，但是将提交历史和暂存区重置到指定的提交。会改写提交历史，因此在协作开发中需要小心使用，尤其是在共享的分支上。主要用于撤销一些本地的提交，重新开始一个新的提交历史。适用于撤销某次提交的更改，并保留原有的提交历史。
Git中rebase的作用
LiZhen314的博客
06-01 3008
Gitrebase，顾名思义，就是重新定义（re）起点（base）的作用，即重新定义分支的版本库状态。要搞清楚这个东西，要先看看版本库状态切换的两种情况： 我们知道，在某个分支上，我们可以通过git reset，实现将当前分支切换到本分支以前的任何一个版本状态，即所谓的“回溯”。即实现了本分支的“后悔药”。也即版本控制系统的初衷。 还有另一种情况，当我们的项目有多个分支的时候。我们除了在本地开发的时候可能会“回溯”外，也常常会将和自己并行开发的别人的分支修改添加到自 己本地来。这种情况下很常见。作为项.
合并代码用 merge 还是用 rebase ? 两者的区别是什么？
最新发布
m0_69632475的博客
06-16 625
所以，我们的提交记录就会非常清晰，没有分叉，上面演示的是比较顺利的情况，但是大部分情况下，rebase 的过程中会产生冲突的，此时，就需要手动解决冲突，然后使用。另外，在解决冲突的时候，用 merge 只需要解决一次冲突即可，简单粗暴，而用 rebase 的时候 ，需要一次又一次的解决冲突。保存退出，此时又会弹出一个编辑页面，这个页面是用来编辑提交的信息，修改为feat: 更正，最后保存一下，接着使用。假设我们现在有2条分支，一个为 master ，一个为 feature/1，他们都基于初始的一个提交。
git rebase的作用
lgz0921的博客
08-06 2494
rebase操作可以把本地未push的分叉提交历史整理成直线，就是说可以合并多次commit，这样我们在查看历史提交的变化时更容易。 什么是把提交历史整理成直线？ 举一个例子：它就是ide里面的这个： 大家都懂吧～～～ 可以看出有交叉的地方，使用rebase可以整理成直线～～～ 我一般不用rebase～～～～哈哈哈～～～～，想使用的小伙伴可以了解一下哦～～ 如果大家看完本文后还是不理解rebase能干啥，请看廖雪峰的官方网站https://www.liaoxuefeng.com/wiki/8
git | rebase用法
Willian的博客屋
02-19 908
博客引用处（以下内容在原有博客基础上进行补充或更改，谢谢这些大牛的博客指导）： rebase 用法小结 rebase在git中是一个非常有魅力的命令，使用得当会极大提高自己的工作效率；相反，如果乱用，会给团队中其他人带来麻烦。它的作用简要概括为：可以对某一段线性提交历史进行编辑、删除、复制、粘贴；因此，合理使用rebase命令可以使我们的提交历史干净、简洁！ 前提：不要通过rebase对任何已经提...
git 的rebase、reset、revert区别？
study_way的博客
01-14 4369
rebase用于修改提交历史的顺序，将一系列提交重新应用到新的基底上。reset用于移动 HEAD 指针，可以用来撤销提交、取消暂存区的更改或者彻底丢弃更改。revert用于创建新的提交，撤销之前的提交，不改变历史。选择使用哪个命令取决于你的需求和工作流程。在共享的分支上使用rebase和reset时要小心，因为它们会改变提交历史，可能引发冲突。
Git撤销&回滚操作(git reset 和 get revert)_好用
07-20 1769
https://blog.csdn.net/asoar/article/details/84111841 git的工作流...
Git系列——Git部署及应用
mql007007的博客
02-23 1368
下面从如下几个方面介绍下其部署及应用：Git服务器搭建Git客户端搭建Git常用命令。
【GIT】git个人笔记
小鱼菜鸟的博客
07-22 872
GIT个人手册 版本 日期 修订内容 作者 V01 2019-06-25 初稿 备注： 使用中不断迭代完善，其他人使用中有其他总结的，可以补充。 目录 第一章说明 一.1.1GIT 中文手册 一.1.2git仓库说明(工作区、暂存区、本地仓、远程仓)1 一.1.3git仓库说明(工作区、暂存区、本地仓、远程仓)2...
Git-2.21.0-64-bit.zip
10-22
Git-2.21.0-64 for windows Git 2.23 Release Notes ====================== Updates since v2.22 ------------------- Backward compatibility note * The "--base" option of "format-patch" computed the ...
revert与reset
xue258521的博客
11-14 528
1、场景 错误的将不该和并的分支合并了上去   2、例 test为正在测试的新功能分支，操作人错误的将test分支合并到了主分支master，此时希望将test的分支提交回滚   3、策略 撤销此次的提交 reset 提交一次新的提交反向撤销本次提交 revert 4、问题 reset 可能因在发现之前，mater上已执行了多次的提交，如下所示： . . . commit1 c...
Git 中 rebase、reset、revert 有什么区别？
前端小白的博客
12-20 1622
3、revert（还原）：git revert命令用于创建一个新的提交，该提交撤销了指定提交的更改。这种方式能够保持提交历史的完整性，并且是安全的，因为它不会影响其他开发者所使用的分支。1、rebase（变基）：git rebase命令用于将一个分支的提交应用到另一个分支上，从而重新组织提交历史。通过变基，可以使得代码提交历史更加清晰、线性，并且可以避免生成大量的合并提交。在Git中，rebase、reset和revert是三个常用的操作命令，它们用于处理合并分支、回退版本、撤销更改。
Git的reset和rebase命令，最透彻、最详细、最简单的教程，学习完对reset和rebase清清楚楚明明白白
WayneHu的博客
08-15 2519
我们提交代码的时候不小心提交错了怎么办？ 提交的message不小心漏掉了字母？提交的代码好像忘改了一个拼错的单词？提交了好几次了有点乱，能不能合在一起？master分支更新了，更我切出的时候不一样怎么办？？？诸如此类等等情况，我们的reset和rebase闪亮登场~~人生不可以重来，但是commit可以。
Git恢复之前版本的两种方法reset、revert（图文详解）
zmjames2000 Just record
09-26 1978
方法一：git reset 原理： git reset的作用是修改HEAD的位置，即将HEAD指向的位置改变为之前存在的某个版本，如下图所示，假设我们要回退到版本一： 适用场景： 如果想恢复到之前某个提交的版本，且那个版本之后提交的版本我们都不要了，就可以用这种方法。 具体操作： 查看版本号： 可以使用命令“git log”查看： 使用“git reset --hard 目标版本号”命令将版本回...
高级 Git 指南：Git Stash、Reset、Rebase 等
Meta.Qing的博客
12-09 1789
每个开发人员都应该对版本控制有很好的了解，而 Git 已经成为软件开发中版本控制的事实标准。但是，开发人员通常只学习一些简单的命令，而忽略了 Git 历史的强大功能以及 Git 可以使您更有效率的其他事情。例如，使用 Git 使用.我参加了 Git 在线高级课程（通过 Github），并继续与 Github 一起教授初学者的 Git 课程。当我注意到关于我最喜欢的 Git 功能的技术文章不多时，我抓住机会与我的开发人员分享它。在本文中，您将学习如何利用以下高级 Git 功能：Git stash 使您无需提交
git reset详解
weixin_33721344的博客
06-05 359
HEAD HEAD也是很多初学者会搞不清楚的一个概念 说穿了也很简单 就是 你的目前branch的最新的commit 所以今天你下了git checkout b1 但有个例外 因为checkout并不只可以指定branch 还可以指定一个commit 所以当你checkout <commit> 他的意思是说 嘿 既然你指定的是...
git 删除历史commit
u011803304的专栏
02-01 9878
“没有commit错代码的人，不足以称为高级工程师。——凯天” 你不认识凯天没事，你只用知道代码提交错分支有救就行了。废话不多说，我们进入正题——怎么删除最后一次提交的记录。 删除最后一次提交 命令很简单，但是不能马虎，不能多回滚或者少回滚，不然就麻烦不断了。 主要命令： 第一步：回滚上一次提交 git reset --hard HEAD^ 就很简单，回滚master分支的上一次提交。 ...
idea如何撤回拉取代码
01-18
### 如何在 IntelliJ IDEA 中撤销 Git Pull 操作 当开发者希望撤销已经执行的 `git pull` 命令时，可以采取几种不同的策略来恢复工作环境至拉取前的状态。具体方法取决于当前的工作场景以及是否已有新的提交被创建。 #### 使用 Reset 方式回退到最近一次本地提交之前 如果仅需简单地丢弃由 `pull` 引入的所有变更，并返回到最后一个本地提交，则可以通过重置分支实现： ```bash # 切换到目标分支 git checkout main # 查看 reflog 找到最后一次 pull 之前的 commit hash git reflog # 假设找到的hash为 abcdefg,那么执行如下命令回到该状态 git reset --hard abcdefg ``` 此方式适用于尚未基于新获取的内容做出任何额外修改的情况；它将直接把 HEAD 移动到指定的历史点并覆盖工作区中的改动[^1]。 #### 反转 Merge 或 Rebase 来取消 Pull 效果 对于那些希望通过更安全的方式处理的情形，比如不想丢失可能存在的未推送到远程的新提交，应该考虑使用 revert 或者 reverse merge/rebase 技术。这允许保留现有历史记录的同时消除特定更新的影响。 - **Revert Merges:** 如果 `pull` 导致了一个合并（merge），则可通过反转这次合并不影响其他部分。 ```bash # 获取最新的合并commit id (通常是HEAD) git log --merges # 对选定的合并commit应用revert操作 git revert -m 1 <merge-commit-id> ``` - **Abort a Rebase or Resolve Conflicts During an Incomplete Rebase:** 若正在进行 rebase 并遇到冲突或其他问题想要停止过程，可随时终止重新基底的过程而不改变原有代码库结构。 ```bash git rebase --abort ``` 以上两种情况均可以在不破坏既有工作的前提下有效地逆转因 `pull` 行为带来的变化[^2]。 #### 在 IntelliJ IDEA GUI 下完成上述动作 除了命令行外，IntelliJ IDEA 提供了图形界面支持这些功能。例如要进行硬重置，可以选择 VCS -> Git -> Reset... ，然后选择合适的模式和对应的提交版本即可达到相同效果。同样地，针对合并后的反向操作也可以通过 IDE 的交互窗口轻松达成目的[^3]。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

iaiti

赏顿早餐钱~

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值