关于java:图文并茂详解-Git看了必懂

作者：Bezier\
链接：https://juejin.cn/post/689524…

前言

作为以后世界上最弱小的代码管理工具 Git 置信大家都很相熟，但据我所知有很大一批人停留在 clone、commit、pull、push... 的阶段，是不是对 rebase 心里没底只敢用merge？碰见版本回退就抓瞎？别问我怎么晓得的，问就是：“我已经就是这样啊～～”。

针对这些问题，明天我就将这几年对 Git 的认知和了解分享进去，尽可能的从实质去解说 Git，帮忙你一步一步去理解Git 的底层原理，置信读完本篇文章你便能够换种姿势，更加风骚得应用 Git 各种指令。

目录

• 1. 基本概念
  • 1.1 Git 的劣势
  • 1.2 文件状态
  • 1.3 commit 节点
  • 1.4 HEAD
  • 1.5 近程仓库
• 2. 分支
  • 2.1 什么是分支？
• 3. 命令详解
  • 3.1 提交相干
  • 3.2 分支相干
  • 3.3 合并相干
  • 3.4 回退相干
  • 3.5 近程相干

1. 基本概念

1.1 Git 的劣势

Git是一个 分布式 代码管理工具，在探讨分布式之前防止不了提及一下什么是 地方式 代码治理仓库

• 地方式：所有的代码保留在地方服务器，所以提交必须依赖网络，并且每次提交都会带入到地方仓库，如果是协同开发可能频繁触发代码合并，进而减少提交的老本和代价。最典型的就是 svn
• 分布式：能够在本地提交，不须要依赖网络，并且会将每次提交主动备份到本地。每个开发者都能够把近程仓库 clone 一份到本地，并会把提交历史一并拿过去。代表就是 Git

那 Git 相比于 svn 有什么劣势呢？打个比方：” 巴拉巴拉写了一大堆代码，忽然发现写的有问题，我想回到一个小时之前 ”，对于这种状况 Git 的劣势就很显著了，因为 commit 的老本比拟小并且本地会保留所有的提交记录，随时随刻能够进行回退。在这并不是说 svn 的不能实现这种操作，只是 Git 的回退会显得更加的优雅。Git相比于 地方式 工具还有很多长处，就不一一列举了，感兴趣的可自行理解。

1.2 文件状态

在 Git 中文件大略分为三种状态：已批改（modified）、已暂存（staged）、已提交（committed）

• 批改：Git 能够感知到工作目录中哪些文件被批改了，而后把批改的文件退出到 modified 区域
• 暂存：通过 add 命令将工作目录中批改的文件提交到暂存区，等待被 commit
• 提交：将暂存区文件 commit 至 Git 目录中永恒保留

1.3 commit 节点

为了便于表述，本篇文章我会通过 节点 代称commit 提交

在 Git 中每次提交都会生成一个 节点 , 而每个节点都会有一个哈希值作为惟一标示，屡次提交会造成一个 线性 节点链（不思考 merge 的状况），如图 1 -1

节点上方是通过 SHA1 计算的哈希值

C2节点蕴含 C1 提交内容, 同样 C3 节点蕴含 C1、C2 提交内容

1.4 HEAD

HEAD是 Git 中十分重要的一个概念，你能够称它为 指针 或者 援用 ，它能够指向任意一个 节点 ，并且指向的节点始终为当前工作目录，换句话说就是当前工作目录(也就是你所看到的代码) 就是 HEAD 指向的节点。

还以图 1 - 1 举例，如果 HEAD 指向 C2 那工作目录对应的就是 C2 节点。具体如何挪动 HEAD 指向前面会讲到，此处不要纠结。

同时 HEAD 也能够指向一个 分支 ，间接指向 分支 所指向的 节点

1.5 近程仓库

尽管 Git 会把代码以及历史保留在本地，但最终还是要提交到服务器上的近程仓库。通过 clone 命令能够把近程仓库的代码下载到本地，同时也会将 提交历史 、 分支 、HEAD 等状态一并同步到本地，但这些状态并不会实时更新，须要手动从近程仓库去拉取，至于何时拉、怎么拉前面章节会讲到。

通过近程仓库为中介，你能够和你的共事进行协同开发，开发完新性能后能够申请提交至近程仓库，同时也能够从近程仓库拉取你共事的代码。

留神点

因为你和你的共事都会以近程仓库的代码为基准，所以要时刻保障近程仓库的代码品质，切记不要将未经检验测试的代码提交至近程仓库

2. 分支

2.1 什么是分支？

分支 也是 Git 中相当重要的一个概念，当一个 分支 指向一个 节点 时，以后 节点 的内容即是该 分支 的内容，它的概念和 HEAD 十分靠近同样也能够视为 指针 或援用 ，不同的是 分支 能够存在多个，而 HEAD 只有一个。通常会依据 性能 或版本 建设不同的分支

那分支有什么用呢？

• 举个例子：你们的 App 经验了含辛茹苦终于公布了 v1.0 版本，因为需要紧急 v1.0 上线之后便快马加鞭的开始 v1.1，正当你开发的衰亡时，QA 同学说用户反馈了一些 bug，须要修复而后从新发版，修复v1.0 必定要基于 v1.0 的代码，可是你曾经开发了一部分 v1.1 了，此时怎么搞？

面对下面的问题通过引入 分支 概念便可优雅的解决，如图 2 -1

• 先看右边示意图，假如 C2 节点既是 v1.0 版本代码，上线后在 C2 的根底上新建一个分支ft-1.0
• 再看左边示意图，在 v1.0 上线后可在 master 分支开发 v1.1 内容，收到 QA 同学反馈后提交 v1.1 代码生成节点 C3，随后切换到ft-1.0 分支做 bug 修复，修复实现后提交代码生成节点 C4，而后再切换到master 分支并合并 ft-1.0 分支，到此咱们就解决了下面提出的问题

除此之外利用分支还能够做很多事件，比方当初有一个需要不确定要不要上线，然而得先做，此时能够独自创立一个分支开发该性能，等到啥时候须要上线间接合并到主分支即可。分支实用的场景很多就不一一列举了。

留神点

当在某个节点创立一个分支后，并不会把该节点对应的代码复制一份进去，只是将新分支指向该节点，因而能够很大水平缩小空间上的开销。肯定要记着不论是 HEAD 还是 分支 它们都只是援用而已，量级十分轻

3. 命令详解

3.1 提交相干

后面咱们提到过，想要对代码进行提交必须得先退出到暂存区，Git 中是通过命令 add 实现

增加某个文件到暂存区：

git add 文件门路

增加所有文件到暂存区：

git add .

同时 Git 也提供了撤销 工作区 和暂存区 命令

撤销工作区改变：

git checkout -- 文件名

清空暂存区：

git reset HEAD 文件名

提交：

将改变文件退出到暂存区后就能够进行提交了，提交后会生成一个新的提交节点，具体命令如下：

git commit -m "该节点的形容信息"

3.2 分支相干

创立分支

创立一个分支后该分支会与 HEAD 指向同一节点，说艰深点就是 HEAD 指向哪创立的新分支就指向哪，命令如下：

git branch 分支名

切换分支

当切换分支后，默认状况下 HEAD 会指向以后分支，即 HEAD 间接指向以后分支指向的节点

git checkout 分支名

同时也能够创立一个分支后立刻切换，命令如下：

git checkout -b 分支名

删除分支

为了保障仓库分支的简洁，当某个分支实现了它的使命后应该被删除。比方后面所说的独自开一个分支实现某个性能，当这个性能被合并到主分支后应该将这个分支及时删除。

删除命令如下：

git branch -d 分支名

3.3 合并相干

对于合并的命令是最难把握同时也是最重要的。咱们罕用的合并命令大略有三个merge、rebase、cherry-pick

merge

merge是最罕用的合并命令，它能够将某个分支或者某个节点的代码合并至以后分支。具体命令如下：

git merge 分支名 / 节点哈希值

如果须要合并的分支齐全当先于以后分支，如图 3 - 1 所示

因为分支 ft-1 齐全当先分支 ft-2 即ft-1齐全蕴含 ft-2，所以ft-2 执行了 “git merge ft-1” 后会触发fast forward(疾速合并)，此时两个分支指向同一节点，这是最现实的状态。然而理论开发中咱们往往碰到是是上面这种状况：如图 3 -2(左)

这种状况就不能间接合了，当 ft-2 执行了 “git merge ft-1” 后 Git 会将节点 C3、C4 合并随后生成一个新节点 C5，最初将ft-2 指向C5 如图 3 -2(右)

留神点：

如果 C3、C4 同时批改了同一个文件中的同一句代码，这个时候合并会出错，因为 Git 不晓得该以哪个节点为规范，所以这个时候须要咱们本人手动合并代码

rebase

rebase也是一种合并指令，命令行如下：

git rebase 分支名 / 节点哈希值

与 merge 不同的是 rebase 合并看起来不会产生新的节点(实际上是会产生的，只是做了一次复制)，而是将须要合并的节点间接累加 如图 3 -3

当右边示意图的 ft-1.0 执行了 git rebase master 后会将 C4 节点复制一份到 C3 前面，也就是 C4'，C4 与C4'绝对应，然而哈希值却不一样。

rebase相比于 merge 提交历史更加线性、洁净，使并行的开发流程看起来像串行，更合乎咱们的直觉。既然 rebase 这么好用是不是能够摈弃 merge 了？其实也不是了，上面我列举一些 merge 和rebase的优缺点：

merge 优缺点：

• 长处：每个节点都是严格依照工夫排列。当合并发生冲突时，只须要解决两个分支所指向的节点的抵触即可
• 毛病：合并两个分支时大概率会生成新的节点并 分叉，长此以往提交历史会变成一团乱麻

rebase 优缺点：

• 长处：会使提交历史看起来更加线性、洁净
• 毛病：尽管提交看起来像是线性的，但并不是真正的按工夫排序，比方图 3 - 3 中，不论 C4 早于或者晚于 C3 提交它最终都会放在 C3 前面。并且当合并发生冲突时，实践上来讲有几个节点 rebase 到指标分支就可能解决几次抵触

对于网络上一些 只用 rebase的观点，作者示意不太认同，如果不同分支的合并应用 rebase 可能须要反复解决抵触，这样就得失相当了。但如果是本地推到近程并对应的是同一条分支能够优先思考 rebase。所以我的观点是 依据不同场景正当搭配应用merge 和rebase，如果感觉都行那优先应用rebase

cherry-pick

cherry-pick的合并不同于 merge 和rebase，它能够抉择某几个节点进行合并，如图 3 -4

命令行：

git cherry-pick 节点哈希值

假如以后分支是 master，执行了git cherry-pick C3(哈希值)，C4(哈希值) 命令后会间接将 C3、C4 节点抓过去放在前面，对应 C3' 和C4'

3.4 回退相干

拆散 HEAD

在默认状况下 HEAD 是指向分支的，但也能够将 HEAD 从分支上取下来间接指向某个节点，此过程就是 拆散 HEAD，具体命令如下：

git checkout 节点哈希值
// 也能够间接脱离分支指向以后节点
git checkout --detach

因为哈希值是一串很长很长的乱码，在实际操作中应用哈希值拆散 HEAD 很麻烦，所以 Git 也提供了 HEAD 基于某一非凡地位 (分支 /HEAD) 间接指向 前一个 或前 N 个 节点的命令，也即绝对援用，如下：

//HEAD 拆散并指向前一个节点
git checkout 分支名 /HEAD^
//HEAD 拆散并指向前 N 个节点
git checkout 分支名～N

将 HEAD 拆散 进去指向节点有什么用呢？举个例子：如果开发过程发现之前的提交有问题，此时能够将 HEAD 指向对应的节点，批改结束后再提交，此时你必定不心愿再生成一个新的节点，而你只需在提交时加上 --amend 即可，具体命令如下：

git commit --amend

回退

回退场景在平时开发中还是比拟常见的，比方你巴拉巴拉写了一大堆代码而后提交，前面发现写的有问题，于是你想将代码回到前一个提交，这种场景能够通过 reset 解决，具体命令如下：

// 回退 N 个提交
git reset HEAD~N

reset和 绝对援用 很像，区别是 reset 会使 分支 和HEAD一并回退。

3.5 近程相干

当咱们接触一个新我的项目时，第一件事件必定是要把它的代码拿下来，在 Git 中能够通过 clone 从近程仓库复制一份代码到本地，具体命令如下：

git clone 仓库地址

后面的章节我也有提到过，clone不仅仅是复制代码，它还会把近程仓库的 援用 (分支 /HEAD) 一并取下保留在本地，如图 3 - 5 所示：

其中 origin/master 和origin/ft-1为近程仓库的分支，而近程的这些援用状态是不会实时更新到本地的，比方近程仓库 origin/master 分支减少了一次提交，此时本地是感知不到的，所以本地的 origin/master 分支仍旧指向 C4 节点。咱们能够通过 fetch 命令来手动更新近程仓库状态

小提示：

并不是存在服务器上的能力称作是近程仓库，你也能够 clone 本地仓库作为近程，当然理论开发中咱们不可能把本地仓库当作私有仓库，说这个只是单纯的帮忙你更清晰的了解 分布式

fetch

说的艰深一点，fetch命令就是一次 下载 操作，它会将近程新减少的节点以及 援用 (分支 /HEAD) 的状态下载到本地，具体命令如下：

git fetch 近程仓库地址 / 分支名

pull

pull命令能够从近程仓库的某个援用拉取代码，具体命令如下：

git pull 近程分支名

其实 pull 的实质就是 fetch+merge，首先更新近程仓库 所有状态 到本地，随后再进行合并。合并实现后本地分支会指向 最新节点

另外 pull 命令也能够通过 rebase 进行合并，具体命令如下：

git pull --rebase 近程分支名

push

push命令能够将本地提交推送至近程，具体命令如下：

git push 近程分支名

如果间接 push 可能会失败，因为可能存在抵触，所以在 push 之前往往会先 pull 一下，如果存在抵触本地解决。push胜利后本地的近程分支援用会更新，与本地分支指向同一节点

综上所述

• 不论是 HEAD 还是 分支 ，它们都只是 援用 而已，援用 + 节点 是 Git 形成分布式的要害
• merge相比于 rebase 有更明确的工夫历史，而 rebase 会使提交更加线性该当优先应用
• 通过挪动 HEAD 能够查看每个提交对应的代码
• clone或 fetch 都会将近程仓库的所有 提交 、 援用 保留在本地一份
• pull的实质其实就是 fetch+merge，也能够退出--rebase 通过 rebase 形式合并

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)

2. 劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！