In the image below we can see a repository with my NeoVIM settings (see the link in the References section). A new stash goes to the top of the Stack, and when you apply the stash it’ll be removed from the top.Īpplying the stash means getting changes back. You can stash stuff as much as you need, as it will work as an actual Stack. When we’re adding features, we create files, so you can run: git stash -include-untracked # or git stash -u for short To save your current changes for later, you just need to run the following command: git stashīy default, it only stashes tracked files but you’ll likely need to do it for untracked ones too. In the next sections, we’re going to simulate the scenario we described before. It’ll stash our changes and get back to the last commit in the current branch (HEAD commit). The command saves your local modifications away and reverts the working directory to match the HEAD commit. 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. You’re probably asking: but what git-stash is and how does it work? Reasonable questions, I would say. What if we could stop the current work exactly as is and go fix that other issue (and save the day)? That would be great, and it is, that’s where git-stash comes in. You have to be one to avoid a mess in the commit history. That works, especially if you are a creative person. They usually write only "WIP" in the commit message (please don’t do that). I have not seen people doing it in a good way, though. You would be solving the problem, and would just need to think a bit about a good message to go with that. You could easily commit your changes even knowing that they’re not committable. What do you do? Naively Solving the problem Things can go wrong and maybe you have to stop what you’re doing right now and work on an urgent fix. But what if you get interrupted before finishing a committable change?
#Git stash command software#
You’ll most likely do a similar process as described above at least once in your workflow.Īs the good software developer that you are, you commit your changes in a semantic and well-packaged way, meaning you only commit the code when you have a block of effort. The workflow you’re using doesn’t matter for this article. Whatever it is, you probably just checkout a branch, do some good code, commit your changes (with a good commit message of course), then push your changes to the remote repository.
#Git stash command how to#
What to do in this case? Maybe you can even have a good idea of how to solve it using that small set of commands, but maybe you could do it more efficiently (and elegantly) using git-stash. We’re going to discuss a scenario that likely fits the other 20% of the problems when you get interrupted in your normal workflow. It’s the real Pareto Principle where you, with 20% of the commands, can solve 80% of the problems, and that’s amazing.
With that small set of commands, you can solve most of your problems.
At this point, you probably already know that all the usual commands (e.g git-add, git-checkout, git-commit) are enough for you.
0 kommentar(er)
