Filed under: Git, — Tags: Git — Thomas Sundberg — 2020-03-11
It happens that you are working on something and realize that you have to change context. Something urgent popped up and you need to get it into production as soon as possible. However, you have uncommitted changes that doesn't work properly. What do you do now? You can't commit your current changes. They are not done and should not end up in production. And you are smart so you avoid branching. Your current changes are on master and should be on master.
One way to deal with this, and be able to verify your change, is to hide your current changes and do the new changes needed. You stash your changes.
First, lets look at the local changes, you do this with the command
git status
Then stash the changes with the command
git stash
This will hide your changes. Your repository is now in the state it was before the last changes, i.e. you are back at your latest commit.
Do git status again to see that you don't have any local changes.
You can now do your new changes. You can build and test your application with the latest changes, not the ones that where half done.
When you are happy, you commit and push your work. I usually do
git fetch
git rebase
git push
It is now time to go back to your half done work that you stashed earlier. Popping the stash will bring them back. You do this with the command
git stash pop
Your earlier changes are now retrieved. Do git status
to verify that you have your changed files.
It is possible to hide your work in git. Stashing them is one way. Other tools have other ways, some have the concept of shelving changes.
I would like to thank Malin Ekholm, Mika Kytöläinen, and Henrik Jörnvall for feedback.
RSS