238

If I work on branch A and suddenly need to work on branch B before being ready with a commit on branch A, I stash my changes on A, checkout B, do my work there, then checkout A and apply the stash.

If I work on A and I want to stop working for the day, should I stash my work and then apply it the next day (when I resume my work), or should I just leave things as they are—uncommitted modified files in the working directory? I don't see why I would need to use stash in this case, except if there is some security benefit.

Also, another scenario: I work both at work and at home. If I am not ready with a commit when I want to go home, can I stash my work, push it to GitHub and then pull that stash at home?

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Alexander Popov
  • 23,073
  • 19
  • 91
  • 130
  • 3
    largely dependant on your company policies, if any. How will you choose the "accepted" answer? – Daemon Painter Jul 31 '20 at 08:45
  • 1
    This question as phrased is just asking for opinions (should I use git *this* way or *that* way?) and thus should be closed or edited. – TylerH Aug 01 '20 at 18:56

10 Answers10

280

Stash is just a convenience method. Since branches are so cheap and easy to manage in git, I personally almost always prefer creating a new temporary branch than stashing, but it's a matter of taste mostly.

The one place I do like stashing is if I discover I forgot something in my last commit and have already started working on the next one in the same branch:

# Assume the latest commit was already done
# start working on the next patch, and discovered I was missing something

# stash away the current mess I made
git stash save

# some changes in the working dir

# and now add them to the last commit:
git add -u
git commit --amend

# back to work!
git stash pop
Mureinik
  • 297,002
  • 52
  • 306
  • 350
  • 3
    Does the thing you added that was missing get merged into the stash once you unstash it? (I'm still shaky on how the timeline works in git -- I assume you're overwriting history??) – Kiki Jewell Jun 04 '18 at 17:57
  • @KikiJewell popped changes are applied on the index - they are not committed. so if you `git stash pop` twice, you'll lose the distinction between those two change sets. – Mureinik Jun 04 '18 at 20:01
  • 2
    As of late October 2017, there has been extensive discussion on the Git mailing list, wherein the command git stash save is being deprecated in favour of the existing alternative `git stash push`. The main reason for this is that `git stash push` introduces the option of stashing selected _pathspecs_, something `git stash save` does not support. – Krishna Gupta Jul 06 '20 at 02:19
  • 1
    @Mureinik, what do you think about new branches vs git stash branch? – Pacerier Aug 11 '20 at 08:07
  • 2
    @Pacerier as I said in the first paragraph, I almost always prefer just creating a new branch, but it's probably more a force of habit than any sound technical reasoning. – Mureinik Aug 11 '20 at 08:21
  • I was just talking to a co-worker about stashing I said the only time I ever do it is if I'm about to commit and realize I'm on the wrong branch, and I can't switch cleanly. But I'm going to add your example as the second reason I would stash, which admittedly happens to me more often than the first. (I previously would commit my current with "wip - stuff", then make the change and another commit with "sq into a1b2c3". And if I cared, I would rebase -i right there, or just wait for later.) I also said- if the stuff is going to be stashed for more than a minute, then it's getting committed. – TTT Oct 29 '20 at 17:17
  • I don't understand https://stackoverflow.com/questions/20537223/what-is-the-intended-use-case-for-git-stash#comment88385613_20537356: will the "amendment" be there after you "pop" ? If so, couldn't that, in theory and practice, introduce a "conflict" between the "amendment" and the "stashed" stuff? And if so again, 1-2 comments on conflict resolution would be appreciated too. (am aware of conflict resolution with git merges, but that's a different situation, at least from a user perspective) – nutty about natty May 15 '23 at 19:20
  • according to a quick google, pop can encounter conflicts (too) so yes, the "amendment" would be there after pop it seems... – nutty about natty May 15 '23 at 19:54
  • @nuttyaboutnatty if you get a conflict when you pop a change, you'll get the conflicted diff on your files (similar to when you encounter a conflict while rebasing) which you'll have to resolve, but the stashed changes will remain in the stash. You could then pop then again or explicitly drop them by calling `git stash drop`. – Mureinik May 16 '23 at 10:06
99

I will break answer on three paragraphs.

Part 1:

git stash (To save your un-committed changes in a "stash". Note: this removes changes from working tree!)

git checkout some_branch (change to intended branch -- in this case some_branch)

git stash list (list stashes)

You can see:
stash@{0}: WIP on {branch_name}: {SHA-1 of last commit} {last commit of you branch}
stash@{1}: WIP on master: 085b095c6 modification for test

git stash apply (to apply stash to working tree in current branch)

git stash apply stash@{12} (if you will have many stashes you can choose what stash will apply -- in this case we apply stash 12)

git stash drop stash@{0} (to remove from stash list -- in this case stash 0)

git stash pop stash@{1} (to apply selected stash and drop it from stash list)

Part 2:
You can hide your changes with this command but it is not necessary.
You can continue on the next day without stash.
This commands for hide your changes and work on different branches or for implementation some realization of your code and save in stashes without branches and commit your custom case!
And later you can use some of stashes and check which is better.

Part 3:
Stash command for local hide your changes.
If you want work remotely you must commit and push.

teddcp
  • 1,514
  • 2
  • 11
  • 25
Olexander Yushko
  • 2,434
  • 16
  • 16
20

The main idea is:

Stash the changes in a dirty working directory away

So basically, the Stash command keeps the changes that you don't need or want (at the moment), but you may need them.

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.

Robbie Dee
  • 1,939
  • 16
  • 43
nzrytmn
  • 6,193
  • 1
  • 41
  • 38
19

You can use the following commands:

  • To save your uncommitted changes

    git stash

  • To list your saved stashes

    git stash list

  • To apply/get back the uncommited changes where x is 0,1,2...

    git stash apply stash@{x}

Note:

  • To apply a stash and remove it from the stash list

    git stash pop stash@{x}

  • To apply a stash and keep it in the stash list

    git stash apply stash@{x}

Anushil Kumar
  • 674
  • 8
  • 8
11

I know StackOverflow is not the place for opinion based answers, but I actually have a good opinion on when to shelve changes with a stash.

You don't want to commit you experimental changes

When you make changes in your workspace/working tree, if you need to perform any branch based operations like a merge, push, fetch or pull, you must be at a clean commit point. So if you have workspace changes you need to commit them. But what if you don't want to commit them? What if they are experimental? Something you don't want part of your commit history? Something you don't want others to see when you push to GitHub?

You don't want to lose local changes with a hard reset

In that case, you can do a hard reset. But if you do a hard reset you will lose all of your local working tree changes because everything gets overwritten to where it was at the time of the last commit and you'll lose all of your changes.

So, as for the answer of 'when should you stash', the answer is when you need to get back to a clean commit point with a synchronized working tree/index/commit, but you don't want to lose your local changes in the process. Just shelve your changes in a stash and you're good.

And once you've done your stash and then merged or pulled or pushed, you can just stash pop or apply and you're back to where you started from.

Git stash and GitHub

GitHub is constantly adding new features, but as of right now, there is now way to save a stash there. Again, the idea of a stash is that it's local and private. Nobody else can peek into your stash without physical access to your workstation. Kinda the same way git reflog is private with the git log is public. It probably wouldn't be private if it was pushed up to GitHub.

One trick might be to do a diff of your workspace, check the diff into your git repository, commit and then push. Then you can do a pull from home, get the diff and then unwind it. But that's a pretty messy way to achieve those results.

git diff > git-dif-file.diff

pop the stash

Cameron McKenzie
  • 3,684
  • 32
  • 28
5

If you hit git stash when you have changes in the working copy (not in the staging area), git will create a stashed object and pushes onto the stack of stashes (just like you did git checkout -- . but you won't lose changes). Later, you can pop from the top of the stack.

gyorgyabraham
  • 2,550
  • 1
  • 28
  • 46
  • I think it is also from Index. This is from Git docs: Use git stash when you want to record the current state of the working directory and the index, – Manuel Rivera Oct 21 '21 at 13:34
4

The stash command will stash any changes you have made since your last commit. In your case there is no reason to stash if you are gonna continue working on it the next day. I would only use stash to undo changes that you don't want to commit.

Severin
  • 8,508
  • 14
  • 68
  • 117
  • 2
    No, `git stash` will not change your branch. It will especially not "revert" any committed changes. It will only (temporary) discard any uncommitted changes on your files. - It might seem picky, but those kind of words have a very special meaning in context of git. You should really not mix those up. – michas Dec 12 '13 at 08:20
  • Thanks for pointing that out. I changed my answer accordingly. – Severin Dec 12 '13 at 08:30
  • In git a "branch" is defined as a series of commits. `git stash` will not touch any commits and therefore will not modify any branch at all. It will not "remove" anything from a branch an it will not "reset" it in any way. The branch stays the same, only the files in the working tree change. - Those are two totally different things. – michas Dec 12 '13 at 08:35
  • It won't discard but "stash" your changes! Git maintains a LIFO structure for stashes, so a stash is actually a push and you can pop from the top of it. The word "discard" means you will lose anything, but you won't. – gyorgyabraham Dec 12 '13 at 09:19
1

Main use cases are already provided in above answers.

One of the use case of stash is that If the changes on your branch diverge from the changes in your stash, you may run into conflicts when popping or applying your stash.

You can use git stash branch to create a new branch to apply your stashed changes to. For example,

git stash branch master_stash_newBranch stash@{1}

This checks out a new branch based on the commit that you created your stash from, and then pops your stashed changes onto it.

Manish Jain
  • 1,197
  • 1
  • 11
  • 32
1

Maybe you can look at stash as a temporary "private" commit. When you stash, you are not adding to the commit history that others will see. It's for situations where you quickly need to tuck something away.

Just as one simple example: you need to go back to the master branch quickly (for whatever reason) and don't have time to add to staging area or make a proper commit (maybe you don't have time to review the work you did and cannot quickly come up with a clear commit message and description?).

A terrible commit will be there for all to see. Stash is similar to a commit, you get to add a message for yourself, reset the working directory, and then you can come back later, and you'll be the only person that can see it. At least, I don't believe pushing stashes is a defult behavior.

There are many other uses mentioned here.

One way to think of stash that might be helpful is as a storage area outside of the git repository "machinery", separate from all branches, and therefore you can access it from anywhere.

mrwonderfulness
  • 361
  • 2
  • 7
0

You can use both ways either to stash and start or create a new branch from upstream. Stash is more convenient way to save undo redo your changes.

Vipul Pandey
  • 1,507
  • 11
  • 20