1 Git相关概念

1.1

以下所谈三个区，文件并不只是简单地在三个区转移，而是以复制副本的方式转移

使用 Git 管理的项目，拥有三个区域，分别是

• Working area工作区（亦称为 工作树Working Tree）、
• stage area 暂存区(亦称为 index 索引)、
• Git 仓库

对应地，Git 中的文件有三种状态

• modified 已修改 ：若工作区的文件被修改了，但还没有放到暂存区，就是 modified 状态。
• staged 已暂存 ：若被修改的文件已经从工作区到了暂存区，就是 staged 状态，因此我们也可以说，文件处于暂存区 = 文件是 staged 状态。此外，Git 会为 staged 状态的文件打上标记，以使其包含在下次 commit 的列表中
• committed 已提交 ：表示文件已经 “复制一份” 到了本地 Git 仓库中

1.2 HEAD、工作树Working Tree、分支Branch、索引

Working Tree ：实际就是 working area

Branch：branch可以有多个，其本质上是一个指向 commit 对象的可变指针

HEAD：HEAD只能有一个，其本质上是一个指向 正在工作中的本地 branch 的可变指针

简单来讲，就是你现在在哪儿，HEAD 就指向哪儿

更具体来说：HEAD指针指向我们所在的 branch，当我们在某个 branch 上创建新的 commit 时，branch 指针总是会指向当前 branch 的最新 commit

所以，HEAD指针 ——–> branch 指针 ——–> 最新 commit

例如当前我们处于 master 分支，所以HEAD这个指针指向了master分支指针

2. 命令

2.1 add 命令

add是个多功能的命令，主要有如下 3 个功效：

① 可以用它开始跟踪新文件，并放到暂存区

② 把已跟踪的、且已修改的文件放到暂存区

③ 把有冲突的文件标记为已解决状态

此外，当存在多个文件需要添加到暂存区时是，采用

git add . 

git commit 默认会将暂存区所有文件一并 commit

2.2 commit

Git 标准的工作流程是工作区 → 暂存区 → Git 仓库，但有时候这么做略显繁琐，此时可以跳过暂存区，直接将工作区中的修改提交到 Git 仓库，这时候 Git 工作的流程简化为了工作区 → Git 仓库

Git 提供了一个跳过使用暂存区域的方式， 只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤：

git commit -a -m "日志信息"

2.3 status

git status 命令无法直接显示 committed 文件的状态，它主要关注的是当前工作目录和staging area 中文件的状态。

当执行 git status 时，会显示以下信息：

1. 已修改但未 add 到 staging zone 的文件
2. 已 add 到staged zone 但未 commit 到 Git 仓库的文件
3. untracked 文件（即不在版本控制下的新文件）

对于已经 commit 的文件，如果它们没有新的未 commit 的改动，git status 将不会报告它们的存在，因为它默认那些文件干净的。

2.8 log和reflog

git log    //查看所有版本记录
#显示内容过多会自动进入多屏显示控制方式：空格向下翻页 、b 向上翻页 、q 退出

git log --pretty=oneline  //每个历史压缩到一行内显示，此时只显示 hash 值和备注

git log --oneline   //与上面的区别是 hash 值只显示一部分

git reflog   //显示历史只显示一行,并且显示指针(要移动到版本多少步)

2.9 reset【跳转 】到指定的版本

HEAD: 这是一个指针，用以标记历史版本

（ 1 ）
基于【部分hash值】跳转[推荐]，可以前进或后退

这个部分hash值，就是 git log --oneline 得到的。

#语法 git reset --hard [部分hash值]
#回退到第一个状态，即创建的状态
git reset --hard 699513b

（ 2 ）
使用^符号，只能后退

#一个^表示后退一步，n 个^表示后退 n 步
git reset --hard HEAD^^  

（ 3 ）
使用~符号，只能后退

#表示后退 n 步
git reset --hard HEAD~n

git reset --hard HEAD~3  //表示后退3步

# 在一行上展示所有的提交历史，以获取指定版本的版本号
git log --pretty=oneline

# 使用 git reset --hard 命令，根据指定的提交 ID 回退到指定版本
git reset --hard <CommitID>

# 在旧版本中使用 git reflog --pretty=oneline 命令，查看命令操作的历史
git reflog --pretty=onelone

# 再次根据最新的提交 ID，跳转到最新的版本
git reset --hard <CommitID>

2.10 reset 命令的三个参数对比

①–soft 参数

一句话：仅仅在本地库移动 HEAD 指针

–soft 是最轻的重置模式，它只重置分支指针，不会修改工作区和暂存区。
使用 --soft 时，Git 会将当前分支指向指定的提交，但是不会删除任何修改，工作区和暂存区的修改都会保留。

实际应用场景：
修改 commit 信息：commit的代码是正确的，但是想修改 commit 附带的信息，可以使用 git reset --soft HEAD^ 命令来重置分支指针，并修改提交信息，然后重新提交，因为工作区和暂存区还是最新的代码。

合并 commit：之前的 commit 都是正确的，每次 commit 一句诗，依次 commit 了四次，这种情况下，工作区、暂存区、Git 仓库都是4句诗。但是，我们想合并四次 commit 为一次。由于工作区和暂存区都保存了正确的四句诗，我们用 --soft 将 Git仓库回退到0句诗，再 commit 一次暂存区，这样，就将四句诗合并到一次 commit 了。

②–mixed 参数

一句话：不仅在本地库移动 HEAD 指针，还同步暂存区为与 HEAD 一致，但工作区不做处理

–mixed 是默认的重置模式，它既不会删除修改，也不会修改提交信息。使用 --mixed 模式时，Git 会将当前分支指向指定的 commit，并将暂存区同步为指定的 commit，但是工作区的修改不会被删除。

实际应用场景：
**取消暂存区的修改：**如果你不小心将修改添加到了暂存区，可以使用 git reset HEAD 命令将指定文件的修改从暂存区移除，然后重新add + commit 。此时，该命令与git restore --staged 作用类似
举例来说，Git 仓库中有1，2 号诗，工作区错误写成了 1，2，4号诗，并且还 add 到了暂存区。此时，mixed 模式将Git 仓库和工作区回退到2号阶段（Git本来就是 2 号，因此不发生改变），然后再将工作区改为1，2，3号并 add commit，这样，最终工作区、暂存区、Git 仓库都同步为了正确的1，2，3

撤销部分 commit：如果你只想撤销部分 commit ，可以使用 git reset --mixed HEAD~n 命令将最近的 n 次 commit reset 为指定commit，然后手动 add 需要保留的修改到暂存区，最后 commit。

③–hard 参数

**一句话：**对 Git 仓库、暂存区、工作区进行的统一回退

详细解释：
–hard 会完全撤销提交并删除所有的修改。使用 --hard 时，Git 会将当前分支指向指定的提交，并删除所有的修改，包括工作区和暂存区的修改。这意味着，使用 --hard 时，所有未提交的修改都将被永久删除，无法恢复。

实际应用场景：

撤销错误的提交：如果你提交了错误的代码，可以使用 git reset --hard HEAD^ 命令来撤销提交并删除所有的修改，然后重新提交正确的代码。
回退到历史版本：如果你想回退到某个历史版本，并且不需要保留任何修改，可以使用 git reset --hard 命令来重置当前分支到指定的提交。

举例：

现在的情况是：
每次添加一句诗，但是第三次时弄错了，添加成了第四句，因此
对于 Git 仓库中的txt文本，内容为：

床前明月光
疑是地上霜
低头思故乡
#显然，漏掉了第三句

对于暂存区，我们先在工作区中将补上第三句，再add，也即暂存区和工作区的文本内容都为：

床前明月光
疑是地上霜
举头望明月
低头思故乡

在这种情况下，如果使用 --hard模式回退一个版本，即两句诗的版本
Git 仓库和本地工作区都会变成：

床前明月光
疑是地上霜

而对于暂存区，当我们使用git status命令时，查询不到任何信息（暂存区内容被完全清空了，工作区的修改也被撤销，剩下都是稳态的东西不会再显示状态）

2. checkout

2.11 删除操作

删除也分几种情况。

2.11.1 手动删除本地文件

首先，我么应把删除也视为一种【修改】。

因此，如果文件已经纳入 Git 管理，我们右键删除了文件后，能在 Git中查询到记录，并且为了完成删除，我们需要 add 和 commit这个删除操作

比如，我们直接右键删除文件，此时用status命令应查到：

add commit 完成删除操作，并且能在日志查询到该记录

2.11.2 用命令删除

#从 Git 仓库、暂存区、工作区中同时移除对应的文件，即 index.js
git rm -f index.js

#只从 Git 仓库和暂存区中移除指定的文件，但保留工作区中的文件，即 index.css 文件
git rm --cached index.css

D 代表已删除，？？代表 untracked，即只存在于工作区，等待 add

2.11.3 误删除

git restore --staged <file_name> 将暂存区的修改重新放回工作区（包括对文件自身的操作，如添加文件、删除文件）

git restore <file_name> 丢弃工作区的修改（不包括对文件自身的操作，如添加文件、删除文件）
(1) 工作区、暂存区、Git 仓库已经同步的情况下，误删除了本地文件（即工作区文件）

例如，先将 txt文件 add 并 commit，然后右键删除本地文件，此时

#该命令可以
git restore a.txt

3. 忽略文件与版本号

忽略文件
一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。 在这种情况下，我们可以创建一个名为 .gitignore 的配置文件，列出要忽略的文件的匹配模式。

文件 .gitignore 的格式规范如下：

① 以 # 开头的是注释

② 以 / 结尾的是目录

③ 以 / 开头防止递归

④ 以 ! 开头表示取反

⑤ 可以使用 glob 模式进行文件和文件夹的匹配（glob 指简化了的正则表达式）

星号 * 匹配零个或多个任意字符
[abc] 匹配任何一个列在方括号中的字符 （此案例匹配一个 a 或匹配一个 b 或匹配一个 c）
问号 ? 只匹配一个任意字符
两个星号 ** 表示匹配任意中间目录（比如 a/**/z 可以匹配 a/z 、 a/b/z 或 a/b/c/z 等）
在方括号中使用短划线分隔两个字符， 表示所有在这两个字符范围内的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的数字）

版本号

每一次Commit对应一个 40 位长的版本号，在对更改内容使用 SHA -1 加密算法后得到的。
这样，根据版本号，可以避免内容被篡改。

其次, 根据版本号的前两位，在.git/objects 文件夹中，可以找到本次 Commit 的记录。

1.6 合并分支