当我们开发一个新功能时会先从master拉出一个新分支dev，然后在这个dev分支下吭哧吭哧的开始写代码开发新功能，比如如下代码，就是我们在dev分支下开发的新功能代码，给Student类新加一个get_name功能。
class Student:
def __init__(self, name, gender, tel):
self.name = name
self.gender = gender
self.tel = tel
def __str__(self):
return f'姓名:{self.name}, 性别:{self.gender}, 联系方式:{self.tel}'
def __repr__(self):
return f'姓名:{self.name}, 性别:{self.gender}, 联系方式:{self.tel}'
def get_name():
return self.name
就在此时，线上版本master出现了bug，我们应该放下手头上新功能的开发工作先将master上的bug修复，这个时候dev分支下的改动怎么处理？
向dev分支提交新功能的代码，然后再切换到master下
直接切换到master分支下
用第一种方案时，首先我们新功能的代码还没开发完成，其次新功能这里还有一些bug没解决，就这样把有问题的代码提交到dev分支中。虽然可以解决目前我们的处境，但不是很妥；但是第二种方案直接切换，明显更不妥，新开发的代码都没了。怎么办？好像陷入了困境……
别急，Git提供了一个git stash命令恰好可以完美解决该问题，其作用就是将当前未提交的修改（即工作区的修改和暂存区的修改）先暂时存储起来，这样工作区干净了后，就可以切换到master分支下拉一个fix分支。在完成线上bug的修复工作后，重新切换到dev分支下通过git stash pop命令将之前储存的修改取出来，继续进行新功能的开发工作。
可以看到此时我们的工作区已经干净了，dev分支中被修改的文件也已经恢复到了版本库中的版本，说明dev分支修改已经被储藏成功了。这个时候我们就可以放心的切换到master分支下去修复我们线上版本的bug了。线上bug修复完成后，我们就可以继续开始之前的新功能的开发了。
修改完后切回dev分支下：
git checkout dev
然后，取出之前储藏的修改
git stash pop
从执行结果可以看出，我们之前开发到一半的新功能又回来啦，这个时候，我们就可以继续开发新功能了。
从上面的介绍，让我们对git stash命令有了一个基本的使用认知。其实，该命令可以将当前工作区的修改储藏来实现清空工作区。但是我们做了两次储藏（即，修改-储藏-再修改-再储藏）会发生什么呢？
执行下述命令来查看我们两次储藏后的结果
# 查看储藏记录列表
git stash list
stash@{index}: WIP on [分支名]: [最近一次的commitID] [最近一次的提交信息]
从上图结果中，我们发现两次储藏记录的标识信息完全一致，只有其前面的index有别，这让我们很难确定我们所需取出的文件修改是储藏在哪一个中。在git默认按如下规则标识储藏记录（WIP意为work in progess，index用于后面取出所对应储藏的修改），由于我们在dev分支下的两次修改中均未发生提交，所以其最近一次的提交ID是一致的。
可以通过下述命令来标记此次储藏，以便后期查看
git stash save 'stashMessage'
如下所示，进行两次修改-储藏操作，并进行自定义标识
然后再执行git stash list查看储藏列表
之前提到的可以通过git stash pop取出最近一次储藏的修改到工作区，而通过查看储藏列表的index的可以取出指定储藏中的修改到工作区
# 取出指定index的储藏的修改到工作区中
git stash apply stash@{index}
# 将指定index的储藏从储藏记录列表中删除
git stash drop stash@{index}
apply从储藏区取出来并不删除记录;
drop从储藏区取出来并把记录删除;
pop从储藏区最近一条取出来并把记录删除。
基于Nginx+Supervisord+uWSGI+Django1.11.1+Python3.6.5构建
