Git 核心知识总结

Git 总览

1. 什么是 Git

在了解 Git 之前，我们先了解一下版本控制这个概念。

1.1 什么是版本控制

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 除了项目源代码，你可以对任何类型的文件进行版本控制。

1.2 为什么需要版本控制

有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致项目问题出现的原因，又是谁在何时报告了某个功能缺陷等等。

1.3 本地版本控制系统

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

Git 是当前最先进、最主流的分布式版本控制系统，免费、开源！核心能力就是版本控制。再具体一点，就是面向代码文件的版本控制，代码的任何修改历史都会被记录管理起来，意味着可以恢复到到以前的任意时刻状态。支持跨区域多人协作编辑，是团队项目开发的必备基础，所以 Git 也就成了程序员的必备技能。

本地版本控制系统

2.Git 的来源

Git 是一种分布式版本控制系统，它的设计和开发最初由林纳斯・托瓦兹（Linus Torvalds）领导，他也是 Linux 操作系统的创始人。Git 的开发始于 2005 年，其背景和初始目的与 Linux 开发社区的需求密切相关。

2.1 背景和初始动机

在 Git 之前，Linux 内核的开发使用的是一个名为 BitKeeper 的商业版本控制系统。这个系统对 Linux 社区是免费的，但在 2005 年，由于一些争议和许可问题，Linux 社区失去了对 BitKeeper 的免费许可。这促使托瓦兹寻找一个新的工具来管理 Linux 内核的开发。

托瓦兹对版本控制系统有几个明确的需求和目标：

1. 「性能」：由于 Linux 内核的庞大和复杂性，性能成为一个关键因素。Git 需要高效地处理大型项目。
2. 「分布式架构」：Git 被设计为分布式系统，意味着每个开发者的计算机上都有整个代码库的完整历史记录，这样可以减少对中央服务器的依赖。
3. 「数据完整性」：Git 强调数据的完整性。它通过对文件内容和目录结构使用 SHA-1 哈希来确保代码历史不被篡改。
4. 「简单的分支和合并」：在 Linux 开发中，分支和合并操作非常频繁。Git 被设计为使这些操作尽可能简单和高效。

2.2 Git 的发展

Git 最初是作为一个命令行工具发布的，但随着时间的推移，围绕 Git 开发了大量的图形界面工具和增强功能，使其更加用户友好。Git 迅速在开源社区中获得了广泛的接受，并逐渐成为世界上最流行的版本控制系统。

2.3 GitHub 和 Git 的普及

Git 的普及也与 GitHub 这样的平台紧密相关。GitHub 是一个基于 Web 的 Git 版本库托管服务，它提供了图形界面，并增加了如分叉、拉取请求和社交网络功能等特性，这些都极大地促进了 Git 的普及和开源文化的发展。

3.Git 的特点

开源免费，使用广泛。

• 强大的文档（代码）的历史版本管理，直接记录完整快照（完整内容，而非差异），支持回滚、对比。
• 分布式多人协作的的代码协同开发，几乎所有操作都是本地执行的，支持代码合并、代码同步。
• 简单易用的分支管理，支持高效的创建分支、合并分支。

4.Git 的基本概念

4.1 概念汇总

4.2 工作区 / 暂存区 / 仓库

工作区（Workspace）就是在电脑里能看到的代码库目录，是我们搬砖的地方，新增、修改的文件会提交到暂存区。

• 在这里新增文件、修改文件内容，或删除文件。

暂存区（stage 或 index）用于临时存放文件的修改，实际上上它只是一个文件（.git/index），保存待提交的文件列表信息。

• 用 git add 命令将工作区的修改保存到暂存区。

版本库 / 仓库（Repository 仓库）Git 的管理仓库，管理版本的数据库，记录文件 / 目录状态的地方，所有内容的修改记录（版本）都在这里。就是工作区目录下的隐藏文件夹.git，包含暂存区、分支、历史记录等信息。

• 用 git commit 命令将暂存区的内容正式提交到版本库。
• master 为仓库的默认分支 master，HEAD 是一个 “指针” 指向当前分支的最新提交，默认指向最新的 master。

4.3 Git 的基本流程

Git 的工作流程核心就下面几个步骤。

1. 准备仓库：创建或从服务端克隆一个仓库。
2. 编写代码：在工作目录中添加、修改代码。
3. 暂存（git add）：将需要进行版本管理的文件放入暂存区域。
4. 提交（git commit）：将暂存区域的文件提交到 Git 仓库。
5. 推送（git push）：将本地仓库推送到远程仓库，同步版本库。
6. 获取更新（fetch/pull）：从服务端更新到本地，获取他人推送的更新，与他人协作、共享。

Git 工作 流程

• git commit -a 指令省略了 add 到暂存区的步骤，直接提交工作区的修改内容到版本库，不包括新增的文件。
• git fetch、git pull 都是从远程服务端获取最新记录，区别是 git pull 多了一个步骤，就是自动合并更新工作区。
• git checkout . 、git checkout [file] 会清除工作区中未添加到暂存区的修改，用暂存区内容替换工作区。
• git checkout HEAD .、 git checkout HEAD [file] 会清除工作区、暂存区的修改，用 HEAD 指向的当前分支最新版本替换暂存区、工作区。
• git diff 用来对比不同部分之间的区别，如暂存区、工作区，最新版本与未提交内容，不同版本之间等。
• git reset 是专门用来撤销修改、回退版本的指令，替代上面 checkout 的撤销功能。

「基本的 Git 工作流程如下：」

1. 在工作目录中修改文件。
2. 暂存文件，将文件的快照放入暂存区域。
3. 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。

4.4 Git 的状态

Git 在执行提交的时候，不是直接将工作区的修改保存到仓库，而是将暂存区域的修改保存到仓库。要提交文件，首先需要把文件加入到暂存区域中。因此，Git 管理的文件有三（+2）种状态：

• 「未跟踪 (untracked)：」 新添加的文件，或被移除跟踪的文件，未建立跟踪，通过 git add 添加暂存并建立跟踪。
• 「未修改：」 从仓库签出的文件默认状态，修改后就是 “已修改” 状态了。
• 「已修改 (modified)：」 文件被修改后的状态。
• 「已暂存 (staged)：」 修改、新增的文件添加到暂存区后的状态。
• 「已提交 (committed)：」 从暂存区提交到版本库。

5.Git 的安装

Git 官网：https://www.git-scm.com/ 下载安装包进行安装。Git 的使用有两种方式：

• 「命令行」：Git 的命令通过系统命令行工具，或 Git 提供的命令行工具运行（C:\Program Files\Git\git-bash.exe）
• 「GUI 工具」：Windows (GUI)、Mac (GUI) 工具，需单独安装，使用更简单、更易上手。

「下一步傻瓜式安装即可。」

指令 git --version 查看安装版本号

1
2

$ git --version
git version 2.39.2.windows.1

6.Git 快速入门

6.1 创建仓库

创建仓库的方式有两种。

1. 一种是创建全新的仓库，基于 git init 命令来，会在当前目录初始化创建仓库。
2. 一种是通过 git clone + 仓库地址的方式，一般叫做克隆远程仓库。

首先准备一个本地的工作目录：GitRepo

新建本地仓库

1
2

$ git init
Initialized empty Git repository in D:/IDEA Workplace/GitRepo/.git/

创建完多出了一个被隐藏的.git 目录，这就是本地仓库 Git 的工作目录。

生成.git 文件夹

克隆远程仓库，如在 gitee 上创建的仓库 https://gitee.com/gaoziman/vue3-doc.git

通过以下命令进行克隆：

1

git clone https://gitee.com/gaoziman/vue3-doc.git

拉取远程代码

可以看到远程仓库就出现在我们的本地工作空间

远程代码出现在本地仓库

6.2 暂存区 add

git add 命令就是把要提交的所有修改放到 「暂存区（Stage）」，然后，执行 git commit 就可以一次性把暂存区的所有修改提交到仓库。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# 查看仓库状态
$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   Nodejs.md

no changes added to commit (use "git add" and/or "git commit -a")

Administrator@WIN-20231112VVY MINGW64 /d/IDEA Workplace/GitRepo/vue3-doc/01-环境 (master)
# 添加到指定文件到暂存区
$ git add Nodejs.md

Administrator@WIN-20231112VVY MINGW64 /d/IDEA Workplace/GitRepo/vue3-doc/01-环境 (master)
# 继续查看仓库状态
$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   Nodejs.md

修改之后通过 git add 文件名 即可把文件提交至暂存区

把文件提交至暂存区

6.3 commit 提交

git commit 提交是以时间顺序排列被保存到数据库中的，就如游戏关卡一样，每一次提交（commit）就会产生一条记录：id + 描述 + 快照内容。

• 「commit id」：根据修改的文件内容采用摘要算法（SHA1）计算出不重复的 40 位字符，这么长是因为 Git 是分布式的，要保证唯一性、完整性，一般本地指令中可以只用前几位（6）。即使多年以后，依然可通过 id 找到曾经的任何内容和变动，再也不用担心丢失了。
• 「描述」：针对本次提交的描述说明，建议 **「准确」** 填写，就跟代码中的注释一样，很重要。
• 「快照」：就是完整的版本文件，以对象树的结构存在仓库下 \.git\objects 目录里，这也是 Git 效率高的秘诀之一。

我们可以通过 git reflog 查看所有的提交记录包括回退记录。

查看回退记录

我们可以通过提交所有的指令到仓库。

1

 git commit -a -m'修改README的版权信息'

有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。 此时，可以运行带有 --amend 选项的提交命令尝试重新提交：

如果代码没有任何新变化，则用来改写上一次 commit 的提交信息

1

$ git commit --amend -m [message]

取消暂存的文件

1

git reset filename

撤消对文件的修改:

1

git checkout -- filename

用参数 --oneline 可以让日志输出更简洁（一行）

git log --oneline 输出

「🔥指令：」

6.4 提交的唯一标识 ID

每一个提交都有一个唯一标识，主要就是提交的 hash 值 commit id，在很多指令中会用到，如版本回退、拣选提交等，需要指定一个提交。那标识唯一提交有两种方式：

• 首先就是 commit id，一个 40 位编码，指令中使用的时候可以只输入前几位（6 位）即可。
• 还有一种就是 HEAD~n，是基于当前 HEAD 位置的一个相对坐标。
  • HEAD 表示当前分支的最新版本，是比较常用的参数。
  • HEAD^ 上一个版本，HEAD^^ 上上一个版本。
  • HEAD~ 或 HEAD~1 表示上一个版本，以此类推，HEAD^10 为最近第 10 个版本。
  • HEAD@{2} 在 git reflog 日志中标记的提交记录索引。

通过 git log、git reflog 可以查看历史日志，可以看每次提交的唯一编号（hash）。区别是 git reflog 可以查看所有操作的记录（实际是 HEAD 变更记录），包括被撤销回退的提交记录。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$ git reflog -n10
5acc914 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~
738748b (dev) HEAD@{1}: reset: moving to HEAD~
9312c3e HEAD@{2}: reset: moving to HEAD~
db03fcb HEAD@{3}: reset: moving to HEAD~
1b81fb3 HEAD@{4}: reset: moving to HEAD~
41ea423 HEAD@{5}: reset: moving to HEAD~
d3e15f9 HEAD@{6}: reset: moving to d3e15f9
1b81fb3 HEAD@{7}: reset: moving to HEAD~1
41ea423 HEAD@{8}: reset: moving to HEAD~
d3e15f9 HEAD@{9}: reset: moving to HEAD~

查看变更记录

6.5 diff 比较

git diff 用来比较不同文件版本之间的差异。

1
2
3
4
5
6
7
8

# 查看文件的修改
$ git diff README.md

# 查看两次提交的差异
$ git diff 8f4244 1da22

# 显示今天你写了多少行代码：工作区+暂存区
$ git diff --shortstat "@{10 day ago}"

7. 远程仓库

Git 作为分布式的版本管理系统，我们每个本地终端都有属于自己的 Git 仓库。但团队协作还需一个中间仓库，作为控制中心，同步各个仓库。于是服务端（远程）仓库就来承担这个职责，服务端不仅有仓库，还配套相关管理功能，这就是所谓的 「远程仓库」 。

远程仓库

• 公共 Git 服务器，如 Github、码云 Gitee、腾讯 Coding 等。
• 搭建私有 Git 服务器，如开源的 Gitlab、Gitea、等。

7.1 远程仓库指令

7.2 push 和 pull

git push、git pull 是团队协作中最常用的指令，用于同步本地、服务端的更新，与他人协作。

「🔸推送」（push）：推送本地仓库到远程仓库。

• 如果推送的更新与服务端存在冲突，则会被拒绝，push 失败。一般是有其他人推送了代码，导致文件冲突，可以先 pull 代码，在本地进行合并，然后再 push。

「🔸拉取」（pull）：从服务端（远程）仓库更新到本地仓库。

• git pull：拉取服务端的最新提交到本地，并与本地合并，合并过程同分支的合并。
• git fetch：拉取服务端的最新提交到本地，不会自动合并，也不会更新工作区。

7.4 fetch 和 pull 有什么区别

1. Git Fetch

git fetch 命令用于从另一个仓库（例如，远程仓库）下载新的分支和数据，但不会自动合并或修改你当前工作目录下的文件或分支。fetch 命令会把远程仓库的所有信息拉取到本地仓库，但这些改动不会反映在你的当前工作分支上，除非你明确地进行合并。

换句话说，git fetch 是一种安全的方式来查看别人已经做了哪些工作，而这些变更在你用 git fetch 之后不会影响你当前的工作状态。如果你想要让这些变更影响你的当前分支，你需要用 git merge 手动合并，如 git merge origin/master（如果你是从 master 分支上 fetch 的）。

2. Git Pull

git pull 命令实际上是 git fetch 加上 git merge 命令的组合。当你执行 git pull，Git 会从远程仓库获取最新的版本信息，然后尝试自动合并到你当前的分支。通常情况下，这意味着它将远程的更新内容合并到你当前分支的本地副本中。

在简单的情况下，git pull 会顺利地将远程变更合并到你的本地分支，你的工作流程可以无缝继续。然而，如果在 fetch 的数据与你本地的修改存在冲突时，你可能需要手动解决这些冲突。

3. 使用场景对比

在不清楚远程分支的情况下，你可能更倾向于首先使用 git fetch 来查看有哪些更新，待检查完更新内容后再决定是否合并到当前分支。这是一种更为谨慎的做法，尤其适用于复杂的合并操作，或者当你不希望自动将更改应用到本地仓库时使用。

另一方面，如果你相信远程的变更不会引起任何问题，并且希望你的本地分支保持与远程分支的同步，可以直接使用 git pull。

4. 案例

获取远程仓库的更新数据，但不合并到当前分支：

1

git fetch origin

获取远程仓库的更新数据并自动合并到当前分支：

1

git pull origin master  # 拉取origin远程仓库的master分支并合并到当前分支

git fetch 用于安全地查看远程变更，而 git pull 则用于获取并立刻应用这些变更。两者合适的使用取决于你想如何管理远程数据和本地分支的关系。

8. 分支

几乎每一种版本控制系统都以某种形式支持分支，一个分支代表一条独立的开发线。

使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。

分支示意

Git 分支实际上是指向更改快照的指针。

有人把 Git 的分支模型称为 **「必杀技特性」**，而正是因为它，将 「Git」 从版本控制系统家族里区分出来。

8.1 branch

加入，准备 1 月份发布新版本，要新开发一些新功能，占领市场。你和小伙伴 「张三」 一起负责开发一个新功能 A，开发周期 2 周，在这两周你们的代码不能影响其他人，不影响主分支。这个时候就可以为这个新功能创建一个分支，你们两在这个分支上干活，2 周后代码开发完了、测试通过，就可以合并进要发版的开发分支了。安全、高效，不影响其他人工作，完美！

实际开发中，我们可能会有多个分支进行开发。

• 「master」：作为主分支，存放稳定的代码，就是开发后测试通过的代码，不允许随便修改和合并。
• 「开发分支」：用于团队日常开发用，比如团队计划 12 月份开发 10 个功能并发版，则在此分支上进行，不影响主分支的稳定，如果我们开发到一个成熟阶段，依然可以合并到 master 主分支。

❝

**「分支」** 就是指向某一个提交记录的 “指针” 引用，因此创建分支是非常快的，不管仓库多大。当我们运行 git branch dev 创建了一个名字为 dev 的分支，Git 实际上是在.git\refs\heads 下创建一个 dev 的引用文件（没有扩展名）。

❞

8.2 分支命令

我这里讲这些命令总结为思维导图，大家可以参考一下。

branch 分支示意导图

列出了当前的所有分支，星号 “*” 开头的 “main” 为当前活动分支。

列出当前的所有分支

8.3 分支冲突

把两个分支的修改内容合并到一起，常用的合并指令 git merge [branch]，将分支 [branch] 合并到当前分支。根据要合并的内容的不同，具体合并过程就会有多种情况。

首先我们准备一个案例项目，我已经在 gitee 准备好了，非常简单，只有三个简单的文件。

gitee 代码

1. 快速合并

合并 dev 到 master，注意要先切换到 master 分支，然后执行 git merge dev，把 dev 合并到当前分支。

首先创建 dev 分支并切换到 dev 分支上去。

创建 dev 分支

然后再 dev 分支上面创建一个 b.txt 文件，随之提交到远程仓库中。

BP Network

可以看到我们远程仓库的 dev 分支上面已经有了 b.txt 这个文件。

BP Network

然后切换到 master 分支上面，把 dev 分支合并到我们的 master 主分支上面。

BP Network

同时可以看到我们远程仓库中 master 分支也同步到了 dev 分支的 b.txt 文件。

BP Network

2. 普通合并

如果 master 有变更，存在分支交叉，则会把两边的变更合并成一个提交。

• 如果两边变更的文件不同，没有什么冲突，就自动合并了。
• 如果有修改同一个文件，则会存在冲突，到底该采用哪边的，程序无法判断，就换产生冲突。冲突内容需要人工修改后再重新提交，才能完成最终的合并。

我们在远程仓库 master 分支中手动更改 a.txt 文件来演示。

1. 第一种情况

BP Network

此时我们在本地仓库中更改其他文件，只要不是 a.txt 即可，然后 push 到远程。

BP Network

此时发现我们当前本地仓库的版本号与远程仓库 master 分支的版本号不一致，导致提交不上去。

这种情况还是比较简单的，只需要通过 git pull 命令将本地版本与远程版本同步即可

BP Network

此时会进行自动合并到本地分支，并当做一次提交，提交信息大家也可以进行更改，我这里默认即可。

BP Network

此时再次提交即可成功提交到远程仓库中。

2. 第二种情况

上面那种方式处理起来比较简单，因为是处理不同的文件。

下面我来演示一下对于同一个文件冲突情况进行解决。

我们在远程仓库手动添加了以下这句话进行对 b.txt 文件的修改。(可以理解为程序员 A 修改了 b.txt 文件并提交到远程仓库中去。)

BP Network

此时程序员 B 也在本地修改了 b.txt 文件。

BP Network

然后通过一系列命令提交至远程仓库。

可以发现出现冲突之后，我们立即通过 git pull 命令进行了同步，但是初始我们的这里发生了很多变化，变成了 **「master | MENERGING」**。

BP Network

此时这种情况就是因为在自动合并的时候出现了冲突，git 无法帮助我们解决，需要我们自己手动解决冲突。

然后我们在本地打开 b.txt 文件。

可以看到确实也把远程更改的内容同步过来了，这里就需要我们手动解决，由我们和另外一个程序员协商到底是保留谁的内容或者是都保留。

BP Network

然后进行代码提交。

BP Network

此时可以发现远程仓库 b.txt 文件内容已经发现了改变，并且是由我们手动解决并提交的。

BP Network

大功告成！！

9.Git 的版本回退

如果发现我们编写代码中写错了要怎么办，但又分好几种情况，我们依次往下看。

• ❓还没提交的怎么撤销？ – checkout
  • 还未提交的修改（工作区、暂存区）不想要了，用签出指令（checkout）进行撤销清除。
  • 或者用 checkout 的新版回滚指令 reset。
• ❓「已提交但么有 push 的提交如何撤销？」—— reset、revert
• ❓「已 push 的提交如何撤销？」—— 同上，先本地撤销，然后强制推送 git push origin -f，「⚠️注意慎用！」 记得先 pull 获取更新。

9.1 版本回退命令

• git checkout .、git checkout [file] 会清除工作区中未添加到暂存区的修改，用暂存区内容替换工作区。
• git checkout HEAD .、git checkout HEAD [file] 会清除工作区、暂存区的修改，用 HEAD 指向的当前分支最新版本替换暂存区、工作区。

1. 只撤销工作区的修改（未暂存）

撤销工作区的（未暂存）修改，把暂存区恢复到工作区。不影响暂存区，如果没暂存，则撤销所有工作区修改。

BP Network

2. 撤销工作区、暂存区的修改

撤销工作区、暂存区的修改，用 HEAD 指向的当前分支最新版本替换工作区、暂存区

BP Network

9.2 reset

reset 是专门用来撤销修改、回退版本的指令，支持的场景比较多，多种撤销姿势，所以参数组合也比较多。简单理解就是移动 master 分支、HEAD 的 “指针” 地址，理解这一点就基本掌握 reset 了。

reset 有三种模式，对应三种参数：mixed（默认模式）、soft、hard。三种参数的主要区别就是对工作区、暂存区的操作不同。

• mixed 为默认模式，参数可以省略。
• 只有 hard 模式会重置工作区、暂存区，一般用这个模式会多一点。

BP Network

穿梭前，用 git log 可以查看提交历史，以便确定要回退到哪个版本。要重返未来，用 git reflog 查看命令历史，以便确定要回到未来的哪个版本。

1. 撤销暂存区

这个其实跟刚刚的 git checkout HEAD . 是一样的。

2. 撤销工作区、暂存区修改

1

$ git reset --hard HEAD

3. 回退版本库到上一个版本，并重置工作区、暂存

1

$ git reset --hard HEAD~

可以看到他已经回到了我们上一个版本。

BP Network

通过 git log 日志查看也没有了之前的记录，而是被 HEAD 指向到上一个版本。

BP Network

4. 回到原来的版本，并重置工作区、暂存

1

$ git reset --hard 891350d

可以看到他又回到上上一步，也就是对上一步操作进行撤销。

BP Network

5. 查看所有历史提交记录

1

git reflog

BP Network

10.IDEA 集成 Git

通过以上内容，我们对 Git 整个工作流程有了一些认识，以及知道如何使用 Git 进行平时的开发。

但是在真实的开发中，我们可能并不是使用命令行进行操作，而是在 IDEA 中进行图形化操作，我们写完代码即可进行提交。

我们打开 IDEA，依次在 settings —》Version Control —》 Git。

选择自己的 Git 安装路径，然后进行测试看是否成功。

BP Network

点击 Test 之后看到自己对应的 Git 版本号之后即可说明我们初步测试成功。

BP Network

然后就可以在 IDEA 中进行代码的编写。

BP Network

BP Network

相比于命令行，IDEA 的图形化操作是不是让人更省心，简单易上手。

11. 参考文献

• https://git-scm.com/book/zh/v2
• https://www.yuque.com/kanding/ktech/ccgylqhnb94ug4bu#LlJg3
• https://javaguide.cn/tools/git/git-intro.html
• https://www.yiibai.com/git