1git-stash(1) 2============ 3 4NAME 5---- 6git-stash - Stash the changes in a dirty working directory away 7 8SYNOPSIS 9-------- 10[verse] 11'git stash' list [<options>] 12'git stash' show [<stash>] 13'git stash' drop [-q|--quiet] [<stash>] 14'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>] 15'git stash' branch <branchname> [<stash>] 16'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] 17 [-u|--include-untracked] [-a|--all] [<message>]] 18'git stash' push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] 19 [-u|--include-untracked] [-a|--all] [-m|--message <message>]] 20'git stash' clear 21'git stash' create [<message>] 22'git stash' store [-m|--message <message>] [-q|--quiet] <commit> 23 24DESCRIPTION 25----------- 26 27Use `git stash` when you want to record the current state of the 28working directory and the index, but want to go back to a clean 29working directory. The command saves your local modifications away 30and reverts the working directory to match the `HEAD` commit. 31 32The modifications stashed away by this command can be listed with 33`git stash list`, inspected with `git stash show`, and restored 34(potentially on top of a different commit) with `git stash apply`. 35Calling `git stash` without any arguments is equivalent to `git stash save`. 36A stash is by default listed as "WIP on 'branchname' ...", but 37you can give a more descriptive message on the command line when 38you create one. 39 40The latest stash you created is stored in `refs/stash`; older 41stashes are found in the reflog of this reference and can be named using 42the usual reflog syntax (e.g. `stash@{0}` is the most recently 43created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}` 44is also possible). Stashes may also be referenced by specifying just the 45stash index (e.g. the integer `n` is equivalent to `stash@{n}`). 46 47OPTIONS 48------- 49 50save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]:: 51push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>]:: 52 53 Save your local modifications to a new 'stash' and roll them 54 back to HEAD (in the working tree and in the index). 55 The <message> part is optional and gives 56 the description along with the stashed state. For quickly making 57 a snapshot, you can omit _both_ "save" and <message>, but giving 58 only <message> does not trigger this action to prevent a misspelled 59 subcommand from making an unwanted stash. 60+ 61If the `--keep-index` option is used, all changes already added to the 62index are left intact. 63+ 64If the `--include-untracked` option is used, all untracked files are also 65stashed and then cleaned up with `git clean`, leaving the working directory 66in a very clean state. If the `--all` option is used instead then the 67ignored files are stashed and cleaned in addition to the untracked files. 68+ 69With `--patch`, you can interactively select hunks from the diff 70between HEAD and the working tree to be stashed. The stash entry is 71constructed such that its index state is the same as the index state 72of your repository, and its worktree contains only the changes you 73selected interactively. The selected changes are then rolled back 74from your worktree. See the ``Interactive Mode'' section of 75linkgit:git-add[1] to learn how to operate the `--patch` mode. 76+ 77The `--patch` option implies `--keep-index`. You can use 78`--no-keep-index` to override this. 79 80list [<options>]:: 81 82 List the stashes that you currently have. Each 'stash' is listed 83 with its name (e.g. `stash@{0}` is the latest stash, `stash@{1}` is 84 the one before, etc.), the name of the branch that was current when the 85 stash was made, and a short description of the commit the stash was 86 based on. 87+ 88---------------------------------------------------------------- 89stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation 90stash@{1}: On master: 9cc0589... Add git-stash 91---------------------------------------------------------------- 92+ 93The command takes options applicable to the 'git log' 94command to control what is shown and how. See linkgit:git-log[1]. 95 96show [<stash>]:: 97 98 Show the changes recorded in the stash as a diff between the 99 stashed state and its original parent. When no `<stash>` is given, 100 shows the latest one. By default, the command shows the diffstat, but 101 it will accept any format known to 'git diff' (e.g., `git stash show 102 -p stash@{1}` to view the second most recent stash in patch form). 103 You can use stash.showStat and/or stash.showPatch config variables 104 to change the default behavior. 105 106pop [--index] [-q|--quiet] [<stash>]:: 107 108 Remove a single stashed state from the stash list and apply it 109 on top of the current working tree state, i.e., do the inverse 110 operation of `git stash save`. The working directory must 111 match the index. 112+ 113Applying the state can fail with conflicts; in this case, it is not 114removed from the stash list. You need to resolve the conflicts by hand 115and call `git stash drop` manually afterwards. 116+ 117If the `--index` option is used, then tries to reinstate not only the working 118tree's changes, but also the index's ones. However, this can fail, when you 119have conflicts (which are stored in the index, where you therefore can no 120longer apply the changes as they were originally). 121+ 122When no `<stash>` is given, `stash@{0}` is assumed, otherwise `<stash>` must 123be a reference of the form `stash@{<revision>}`. 124 125apply [--index] [-q|--quiet] [<stash>]:: 126 127 Like `pop`, but do not remove the state from the stash list. Unlike `pop`, 128 `<stash>` may be any commit that looks like a commit created by 129 `stash save` or `stash create`. 130 131branch <branchname> [<stash>]:: 132 133 Creates and checks out a new branch named `<branchname>` starting from 134 the commit at which the `<stash>` was originally created, applies the 135 changes recorded in `<stash>` to the new working tree and index. 136 If that succeeds, and `<stash>` is a reference of the form 137 `stash@{<revision>}`, it then drops the `<stash>`. When no `<stash>` 138 is given, applies the latest one. 139+ 140This is useful if the branch on which you ran `git stash save` has 141changed enough that `git stash apply` fails due to conflicts. Since 142the stash is applied on top of the commit that was HEAD at the time 143`git stash` was run, it restores the originally stashed state with 144no conflicts. 145 146clear:: 147 Remove all the stashed states. Note that those states will then 148 be subject to pruning, and may be impossible to recover (see 149 'Examples' below for a possible strategy). 150 151drop [-q|--quiet] [<stash>]:: 152 153 Remove a single stashed state from the stash list. When no `<stash>` 154 is given, it removes the latest one. i.e. `stash@{0}`, otherwise 155 `<stash>` must be a valid stash log reference of the form 156 `stash@{<revision>}`. 157 158create:: 159 160 Create a stash (which is a regular commit object) and return its 161 object name, without storing it anywhere in the ref namespace. 162 This is intended to be useful for scripts. It is probably not 163 the command you want to use; see "save" above. 164 165store:: 166 167 Store a given stash created via 'git stash create' (which is a 168 dangling merge commit) in the stash ref, updating the stash 169 reflog. This is intended to be useful for scripts. It is 170 probably not the command you want to use; see "save" above. 171 172DISCUSSION 173---------- 174 175A stash is represented as a commit whose tree records the state of the 176working directory, and its first parent is the commit at `HEAD` when 177the stash was created. The tree of the second parent records the 178state of the index when the stash is made, and it is made a child of 179the `HEAD` commit. The ancestry graph looks like this: 180 181 .----W 182 / / 183 -----H----I 184 185where `H` is the `HEAD` commit, `I` is a commit that records the state 186of the index, and `W` is a commit that records the state of the working 187tree. 188 189 190EXAMPLES 191-------- 192 193Pulling into a dirty tree:: 194 195When you are in the middle of something, you learn that there are 196upstream changes that are possibly relevant to what you are 197doing. When your local changes do not conflict with the changes in 198the upstream, a simple `git pull` will let you move forward. 199+ 200However, there are cases in which your local changes do conflict with 201the upstream changes, and `git pull` refuses to overwrite your 202changes. In such a case, you can stash your changes away, 203perform a pull, and then unstash, like this: 204+ 205---------------------------------------------------------------- 206$ git pull 207 ... 208file foobar not up to date, cannot merge. 209$ git stash 210$ git pull 211$ git stash pop 212---------------------------------------------------------------- 213 214Interrupted workflow:: 215 216When you are in the middle of something, your boss comes in and 217demands that you fix something immediately. Traditionally, you would 218make a commit to a temporary branch to store your changes away, and 219return to your original branch to make the emergency fix, like this: 220+ 221---------------------------------------------------------------- 222# ... hack hack hack ... 223$ git checkout -b my_wip 224$ git commit -a -m "WIP" 225$ git checkout master 226$ edit emergency fix 227$ git commit -a -m "Fix in a hurry" 228$ git checkout my_wip 229$ git reset --soft HEAD^ 230# ... continue hacking ... 231---------------------------------------------------------------- 232+ 233You can use 'git stash' to simplify the above, like this: 234+ 235---------------------------------------------------------------- 236# ... hack hack hack ... 237$ git stash 238$ edit emergency fix 239$ git commit -a -m "Fix in a hurry" 240$ git stash pop 241# ... continue hacking ... 242---------------------------------------------------------------- 243 244Testing partial commits:: 245 246You can use `git stash save --keep-index` when you want to make two or 247more commits out of the changes in the work tree, and you want to test 248each change before committing: 249+ 250---------------------------------------------------------------- 251# ... hack hack hack ... 252$ git add --patch foo # add just first part to the index 253$ git stash save --keep-index # save all other changes to the stash 254$ edit/build/test first part 255$ git commit -m 'First part' # commit fully tested change 256$ git stash pop # prepare to work on all other changes 257# ... repeat above five steps until one commit remains ... 258$ edit/build/test remaining parts 259$ git commit foo -m 'Remaining parts' 260---------------------------------------------------------------- 261 262Recovering stashes that were cleared/dropped erroneously:: 263 264If you mistakenly drop or clear stashes, they cannot be recovered 265through the normal safety mechanisms. However, you can try the 266following incantation to get a list of stashes that are still in your 267repository, but not reachable any more: 268+ 269---------------------------------------------------------------- 270git fsck --unreachable | 271grep commit | cut -d\ -f3 | 272xargs git log --merges --no-walk --grep=WIP 273---------------------------------------------------------------- 274 275 276SEE ALSO 277-------- 278linkgit:git-checkout[1], 279linkgit:git-commit[1], 280linkgit:git-reflog[1], 281linkgit:git-reset[1] 282 283GIT 284--- 285Part of the linkgit:git[1] suite