I’m always on the wrong branch. I’m either on
main working on something that should be on a
feature branch. Or I’m on the last branch I was working on and should have cut a new branch. Oh well. It’s never that big of a deal. Basically means switching unstaged changes to a new branch. This is what I normally do:
- Stash all the changed-but-unstaged files
- Move back to master
- Pull master to make sure it’s up to date
- Cut a new branch from master
- Move to the new branch
- Unstash those changed files
Want a bunch of other Git tips? Our “Advanced Git” series has got a ton of them.
Switching unstaged changes to a new branch with the Git CLI it looks like this
Here’s how I generally switch unstaged changes to a new branch in Git:
git status git stash --include-untracked git checkout master git pull git branch content/sharis git checkout content/sharis git stash pop
Switching unstaged changes to a new branch in Git Tower it looks like this
I think you could theoretically do each of those steps to switch unstaged changed to a new branch, one-by-one, in Git Tower, too, but the shortcut is that you can make the branch and double-click over to it.
Sorry, I’m just doing Git Tower but there are lots of other Git GUIs that probably have clever ways of doing this as well.
But there is a new fancy way!
This way of switching unstaged changes to a new branch is new to me anyway, and it was new to Wes when he tweeted this:
git switch -c new-branch
git switchis mainly a cleaner version of branch-related commands in
git switch -c new-branchdoes, is create a new branch and switch to it. Just like
git checkout -b new-branch. Both allow having uncommited changes.
The other part of
git checkoutfunctionality should now be done with
One thing you can do as well when you are on a feature branch, but want to branch off of the master branch is
git switch -c new-branch master. This is the same as
git switch masterfollowed by
git switch -c new-branchand works the same if you replace
git switch -cwith
git checkout -bagain (e.g. for old git versions).
Switching branches will fail, (only) if you have modified files that differ between your feature branch and master. As a workaround you can add the
--mergeflag to ask git to try and merge both changes.
In any case you might not be up-to-date with the upstream master. So you still have to
git pull. This again will be a problem when you have uncommited changes. In this case there is the
--autostashflag. Not sure how much simpler this makes things though ;-)
So all in all, I would say your explicit use of stash is still a good approach, because you are using simple git commands and have full control over what is happening. Alternatively the following would be equivalent if you really want to avoid stashing:
If you still want to also update
origin/masterat the same time, you can do
Why don’t you just use:
It automatically transfers all unstaged changes to the newly created branch.
git switchseems to do similar thing though, but with already commited stuff. I could make use of it just yesterday, will try it soon.
Brilliant! I saw @wes’ tweet about this right after I saw yours and thought #greatMinds!
I cannot wait to use this!