命令	说明
git stash	能够将所有未提交的修改（工作区和暂存区）保存至堆栈中，用于后续恢复当前工作目录。
git stash save "注释内容"	作用等同于git stash，区别是可以加一些注释
git stash list	查看存储stash内容
git stash apply stash@{2}	如果不指定一个储藏，Git认为指定的是最近的储藏；该命令不会将内容从堆栈中删除
git stash pop	来应用储藏然后立即从栈上扔掉它
git stash drop “名称”	加上将要移除的储藏的名字来移除它
git stash clear	清除堆栈中的所有内容
git stash show	查看堆栈中最新保存的stash和当前目录的差异

git stash应用场景

当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。
由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。

Git后悔药

工作区

如何撤回自己在工作目录中的修改：git checkout --fileName

暂存区

如何撤回自己在暂存区：git reset HEAD filename

版本库

如何重新提交自己的备注： git commit -amend

如何重新提交自己的代码：出现一红一绿时，需要先git add 再git commit

GitLog

git reflog：主要是HEAD有变化，那么git reflog就会记录下来

Reset三部曲（commithash）

移动HEAD

Reset做的第一件事就是移动HEAD的指向。

假设我们再次修改了file.txt 文件并第三次提交它，现在的历史看起来是这样：

git reset --soft HEAD~

reset 加参数（--soft）：--soft则会保留工作目录的内容，并把因为保留工作目录内容所带来的新的文件差异放进暂存区。

这与改变HEAD自身不同(checkout 所做的)；reset移动HEAD指向的分支。

只动HEAD（带着分支一起移动），暂存区（Index）不会更新。

更新暂存区（索引）

注意 git reset HEAD~等同于git reset --mixed HEAD~

reset 不加参数(mixed)：保留工作目录，并清空暂存区

动了HEAD（带着分支一起移动）

动了暂存区（Index）

更新工作目录

reset 加参数（--hard）：--hard 会清空工作目录和暂存区的改动

动了HEAD（带着分支一起移动）

动了暂存区（Index）

动了工作目录（Working Directory）

Reset三种模式区别和使用场景

区别：

--hard：重置位置的同时，直接将working Tree工作目录、index暂存区及repository远程仓库都重置成目标Reset节点的内容，所以效果看起来等同于清空暂存区和工作区。
--soft：重置位置的同时，保留working Tree工作目录和index暂存区的内容，只让repository远程仓库中的内容和reset目标节点保持一致，因此效果看起来就是工作目录的内容不变，暂存区原有的内容也不变，只是原节点和Reset节点之间的所有差异都会放到暂存区中。
--mixed（默认）：重置位置的同时，只保留Working Tree工作目录的内容，但会将Index暂存区和Repository中的内容更改和reset目标节点一致，因此原节点和Reset节点之间的【差异变更集】会放入Working Tree工作目录中。所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。

使用场景：

--hard：（1）要放弃目前本地的所有改变时，即去掉所有add到暂存区的文件和工作区的文件，可以执行 git reset -hard HEAD 来强制恢复git管理的文件夹的內容及状态；（2）真的想抛弃目标节点后的所有commit（可能觉得目标节点到原节点之间的commit提交都是错了，之前所有的commit有问题）。
--soft：原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)，所以假如我们之前工作目录没有改过任何文件，也没add到暂存区，那么使用reset --soft后，我们可以直接执行 git commit 将 index暂存区中的内容提交至 repository 中。为什么要这样呢？这样做的使用场景是：假如我们想合并「当前节点」与「reset目标节点」之间不具太大意义的 commit 记录(可能是阶段性地频繁提交,就是开发一个功能的时候，改或者增加一个文件的时候就commit，这样做导致一个完整的功能可能会好多个commit点，这时假如你需要把这些commit整合成一个commit的时候)，可以考虑使用reset --soft来让 commit 演进线图较为清晰。总而言之，可以使用--soft合并commit节点。
--mixed（默认）：（1）使用完reset --mixed后，我们可以直接执行git add将这些改变过的文件内容加入index暂存区中，在执行git commit将index暂存区中的内容提交到Repository中，这样一样可以达到合并commit节点的效果，（与上面--soft合并commit节点差不多，只是多了git add添加到暂存区的操作）；（2）移除所有index暂存区中准备要提交的文件(Staged files)，我们可以执行 git reset HEAD 来 Unstage 所有已列入 Index暂存区 的待提交的文件。(有时候发现add错文件到暂存区，就可以使用命令)。(3)commit提交某些错误代码，或者没有必要的文件也被commit上去，不想再修改错误再commit（因为会留下一个错误commit点），可以回退到正确的commit点上，然后所有原节点和reset节点之间差异会返回工作目录，假如有个没必要的文件的话就可以直接删除了，再commit上去就OK了。

Reset注意事项：

必须注意，--hard标记是reset命令唯一的危险用法，它也是Git会真正地销毁数据的仅有的几个操作之一。其他任何形式的reset调用都可以轻松撤销，但是--hard选项不能，因为它强制覆盖了工作目录中的文件。再这种特殊情况下，我们的Git数据库中的一个提交内还留有该文件的V3版本，我们可以通过reflog来找回它。若该文件还未提交，Git仍会覆盖它从而导致无法恢复。

Git checkout和git reset --hard区别

checkout	reset --hard
checkout只动HEAD	reset --hard动HEAD而且带着分支一起移动
checkout对工作目录是安全的	reset --hard是强制覆盖工作目录

Git tag标签

Git可以给历史中的某一个提交打上标签，以示重要。比较有代表性的是人们会使用这个功能来标记发布节点（V1.0等等）

tag的简单使用

1.创建tag：

创建tag是基于本地分支的commit，而且与分支的推送是两回事，就是说分支已经推送到远程了，但是你的tag并没有，如果把tag推送到远程分支上，需要另外执行tag的推送命令。

命令	说明
git tag <tagName>	创建本地tag
git push origin <tagName>	推送到远程仓库
git push origin --tags	若存在很多未推送的本地标签，你想一次全部推送的话，使用该命令

以上是基于本地当前分支的最后的一个commit 创建的 tag ，但是如果不想以最后一个，只想以某一个特定的提交为tag ，也是可以的，只要你知道commit 的id。

git log --pretty=oneline //查看当前分支的提交历史里面包含 commit id

git tag -a <tagName> <commitId>

2.查看标签

命令	说明
git show <tagName>	查看本地某个tag的详细信息
git tag 或者 git tag -l	查看本地所有tag
git ls-remote --tags origin	查看远程所有tag

3.删除标签

命令	说明
git tag -d <tagName>	本地tag的删除
git push origin :refs/tags/<tagName>	远程tag的删除

4.检出标签

git checkout -b <branchName> <tagName>

因为 tag 本身指向的就是一个 commit，所以和根据commit id 检出分支是一个道理。

5.其他命令

命令	说明
git tag -a <tagname> -m "XXXX"	可以指定标签信息
git tag -a v0.1.0 -m "release 0.1.0 version"	创建附注标签
git checkout [tagname]	切换标签

以上内容，如果哪里有问题，及时私信或者评论说明，谢谢！！

您的点赞动力，就是作者出更多好的作品的动力！！！！

作者：筱白爱学习！！！

码农公寓

Git存储

git stash命令