被遗忘的 Git Stash
分类：技术
在介绍 Git 的时候，大多数文章都会提到它在 Working Copy 和 Repository 之间新增的 Staging Area，它使得你可以只提交 Working Copy 中的一小部分。作为一个半路出家的 Git 山寨用户，我之前知道的也就只是这三个地方了，不过这两天发现了第四个区域：Stashing Area。
假设你刚把代码改得乱七八糟，忽然想要从修改前的某个版本里做一个小改动，马上出一个紧急修正版。此时理论上，你只需先提交当前所有改动，然后就可以马上切换到以前的版本/分支开始工作了。但是作为「每次一提交都要能够通过编译」原则的忠实粉丝，这种思路所可能产生的垃圾提交是完全无法忍受的。
一种比较山寨的做法就是，手动把已修改的文件复制出去，然后 git checkout 回修改前的版本，最后切换版本/分支开始工作。做完以后再切换回来、把之前复制出去的文件复制回来。
Stashing Area 直接翻译过来是储藏间，是 Git 中用来暂存已作出的修改的地方，可以避免这种手动做法的繁琐。
git stash save将当前 Working Copy 中的修改保存为 Stash 中的一条新的记录，Working Copy 则变成了修改前的样子。- 切换到别的版本/分支干活。
- 切换回原先的版本/分支。
git stash pop将 Stash 中最新的记录取出，并应用到 Working Copy 上。（从名字上可以看出，Stash 是一个栈式结构。）
Stash 的另一个方便之处是 git stash branch，它可以直接从 Stash 上创建一个分支。比如在你刚把代码改得乱七八糟，忽然想起来自己忘了新建分支的时候很有用。
没那么高要求, 每次 push 能编译并且通过测试就行了 :D
倒是 git bisect 是个大神器.
以前不知道从哪儿看来的规则，觉得挺有道理的，就一直默默遵守了下来～比如若干年后回首往事的时候 checkout 某一次 commit 结果发现前后若干次 commit 都不能编译，只好通过 log 之类的慢慢判断或者二分/撞大运这样的比较浪费时间。
查哪些 commit 属于同一 push 看起来似乎很麻烦的样子……当然如果约定 fix 分支随便 commit，而 master/dev 之类的主要分支不准 fastforward 而且只能 merge，似乎也是个不错的办法。
git bisect 之前也木有听说过，囧，俺回去好好看看 :)