git stash temporarily shelves (or stashes) changes you've made to your working copy so you can work on something else, and then come back and re-apply them later on.
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.
Git stash is used to save our changes in one place. The data structure for this way is stack. The top of stack is alway the latest changes that we have just pushed to the stack. To access the element of the stack, we can use syntax: stash@{n} .
The key difference between git stash pop and apply involves the stash history. When a developer uses the git stash apply command, the most recently saved stash overwrites files in the current working tree but leaves the stash history alone. In contrast, the pop command restores files but then deletes the applied stash.
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
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.
The main idea is
Stash the changes in a dirty working directory away
So Basicallly Stash command keep your some changes that you don't need them or want them 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.
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}
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.
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?
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.
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
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With