stash
它的意思就是，把当前你已经修改了的文件暂存到本地，把你的分支恢复到未修改状态。你可以无限存储，存储的顺序是倒序的，最后的提交排序在最顶端，通过list 来查看存储的列表。
stash相关命令
存储当前修改：
git stash save "message"
或者
git stash "message"
查看存储列表：
git stash list
恢复存储的修改：
git stash apply
恢复指定的存储修改：
git stash apply stash@{
l} #l 是指当前存储列表中的顺序 0,1,2,3...
清空存储列表：
git stash clear
移除指定的存储修改：
git stash drop stash@{
l} # l 是指当前存储列表中的顺序 0,1,2,3...
rebase的基本操作
开发任务分叉到两个不同分支，又各自提交了更新。
整合分支最容易的方法是 merge 命令。 它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交）。
其实，还有一种方法：你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。 在 Git 中，这种操作就叫做 变基。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。
它的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master）的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。（译注：写明了 commit id，以便理解，下同）
此时，C4’ 指向的快照就和上面使用 merge 命令的例子中 C5 指向的快照一模一样了。 这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。
rebase 和 merge
无论是通过rebase，还是通过merge合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。
rebase是将一系列提交按照原有次序依次应用到另一分支上
merge是把最终结果合在一起。
rebase相关命令
合并分支内容：
git rebase [branch]
解决冲突后继续合并：
在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:
git rebase --continue
终止合并（还原到原有状态）：在任何时候，你可以用–abort参数来终止rebase的行动
git rebase --abort
stash，rebase的区别
第一、原理不一样
stash操作，只是把修改的内容保存起来，然后还需要执行merge操作，把master的最新提交合并到branch分支中，然后执行 stash apply，把暂存的修改内容恢复，这样就把commit4指向了最新的内容修改了。
rebase操作，是在branch分支中已经把修改内容提交到本地分支了，这个时候执行rebase操作，会先把修改的内容放入patch中，然后还原到未修改的状态，然后合并master的最新修改到branch中，然后再把patch中的内容恢复，同样的也是把commit4指向了最新的内容修改了。
第二、时机不一样
stash操作，有修改的内容，还没有提交到本地分支，也没有提交到远程分支
rebase操作，有修改的内容，已经提交到本地分支，没有提交到远程分支
第三、步骤不一样
stash操作，需要执行 stash + merge + apply
rebase操作，需要执行 commit+ rebase
参考：https://www.jianshu.com/p/3dc4677a3b08