git stash
在git中有时候我们工作做了一半，但是有点急事需要离开一段时间，或者现在需要切换到另一个分支下，去维护和修改一些其它的东西，但是我们现在的工作还没有完成，提交上去的话，并不是完整的，那么该怎么办呢？
git提供了保留现场和恢复现场的操作。通过git stash操作，你可以把你当前的工作进度暂存起来(我认为其实就和git add类似，放到了git的暂存区中因为git status的话，你可以看见当前分支是clean的)
$ vim LICENSE
$ git stash
Saved working directory and index state WIP on dev: 47f7c9c 修改了readme.txt
$ git status
On branch dev
nothing to commit, working tree clean你可以多次保存现场，但是现场之间并不是连贯的哦(意思是，你将当前状态保存了现场之后，你打开你一个东西，是你保存现场之前完全没有修改的样子！)，所以我暂时觉得多次保存现场没有太大的意义。但是现场的存储，你要知道的是，它是通过栈的方式存储的，即其实你保存现场和恢复现场遵循的都是，先进后出的！
上面说了保存现场是：git bash，那么恢复现场该怎么办？
别着急先说如果你的现场存了很多个，怎么查看现场列表。
通过git stash list 就可以查看你的现场列表了！
$ git stash list
stash@{0}: WIP on dev: 47f7c9c 修改了readme.txt
stash@{1}: WIP on dev: 47f7c9c 修改了readme.txt
stash@{2}: WIP on dev: 47f7c9c 修改了readme.txt后面的"修改了readme.txt"是当前节点的commit -m注释，因为我么这三个现场都是对同一个节点的现场保留
那么恢复现场该怎么办呢？
我说过现场存储的数据结构是栈，那么学过数据结构的人应该知道，栈有入栈(push)和出栈(pop)，但是还有一种查看栈顶元素(peek)但是不出栈的操作，那么对应git的现场保留也应该有这样的操作！
push：git stash 现场保留
pop：git stash pop 恢复现场，并且从现场列表中删除栈顶现场
peek：git stash apply 恢复现场，但是不从现场列表中删除现场
如果使用了git stash apply 又要删除现场的话，就要额外使用一条命令：
git stash drop(但是此条命令也只能删除栈顶的一个现场)
所以我这里不建议多个现场！
如果多个现场，你又想要恢复特定的现场呢？其实git也有提供：
通过git stash apply stash@{0}[stash的id]
bug修复连贯案例：
如果你当前发现master分支有bug，随即你在master分支上新建了一个分支issue-500，修改完了之后，你切换到master分支，通过git merge issue-500，之后master造成了修改！那么你的其它分支应该马上和master合一次(正常情况下是对dev修复bug之后，dev分支和个人分支合)
这里合并，最好就使用禁用fast forward的普通合并：
merge --no-ff -m "合并master上改好的bug" dev这里复现一次这个过程：
先在master分支上新建一个LICENSE文件，随便写点内容：
当前是在主分支(master上)
vim LICENSE：
hello，write by mzy.
...
wq然后为master创建一个dev分支：
git branch dev然后在master上创建并切换到一个issue-404分支：
git checkout -b issue-404修改LICENSE
vim LICENSE
hello, write by mzy
在issue中的修改
...
wq然后：
git add LICENSE
git commit -m "issue-404中修改了LICENSE"切换回master分支：
合并issue分支：
$ git merge issue-404
Already up to date.
合并成功！
（注意：如果是没有冲突的合并，git自动就提交到了版本库，但是如果有冲突，记得先手动解决冲突之后，记得要git add、
git commit 到版本库哦）
然后我们可以删除这个修改问题的分支issue-404了：
$ git branch -d issue-404
Deleted branch issue-404(was 6488267).（以上删除issue-404分支，因为合并了，所有直接删除成功，如果没有合并的话，要强制删除记得使用-D哦）
切换到我们的dev分支查看LICENSE文件：
发现master的改变，并没有被推送给子分支dev，所以需要在当前的dev分支上合并一下master中的修改！
git merge --no-ff -m "合并master上改好的bug" mastercat LICENSE发现之前的修改拿到了！
(这里有个概念：upstream和downstream，up我理解是远端的，较稳定的一端，比如master和dev比，master是主分支稳定的就算是up，相对于master来说它的down就是dev，因为master最后需要合并dev中的内容[拿到dev中的内容])