TimothyQiu's Blog

keep it simple stupid

被遗忘的 Git Stash

分类:技术

在介绍 Git 的时候,大多数文章都会提到它在 Working Copy 和 Repository 之间新增的 Staging Area,它使得你可以只提交 Working Copy 中的一小部分。作为一个半路出家的 Git 山寨用户,我之前知道的也就只是这三个地方了,不过这两天发现了第四个区域:Stashing Area。

假设你刚把代码改得乱七八糟,忽然想要从修改前的某个版本里做一个小改动,马上出一个紧急修正版。此时理论上,你只需先提交当前所有改动,然后就可以马上切换到以前的版本/分支开始工作了。但是作为「每次一提交都要能够通过编译」原则的忠实粉丝,这种思路所可能产生的垃圾提交是完全无法忍受的。

一种比较山寨的做法就是,手动把已修改的文件复制出去,然后 git checkout 回修改前的版本,最后切换版本/分支开始工作。做完以后再切换回来、把之前复制出去的文件复制回来。

Stashing Area 直接翻译过来是储藏间,是 Git 中用来暂存已作出的修改的地方,可以避免这种手动做法的繁琐。

  1. git stash save 将当前 Working Copy 中的修改保存为 Stash 中的一条新的记录,Working Copy 则变成了修改前的样子。
  2. 切换到别的版本/分支干活。
  3. 切换回原先的版本/分支。
  4. git stash pop 将 Stash 中最新的记录取出,并应用到 Working Copy 上。(从名字上可以看出,Stash 是一个栈式结构。)

Stash 的另一个方便之处是 git stash branch,它可以直接从 Stash 上创建一个分支。比如在你刚把代码改得乱七八糟,忽然想起来自己忘了新建分支的时候很有用。

相关信息

Git

已有 2 条评论 »

  1. 没那么高要求, 每次 push 能编译并且通过测试就行了 :D
    倒是 git bisect 是个大神器.

    1. 以前不知道从哪儿看来的规则,觉得挺有道理的,就一直默默遵守了下来~比如若干年后回首往事的时候 checkout 某一次 commit 结果发现前后若干次 commit 都不能编译,只好通过 log 之类的慢慢判断或者二分/撞大运这样的比较浪费时间。

      查哪些 commit 属于同一 push 看起来似乎很麻烦的样子……当然如果约定 fix 分支随便 commit,而 master/dev 之类的主要分支不准 fastforward 而且只能 merge,似乎也是个不错的办法。

      git bisect 之前也木有听说过,囧,俺回去好好看看 :)

添加新评论 »