

You can solve these conflicts exactly with the same options that you know from merging branches.

Then create a stash manually like shown in this blog post, and after that you can checkout the master branch smoothly, as you won’t have any uncommitted local changes anymore after you created the stash.ītw., when applying a stash, you can get conflicts in a way like when merging a branch. If you don’t want to apply the changes to the master branch, you should click “Cancel” in this dialog. Then it will apply the changes from the stash to the master branch. This will stash your uncommitted changes from the feature branch, it will checkout the other branch, which is in this sample the master branch. Instead of doing a force checkout, you can also click on “Stash and Continue”. But Visual Studio shows you another dialog after clicking on “Force Checkout” to ensure that you’re really sure to undo your local changes. That means your uncommitted changes will be lost. In this window you can do a force checkout, which means Visual Studio will undo the local changes and checkout the master branch. Visual Studio notices the problem and shows this window: So let’s see what happens when we try to checkout the master branch by using the context menu like below: The checked out branch feature/customerLogin has local changes, and it also does not point to the same commit as the master branch (You can’t see that in the screenshot, so just believe me :)). In the picture below you see the branches page of Team Explorer. As you saw in the screenshot above, I have made changes to the Program.cs file. But what if you are not ready yet to commit? Instead of undoing or committing your changes, you can also stash them, and this is what Visual Studio actually suggests when you try to checkout another branch and the other branch points to another commit and you have made local changes that you haven’t committed yet (yes, I know, a lot of conditions in this sentence. But if the other branch doesn’t point to the same commit, you have to commit your local changes first to checkout the other branch. This works without a problem if the other branch points to the same commit as the branch that you’ve checked out. So, stashing is great for storing changes that you do not want to commit yet.Īnother thing where stashing is quite useful is when you want to switch to another branch. So let’s select in my case “Pop All as Unstaged”, and then we’re back at the state that we had at the beginning of this blog post. If you hadn’t any staged files before you created the stash, then you won’t see a difference between the two options.

Let’s select “Stash All”.Īfter clicking on “Stash all”, you can see now the created stash, and the branch doesn’t have any changes anymore. So both stash options will have the same effect. But in my case above, I haven’t staged the Program.cs file. If you want to keep the changes in the branch that you have already staged for a commit, you select “Stash All and Keep Staged”. Clicking on “Stash All” will also undo all those uncommitted changes in your branch. So, a stash is like a local copy of your uncommitted changes. This will create a stash that contains all the uncommitted changes. Now click on the Stash button:įrom the drop down, click on “Stash All”. The message is optional for a stash, I entered in the screenshot below the message “First draft of customer login”. Just enter a message in the Changes window of Team Explorer. But you want to save the functionality for now and look at the original branch without changes.
#Git stash apply vs pop code#
But you’re not ready to commit it, as you didn’t reach yet the code quality you normally write. If you have looked already at the Changes page of Team Explorer in Visual Studio 2019, you might have seen that it has a new Stashes section.
