为什么我们需要它
不得不说, 在知道这个命令的时, 以及之后的使用中, 我都超级热爱这个命令, 因为它真的太好用了.
给大家说一下我使用这个命令的场景:
此时我在 feature_666 分支, 非常聚精会神加持高专注地实现一个功能 666 模块, 简直键盘如飞的编写代码~~~
然后这时, 客户反馈出一个 bug , 非常严重, 必须立马解决, 优先级为 0 !!!
于是, 我需要去到 release 分支去 checkout 新的分支去工作了, 但是 666 功能还没完成怎么办?
此时我面临着一个选择题:
A: 提交后切换, 代码保存到分支 feature_666, 却产生一个无意义的提交
B: 不提交直接切换, 然而这个选项根本没人会选.
是不是很难选, 此时, 别忘记还有 C 选项!
C: 使用 Git stash , 将当前修改 (未提交的代码) 存入缓存区, 切换分支修改 bug , 回来再通过 Git stash pop 取出来.
1. 暂存操作
- # 查看当前状态
- Git status
- # 如果有修改, 添加修改文件
- Git add .
- # 暂存操作
- Git stash save '本次暂存的标识名字'
2. 查看当前暂存的记录
- # 查看记录
- Git stash list
修改存储到什么位置了?
当我们使用 Git init 给项目添加版本控制的时候, 会在项目路径下生成一个 .Git 隐藏文件夹..Git 中存储着版本管理的所有信息.
.Git/refs/stash 中, 存储的是最后一个 stash 对应的节点指针
同样, 在 .Git/log/refs/stash 中可以看到我们全部的 stash 记录信息
存储多个 stash 的情况
ok , 我们来尝试一下修改文件, 然后再次使用 Git stash , 此时我们有个两个 暂存修改, 那么怎么查看呢?
Git stash list // 查看暂存区的所有暂存修改记录
如果在未提交的情况下, 执行 Git stash 两次, 无法准确分辨两个 stash 具体修改的是哪些内容, 这样用, 显的伟大的 Git 一点都不智能, 怎么可以!.
所以, 在这种情况下, 给 stash 存储的修改起个名字, 显然非常重要, 方式如下:
Git stash save <message>
3. 恢复暂存的工作
- 'pop 命令恢复, 恢复后, 暂存区域会删除当前的记录'
- # 恢复指定的暂存工作, 暂存记录保存在 list 内, 需要通过 list 索引 index 取出恢复
- Git stash pop stash@{
- index
- }
- 'apply 命令恢复, 恢复后, 暂存区域会保留当前的记录'
- # 恢复指定的暂存工作, 暂存记录保存在 list 内, 需要通过 list 索引 index 取出恢复
- Git stash apply stash@{
- index
- }
4. 删除暂存
- # 删除某个暂存, 暂存记录保存在 list 内, 需要通过 list 索引 index 取出恢复
- Git stash drop stash@{
- index
- }
- # 删除全部暂存
- Git stash clear
来源: https://www.jb51.net/article/191555.htm