Git核心知识总结

?作者简介：大家好，我是Leo，热爱Java后端开发者，一个想要与大家共同进步的男人😉😉
🍎个人主页：Leo的博客
💞当前专栏： 工具教程
?特色专栏： MySQL学习
🥭本文内容：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 概念汇总

概念名称	描述
工作区（Workspace）	就是在电脑里能看到的代码库目录，是我们搬砖的地方，新增、修改的文件会提交到暂存区
暂存区（stage 或 index）	用于临时存放文件的修改，实际上上它只是一个文件（.git/index），保存待提交的文件列表信息。
版本库/仓库（Repository）	Git的管理仓库，管理版本的数据库，记录文件/目录状态的地方，所有内容的修改记录（版本）都在这里。
服务端/远程仓库（origin 或 remote）	服务端的版本库，专用的Git服务器，为多人共享提供服务，承担中心服务器的角色。本地版本库通过push指令把代码推送到服务端版本库。
本地仓库	用户机器上直接使用的版本库
分支（Branch）	分支是从主线分离出去的“副本”，可以独立操作而互不干扰，仓库初始化就有一个默认主分支master。
头（HEAD）	HEAD类似一个“指针”，指向当前活动分支的最新版本。
提交（Commit）	把暂存区的所有变更的内容提交到当前仓库的活动分支。
推送（Push）	将本地仓库的版本推送到服务端（远程）仓库，与他人共享。
拉取（Pull）	从服务端（远程）仓库获取更新到本地仓库，获取他人共享的更新。
获取（Fetch）	从服务端（远程）仓库更新，作用同拉取（Pull），区别是不会自动合并。
冲突（Conflict）	多人对同一文件的工作副本进行更改，并将这些更改合并到仓库时就会面临冲突，需要人工合并处理。
合并（Merge）	对有冲突的文件进行合并操作，Git会自动合并变更内容，无法自动处理的冲突内容会提示人工处理。
标签（Tags）	标签指的是某个分支某个特定时间点的状态，可以理解为提交记录的别名，常用来标记版本。
master（或main）	仓库的“master”分支，默认的主分支，初始化仓库就有了。Github上创建的仓库默认名字为“main”
origin/master	表示远程仓库（origin）的“master”分支
origin/HEAD	表示远程仓库（origin）的最新提交的位置，一般情况等于“origin/master”

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 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查看安装版本号

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

6.Git快速入门

6.1 创建仓库

创建仓库的方式有两种。

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

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

然后gitbash打开，初始化为git仓库。

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

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

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

通过以下命令进行克隆：

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

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

6.2 暂存区add

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

指令	描述
git add [file1] [file2]	添加文件到暂存区，包括修改的文件、新增的文件
git add [dir]	同上，添加目录到暂存区，包括子目录
git add .	同上，添加所有修改、新增文件（未跟踪）到暂存区
git rm [file]	删除工作区文件，并且将这次删除放入暂存区

# 查看仓库状态
$ 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 查看所有的提交记录包括回退记录。

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

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

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

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

$ git commit --amend -m [message]

取消暂存的文件

git reset filename

撤消对文件的修改:

git checkout -- filename

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

🔥指令：

指令	描述
git commit -m ‘说明’	提交变更，参数-m设置提交的描述信息，应该正确提交，不带该参数会进入说明编辑模式
git commit -a	参数-a，表示直接从工作区提交到版本库，略过了git add步骤，不包括新增的文件
git commit [file]	提交暂存区的指定文件到仓库区
git commit --amend -m	使用一次新的commit，替代上一次提交，会修改commit的hash值（id）
git log -n20	查看日志(最近20条)，不带参数-n则显示所有日志
git log -n20 --oneline	参数“--oneline”可以让日志输出更简洁（一行）
git log -n20 --graph	参数“--graph”可视化显示分支关系
git log --follow [file]	显示某个文件的版本历史
git blame [file]	以列表形式显示指定文件的修改记录
git reflog	查看所有可用的历史版本记录（实际是HEAD变更记录），包含被回退的记录（重要）
git status	查看本地仓库状态，比较常用的指令，加参数-s简洁模式

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变更记录），包括被撤销回退的提交记录。

$ 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用来比较不同文件版本之间的差异。

指令	描述
git diff	查看暂存区和工作区的差异
git diff [file]	同上，指定文件
git diff --cached	查看已暂存的改动，就是暂存区与新版本HEAD进行比较
git diff --staged	同上
git diff --cached [file]	同上，指定文件
git diff HEAD	查看已暂存的+未暂存的所有改动，就是与最新版本HEAD进行比较
git diff HEAD~	同上，与上一个版本比较。HEAD~表示上一个版本，HEAD~10为最近第10个版本
git diff [id] [id]	查看两次提交之间的差异
git diff [branch]	查看工作区和分支直接的差异

# 查看文件的修改
$ 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 远程仓库指令

指令	描述
git clone [git地址]	从远程仓库克隆到本地（当前目录）
git remote -v	查看所有远程仓库，不带参数-v只显示名称
git remote show [remote]	显示某个远程仓库的信息
git remote add [name] [url]	增加一个新的远程仓库，并命名
git remote rename [old] [new]	修改远程仓库名称
git pull [remote] [branch]	取回远程仓库的变化，并与本地版本合并
git pull	同上，针对当前分支
git fetch [remote]	获取远程仓库的所有变动到本地仓库，不会自动合并！需要手动合并
git push	推送当前分支到远程仓库
git push [remote] [branch]	推送本地当前分支到远程仓库的指定分支
git push [remote] --force/-f	强行推送当前分支到远程仓库，即使有冲突，??很危险！
git push [remote] --all	推送所有分支到远程仓库
git push –u	参数–u表示与远程分支建立关联，第一次执行的时候用，后面就不需要了
git remote rm [remote-name]	删除远程仓库
git pull --rebase	使用rebase的模式进行合并

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.案例

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

git fetch origin

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

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 分支命令

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

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

8.3 分支冲突

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

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

1. 快速合并

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

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

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

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

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

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

2. 普通合并

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

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

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

1. 第一种情况

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

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

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

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

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

2. 第二种情况

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

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

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

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

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

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

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

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

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

此时我们觉得都进行保留，然后删除其他多余内容。

然后进行代码提交。

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

大功告成!!

9.Git的版本回退

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

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

9.1 版本回退命令

指令	描述
git checkout .	撤销工作区的（未暂存）修改，把暂存区恢复到工作区。不影响暂存区，如果没暂存，则撤销所有工作区修改
git checkout [file]	同上，file指定文件
git checkout HEAD .	撤销工作区、暂存区的修改，用HEAD指向的当前分支最新版本替换工作区、暂存区
git checkout HEAD [file]	同上，file指定文件
git reset	撤销暂存区状态，同git reset HEAD，不影响工作区
git reset HEAD [file]	同上，指定文件file，HEAD可省略
git reset [commit]	回退到指定版本，清空暂存区，不影响工作区。工作区需要手动git checkout签出
git reset --soft [commit]	移动分支master、HEAD到指定的版本，不影响暂存区、工作区，需手动git checkout签出更新
git reset --hard HEAD	撤销工作区、暂存区的修改，用当前最新版
git reset --hard HEAD~	回退到上一个版本，并重置工作区、暂存区内容。
git reset --hard [commit]	回退到指定版本，并重置工作区、暂存区内容。
git revert[commit]	撤销一个提交，会用一个新的提交（原提交的逆向操作）来完成撤销操作，如果已push则重新push即可

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

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

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

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

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

9.2 reset

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

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

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

模式名称	描述	HEAD的位置	暂存区	工作区
soft	回退到某一个版本，工作区不变，需手动git checkout	修改	不修改	不修改
mixed(默认)	撤销暂存区状态，不影响工作区，需手动git checkout	修改	修改	不修改
hard	重置未提交修改（工作区、暂存区）	修改	修改	修改

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

1. 撤销暂存区

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

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

$ git reset --hard HEAD

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

$ git reset --hard HEAD~

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

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

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

$ git reset --hard 891350d

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

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

git reflog

10.IDEA集成Git

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

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

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

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

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

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

然后讲代码push到远程仓库。

相比于命令行，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

12.总结

以上便是本文的全部内容，本人才疏学浅，文章有什么错误的地方，欢迎大佬们批评指正！我是Leo，一个在互联网行业的小白，立志成为更好的自己。

如果你想了解更多关于Leo，可以关注公众号-程序员Leo，后面文章会首先同步至公众号。