《git 入门教程之紧急修复.docx》由会员分享，可在线阅读，更多相关《git 入门教程之紧急修复.docx（8页珍藏版）》请在金锄头文库上搜索。
1、git 入门教程之紧急修复和往常一样,每个人团队开发者都在自己的本地分支上进行日常工作,相互独立又相互联系,一直以来相安无事,可是某天下午,上级领导突然急冲冲的打电话告诉你线上出bug了,需要你紧急修复,下班之前必须解决!我们天生就是创造 bug 的特殊群体,每天都在和各种各样的 bug 打交道,早已经习惯了这样的工作节奏,再也没有当初刚刚遇到紧急问题的手足无措,先喝杯茶,冷静一下,然后汇报领导说:放心吧!保证30min 内解决问题!背景学习了分支操作的相关知识,团队内部就基本的开发流程达成一致:假设线上是主干 master 分支,开发是 dev 分支,团队成员是自定义 custom 分支,平
2、时开发时在大家在各自 custom 分支上工作,完成分配任务后再合并到开发 dev 分支,等到开发分支功能稳定后,由项目领导负责合并到主干分支 master .上述流程只是开发流程的简化版,实际情况更加复杂,后续再介绍 gitflow 工作流相关知识.由于是线上出现 bug,理所当然是基于 master 分支检出临时分支,修复分支代号为 issue-110,然后定位 bug 并提交,最后再合并到 master 分支,如此一来成功修复 bug,完成既定任务,心安理得准备下班回家!如果真的向上述步骤那样操作,显然还不够冷静,刚才那一杯茶算是白喝了!因为这样操作可能会丢失现场数据,那很多工作岂不是白
3、做了,下面简单演示一下:错误示例(一). 事发前正在自定义的 snow 分支上愉快编码中# 线上分支 master,开发分支 dev,自定义分支 snow,当前正处于自定义分支$ git branch dev master* snow# 接到领导电话前正在自定义 snow 分支上进行愉快编码中.$ echo Happy coding test.txt$ git add test.txt$ git commit -m Happy coding(二). 事发时直接检出主分 master 分支,并紧急修复 bug .(2.1) 基于 master 分支检出 issue-110 分支,并修复提交.#
4、注意: 事发时正在思考人生,此时更改尚未添加到暂存区!$ echo who am i test.txt# 当前情况下,默认不允许直接切换到其他分支,因为工作区更改会被重写,这里为了演示错误示例,强制切换!$ git checkout -f master # 基于主干 master 分支检出修复 issue-110分支$ git checkout -b issue-110Switched to a new branch issue-110# 定位线上 bug并修复,假设将 fast forward 更改为 fast forward not recommend,瞬间修复 bug有没有!$ cat
5、test.txtadd test.txtsee https:/snowdreams1006.github.io/git/usage/remote-repository.htmllearn git branchsee https:/snowdreams1006.github.io/git/usage/branch-overview.htmlgit commit c1git commit c2 and c3git checkout -b devfast forward$ vim test.txt$ cat test.txtadd test.txtsee https:/snowdreams1006.
6、github.io/git/usage/remote-repository.htmllearn git branchsee https:/snowdreams1006.github.io/git/usage/branch-overview.htmlgit commit c1git commit c2 and c3git checkout -b devfast forward not recommend# 修复 bug 后,提交更改并备注已修复$ git add test.txt$ git commit -m fix bug about issue-110issue-110 e60c8ad fi
7、x bug about issue-110 1 file changed, 1 insertion(+), 1 deletion(-)sunpodeMacBook-Pro:git-demo sunpo$ git statusOn branch issue-110nothing to commit, working tree clean$ (2.1) 切换到主干 master 分支,并合并修复 issue-110 分支# 切换回 master 分支,合并修复 issue-110 分支$ git checkout masterSwitched to branch masterYour branch
8、 is up to date with origin/master.$ git merge issue-110Updating 3fe94c0.e60c8adFast-forward test.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)# 验证 bug 已修复: 更改为 fast forward not recommend$ cat test.txtadd test.txtsee https:/snowdreams1006.github.io/git/usage/remote-repository.htmllearn git
9、 branchsee https:/snowdreams1006.github.io/git/usage/branch-overview.htmlgit commit c1git commit c2 and c3git checkout -b devfast forward not recommend$ (三). 事发后切换回自定义 snow 分支,打算下班回家.# 切换回 snow 分支,发现丢失了事发前的未保存更改:who am i$ git checkout snowSwitched to branch snow$ cat test.txtadd test.txtsee https:/s
10、nowdreams1006.github.io/git/usage/remote-repository.htmllearn git branchsee https:/snowdreams1006.github.io/git/usage/branch-overview.htmlgit commit c1git commit c2 and c3git checkout -b devfast forwardHappy coding$ 现在还打算下班吗?你所做的更改因为没有提交或者不能提交造成全部丢失!结果因为手头工作进行到一半无法提交或者忘记提交等原因,为了临时修复紧急 bug 而直接切换到目标分支
11、再回来时发现更改全部丢失,相当于那部分工作白忙活了!正确示例经过上述错误示例的惨痛教训后,再也不敢轻易切换分支了,原因在于工作区更改并没有被提交,或者说不能提交,如果能够有一种机制来保护案发现场,这样我们就能放心切换到其他分支工作,回来时一切如初,那该多好?幸运的是,git 确实提供这么一种机制,git stash 命令临时存储工作区,类似草稿箱作用.(一). 恢复工作区丢失更改,并使用 git stash 命令保存现场.# 修复工作区丢失更改: 同样未添加到暂存区$ echo learn git stash test.txt$ cat test.txtadd test.txtsee http
12、s:/snowdreams1006.github.io/git/usage/remote-repository.htmllearn git branchsee https:/snowdreams1006.github.io/git/usage/branch-overview.htmlgit commit c1git commit c2 and c3git checkout -b devfast forwardHappy codinglearn git stash# 保护现场: 存储到草稿箱$ git stashSaved working directory and index state WI
13、P on snow: 93227ba Happy coding(二). 切换到开发 dev 分支并合并修复 issue-110 分支.# 切换到开发 dev 分支$ git checkout devSwitched to branch devsunpodeMacBook-Pro:git-demo sunpo$ git statusOn branch devnothing to commit, working tree clean# 合并修复 issue-110 分支$ git merge issue-110Updating 3fe94c0.e60c8adFast-forward test.tx
14、t | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)sunpodeMacBook-Pro:git-demo sunpo$ git statusOn branch devnothing to commit, working tree clean$ (三). 切换回自定义 snow 分支,并恢复工作现场.# 切换回自定义 snow 分支$ git checkout snowSwitched to branch snowsunpodeMacBook-Pro:git-demo sunpo$ git statusOn branch snownoth
15、ing to commit, working tree clean$ git status 命令返回结果怎么显示工作区是干净的,好不容易才将丢失的更改找回来怎么又不见了?!逗我玩?冷静,冷静,不要慌,既然工作现场已经保存到草稿箱,那我们想要找回总要去草稿箱才能取出来吧?现在让我们看一下草稿箱有没有我们的工作现场?# 查看存储的草稿箱列表$ git stash liststash0: WIP on snow: 93227ba Happy coding$ 这里的 stash0 是草稿 id,因为草稿箱允许保存多条草稿!现在放心了吧,保存的草稿安然无恙躺在未知的某个地方,现在我们想办法恢复回工作区即可! git stash apply 恢复草稿,然后 git stash drop 删除草稿 git stash pop 恢复
