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 时,会显示以下信息:
- 已修改但未 add 到 staging zone 的文件
- 已 add 到staged zone 但未 commit 到 Git 仓库的文件
- 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 的记录。