Git 的 stash 功能，望文生义，便是为了存储代码。假定你正在分支 feature/make-bug 尽情创作，刚修正了一半的代码，你领导忽然告诉你在版别分支 v1.0.0 有个紧急 bug 要你修正。像我刚用 Git 不久的时分，下意识直接切换分支 git checkout v1.0.0，这么做的话，就会有两种后果：

  1. 分支切换失败，git 报错。
error: Your local changes to the following files would be overwritten by checkout:
        service.py
Please commit your changes or stash them before you switch branches.
Aborting
  1. 修正的文件会被带到目标分支。

这里先不追究形成这两种状况的原因。假如不运用 stash，怎么能正确切换到 v1.0.0 分支呢？有两种方式：

  1. 在 feature/make-bug 运用 commit 提交修正，然后切换到 v1.0.0 修正完 bug 后，再切回 feature/make-bug 继续开发，假如不愿意保存前次的临时 commit 记录，则履行 git reset HEAD^ 来完结
  2. 手动将修正的文件文件保存在 git 作业空间之外。

两种都不是好方法，榜首种很不灵敏，并且还为未完结的作业生成一个 commit。第二种手动复制粘贴更不是好主意。

比较于榜首种方法，git stash 能够直接将未提交的修正保存在本地，并允许你做其他的修正，履行其他的 git 操作，比如切到其他分支。当你需求的时分，能够再将 stash 存储过的修正复原。

怎么运用 git stash

关于上例，下面是当你运用 git stash 的履行步骤：

  1. 确保文件现已保存，一般 IDE 会自动保存好。
  2. 履行 git stash 存储当时修正。
  3. 切换到 v1.0.0 分支。
  4. 在 v1.0.0 分支修正 bug，并提交修正。
  5. 切换回到 feature/make-bug 分支。
  6. 履行 git stash pop 指令复原存储的修正。

原理上，Git stash 会将代码存储在工程的作业目录 .git/refs/stash 中， 并且并不会被 git push 推送到长途。

Git stash 是能帮你完好保存好稍后可能用到的代码，并且快速整理作业目录的东西。

怎么创立一个 stash

最简单的指令便是：

$ git stash
Saved working directory and index state WIP on master: 83a38ba Merge branch 'feature/make-bug'

默许状况下，git stash 存储没有 commit 的修正。不会存储未盯梢的文件（刚新建没有被 add 的文件）与 ignored 文件，一般来说是不需求这这种文件的。当你的确需求时，能够经过 git stash 的额外的参数来操控:

  • git stash -u 或者 git stash --include-untracked ：表明存储未盯梢的文件。
  • git stash -a或者git stash --all ：表明存储为盯梢与 ignored 的文件。

检查你的 stash

运用 git stash list 检查现在所有的 stash，stash 是经过仓库（后进先出）的顺序存储的。如下所示：

$ git stash list
stash@{0}: WIP on master: 83a38ba Merge branch 'feature/make-bug'

默许 Git 会为 stash 增加默许描绘，如上, 有 WIP 文本（正在作业并编写的代码）、分支名、commit 号，上一个提交的描绘。但是这供给的信息不太友爱，当有多个 stash 的时分，也难以区分，不利于回忆，这时分你能够运用指令 git stash save <description> 自定义 stash 描绘：

$ git stash save '增加用户删去 dao'
Saved working directory and index state On master: 增加用户删去 dao
$ git stash list
stash@{0}: On master: 增加用户删去 dao
stash@{1}: WIP on master: 83a38ba Merge branch 'feature/make-bug'

康复 stash 改动

你能够运用 git stash apply 与 git stash pop 康复 stash 的存储。直接履行这两个指令，会康复栈顶的的 stash（即 stash@{0} 最后保存的 stash）到作业目录。
两者不同的是，pop 会移除仓库中的 stash，而 apply 不会。

$ git stash pop
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
        modified:   dao.py
no changes added to commit (use "git add" and/or "git commit -a")

当你需求康复最近的 stash 的时分， 直接 pop 是最便利的。

当然，你能够选择你想康复哪个 stash，经过指定 stash id 来完结, 相同，pop 会移除仓库中的指定 stash，而 apply 不会。

$ git stash pop stash@{2}
# 直接写 id 也能够
$ git stash pop 2

或：

$ git stash apply stash@{1}
# 直接写 id 也能够
$ git stash pop 1

整理 stash

当你不需求 stash 的时分，经过下面的指令来整理：

  • git stash clear 整理所有的 stash
  • git stash drop <stash_id> 删去指定的 stash
$ git stash drop 0

展现 stash 中的修正

运用 git stash show <stash_id> 来展现修正：

$ git stash show 0
 dao.py | 3 +++
 1 file changed, 3 insertions(+)

传入 --patch或者-p 检查更详细的信息：

diff --git a/dao.py b/dao.py
index e69de29..8941b16 100644
--- a/dao.py
+++ b/dao.py
@@ -0,0 +1,3 @@
+def addUser(user):
+    session.insert(user)
+    session.commit()

可见是增加了一个叫 addUser 的方法。

康复 stash 到新的分支

有一个场景，当你想要康复 stash 的时分，原分支上现已做了与你 stash 抵触的修正。这时分 pop stash，就会形成代码抵触，这时分就能够运用 git stash branch <new_branch_name stash_id> 指令来处理，它会创立一个新的分支，并把 stash pop 到新分支上，你能够在新分支上处理抵触与进一步修正：

$ git stash branch feature/modify-dao 0
Switched to a new branch 'feature/modify-dao'
On branch feature/modify-dao
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
        modified:   dao.py
Dropped refs/stash@{0} (4a09ff22f71b41ea5426f16463e61eb9d491c840)

创立一个 stash 但先不存储

在有些场景下，你可能需求先创立一个 stash，但不想立刻保存到 stash 仓库中。这时分能够运用 git stash create '<desc>' 指令完结，它创立一个 stash，并回来一个引证，在稍后需求存储到仓库的时分，再运用 git stash store -m "<desc in stack>" "<引证id>" 指令。

# 为了便利先整理所有 stash
$ git stash clear
# 创立但不存储到仓库
$ git stash create 'sample stash'
db37916f9a66853ed780174d305900a757f2cc0b
$ git stash list
# 空结果

实践存储:

git stash store -m "sample stash testing.." "db37916f9a66853ed780174d305900a757f2cc0b"

总结

本文介绍了 stash 的应用场景与常用用法，希望能有所帮助。

参阅： opensource.com/article/21/…