初始演示仓库

git init
git add README.md && git commit -m "first commit"
git add .gitignore && git commit -m "add ignore file"
git add main.py && git commit -m "add main file"
git log --pretty=oneline

下面演示的每个环节都需要基于初始的演示仓库来操作

如何查看某一个提交记录的详细内容 上文已介绍 这里不再赘述了

git checkout

git checkout 不带文件路径 对工作区安全

checkout对工作区是安全的 不会丢弃工作区所做的更改

在工作区中新增tests/test.py文件
并将该文件加入暂存区
git add tests/test.py
然后checkout到上一个提交
git checkout 1bf76dd2df0af778721ce3084f0204105a394cc5

HEAD状态

HEAD 会直接指向 1bf76dd2df0af778721ce3084f0204105a394cc5 提交
进入分离 HEAD 状态
即不再指向分支引用

然后提取1bf76dd2df0af778721ce3084f0204105a394cc5提交的文件快照依次更新到暂存区和工作区

git checkout [branch] 执行过程与上面类似
区别在于HEAD会指向[branch]这个分支的引用
checkout 带有文件路径 对工作区不安全

git checkout fa7557c5c8f4c2ecd4a9ba3308fded322f015ff6 README.md
git reset soft模式

git checkout master && cat .git/refs/heads/master
git reset --soft 1b0f9054582d9390dfd3d47e1127d692638cd818
git status

将HEAD及其指向的分支引用指向1b0f9054582d9390dfd3d47e1127d692638cd818 提交

HEAD指向的分支引用不变
但分支引用变成了1b0f9054582d9390dfd3d47e1127d692638cd818

若 HEAD 原本处于分离 HEAD 状态，则只会更新 HEAD 本身

它不会再对暂存区以及工作区进行任何更改
暂存区和工作区依然保留着原来的 406caab89533dcd17edc86bc2037d9134f543e66 提交之后的文件快照与文件
mixed模式

会重置提交历史
还会更新暂存区

git checkout master && cat .git/refs/heads/master
git reset --mixed 5c8d38b72eb64a55b57d85d448407337773758d5

1、重置提交历史跟soft模式相同
2、之后还会更新暂存区 将其填充为5c8d38b72eb64a55b57d85d448407337773758d5提交的文件快照
暂存区的原有内容将会丢失
3、不会对工作区进行任何更改
工作区依然保留着68260c826b73d08505765ef82d20b027592dfe88提交之后的文件
hard模式

git checkout master && cat .git/refs/heads/master
git reset --hard dde4ac13ab0f41ba0575be2de44f4368c6ebd280

1、更新HEAD指向dde4ac13ab0f41ba0575be2de44f4368c6ebd280提交 ，重置提交历史和暂存区的过程是soft和mixed相同
2、更新暂存区 将其填充为dde4ac13ab0f41ba0575be2de44f4368c6ebd280提交的文件快照，暂存区原有内容将会丢失
3、更新工作区 将其填充为dde4ac13ab0f41ba0575be2de44f4368c6ebd280提交的文件快照，工作区中的原有内容将会丢失

工作区和暂存区的未提交更改丢失后无法再通过 Git 找回
找回提交历史

reset 后丢失的提交历史仍然能够恢复
因为只是更新了 HEAD 指向的提交
而没有对实际的提交对象做任何更改

git reflog
git reset --hard 0f9fcca
就能恢复原来的提交历史

取消暂存文件

在工作区新增hello.py、world.py两个文件
同时加入暂存区
git add . 

将其中一个文件取消暂存

git reset world.py

从 HEAD 提交中匹配 world.py 对应的文件快照
将匹配到的文件快照复制到暂存区

git status

分别提交
git commit -m "add hello.py"
# 在另一个提交中提交 world.py
git add world.py
git commit -m "add world.py"
git revert 怎么修改的 就怎么修改回去

比如
修改之前name=平凡人
修改之后name=笔记

revert
之前:name=笔记
之后:name=平凡人

用于回滚某一个（或多个）提交引入的更改

revert 操作会接收指定的提交
反转该提交引入的更改
并创建一个新的「回滚提交」记录反转更改
然后更新分支引用
使其指向该提交

步骤

• 将反转指定提交的更改合并到工作区
• 将更改添加到暂存区
• 创建新的提交

要求

提供一个干净的暂存区（即和 HEAD 提交状态一致）
且要求工作区的本地更改不会被合并操作覆盖
否则回滚会失败

git restore

将指定文件取消暂存

将暂存区中的 main.py 还原为 HEAD 中的内容
此时 HEAD 是默认的 source

git restore --staged main.py

放弃工作区中对该文件的更改

git restore main.py

可以选择将其还原为暂存区中的内容
因为此时暂存区中的内容和 HEAD 相同

暂存更改后再恢复

场景

当前分支修改了一些文件
但还不足以组织成提交或者包含了多个提交的内容
突然有紧急情况需要开始一项新的任务
此时希望可以将工作区和暂存区的本地更改暂时保存起来
以备在其他工作完成后可以从这里继续

git stash

会将本地更改保存起来
并将工作区和暂存区恢复到与 HEAD 提交相匹配的状态
此时可以切换到其他分支或者继续在当前分支完成其他任务
之后再将暂存的内容取回

用法

# 保存当前更改（添加 -u 选项以包括未跟踪的新文件）
git stash -u
# 完成其他任务...
# 恢复暂存的更改
git stash pop

图解说明

基于基础版本开发迭代1

迭代1还未提交来了一个紧急的迭代2

迭代2也是基于基础版本开发

此时将未提交的迭代1保存

等迭代2开发完了 再把迭代1恢复