场景
线上在使用的用户突然发现系统或者 app 运行不正常了,比如说突然网站的商品显示不出来。用户通常会打电话给客服投诉,客服找到运营后,运营直接在缺陷跟踪系统上提工单(比如在 jira 上提一个 task),里面会写上详细的一些 bug 信息,包括什么时间,谁反馈,截图,如何复现等。随后这个 bug 会被指派给一个负责的 RD 和一个对应的 QA。
RD 会去看一下那个工单,尝试在本地先复现出来,然后去修复那个 bug,再部署到预发布环境,让 QA 快速的回归一下,验证一下那个 bug 是否修复了。好了以后,就直接上线。
但是修复线上 bug,需要从 master 分支拉一个 bugfix 分支出来的,而此时可能 RD 手头正在开发 feature 分支,代码才写到一半,没弄完呢。如果 RD 此时要切换分支,在 git 中是会让你先 commit 当前 feature 分支的代码,然后再切换到 bugfix 分支的。如果把写到一半儿的代码就贸然提交一个 commit 的话,你的 commit将包含了一半的代码,弄一个不伦不类的 commit 记录出来,可能违反公司规范!
这种情况如何处理呢?
stash 保护现场
使用 git 的 stash 功能,可以将 feature 分支开发的代码全部暂存起来,然后将工作区的代码恢复到干净的状态,好像什么都没修改过一样。
比如,张三正在 feature/002 分支开发时,突然间要求去修复一个 bug。

此时可以先将当前工作区的代码保存起来

stash之后,工作区的代码状态是:

会发现刚才的代码没了,查看 stash 列表会发现刚才的对面被暂存到 stash 了。而此时 git 的 status 也是working tree。

接着,张三就可以基于远程的 bug 分支拉取并创建一个 bug 分支到本地修复 bug
git fetch origin
git checkout -b bugfix/002 origin/bugfix/002
bug 修复完后,push 到远程 bug 的分支,然后发起 PR,依次申请合并到 master 分支和 develop 分支。合并后删除远程和本地 bug 分支,再切换到本地的 feature 分支进行后续的开发。
stash 恢复现场
方式一
git stash list
git stash apply
执行第一条命令,先查看 stash 列表,再执行第二条命令,将最近一次 stash 给恢复回来

恢复到现场后继续开发,完成该分支的功能,集成到 develop 分支,然后基于 develop 分支拉一个 release 分支,测试完成后将 release 分支合到 master 分支,打新 tag 再上线。
方式二
git stash apply 序号
直接指定序号,恢复到指定时刻的工作区状态。

方式三(暂存区)
如果执行 git stash 的时候,有放入了暂存区的内容,在恢复的时候需要使用如下命令恢复现场
git stash apply --index
该命令会同时将工作区和暂存区中的内容进行恢复
删除 stash
git stash drop 序号
比如删除处于暂存区的 stash@{1}

注意事项
默认情况下,它只会将工作区中的修改的文件进行 stash,也就是指 stash 一些 modified 状态的文件。如果要将 untracked 和暂存区中的文件都进行 stash。要使用如下命令:
git stash --index --include-untracked
该命令将暂存区中 tracked 和 untracked 的内容全部进行 stash 暂存
2560



被折叠的 条评论
为什么被折叠?



