为什么我们需要它
不得不说, 在知道这个命令的时, 以及之后的使用中, 我都超级热爱这个命令, 因为它真的太好用了.
给大家说一下我使用这个命令的场景:
此时我在 feature_666 分支, 非常聚精会神加持高专注地实现一个功能 666 模块, 简直键盘如飞的编写代码~~~
然后这时, 客户反馈出一个 bug , 非常严重, 必须立马解决, 优先级为 0 !!!
于是, 我需要去到 release 分支去 checkout 新的分支去工作了, 但是 666 功能还没完成怎么办?
此时我面临着一个选择题:
A: 提交后切换, 代码保存到分支 feature_666, 却产生一个无意义的提交
B: 不提交直接切换, 然而这个选项根本没人会选.
是不是很难选, 此时, 别忘记还有 C 选项!
C: 使用 Git stash , 将当前修改 (未提交的代码) 存入缓存区, 切换分支修改 bug , 回来再通过 Git stash pop 取出来.
- Git stash // 将修改存储到暂存区, 工作区会删除这些修改
- Git checkout <bug_branch>
查看修改
如果你有丢失代码的经历, 肯定会对这个之前没接触的新命令不放心, 那么怎么确定你操作成功了呢?
Git stash show // 查看刚才暂存的修改
取出修改
现在 bug 改完了, 要重新回来开发了, 取出修改
- Git checkout <feture_branch> // 切换刚才功能开发的分支
- Git stash pop // 取出修改
修改存储到什么位置了?
当我们使用 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>
取出也有好几种方式
上面的演示中, 取出 stash 的方式都是
Git stash pop // 取出最近一次暂存并删除记录列表中对应记录
这是一个非常好用的取出方式, 一般使用的频率最高, 但并非适用所有情况.
因为 Git stash pop 是弹出栈顶的一个 stash , 也就是最后一次存储的 stash. 在存储多个 stash , 想取出非栈顶的一个的情况下, 是不适用的.
这个时候要使用:
- Git stash list // 查看暂存区的所有暂存修改
- Git stash apply stash@{
- X
- } // 取出相应的暂存
- Git stash drop stash@{
- X
- } // 将记录列表中取出的对应暂存记录删除
结语
虽然, 所有的 Git 命令都能从 Git 文档 https://git-scm.com/book/en/v2 上能查看到, 但是总是要自己亲自敲过这些命令, 这些技能才能自己掌握.
不得不说, 使用命令行真的才是使用 Git 的正确方式, 真的超爽!
来源: https://www.cnblogs.com/mzy520/p/11282751.html