Create Git branch with current changes

If you hadn’t made any commit yet, only (1: branch) and (3: checkout) would be enough.
Or, in one command: git checkout -b newBranch

With Git 2.23+ (Q3 2019), the new command git switch would create the branch in one line (with the same kind of reset --hard, so beware of its effect):

# First, save your work in progress!
git stash

# Then, one command to create *and* switch to a new branch
git switch -f -c topic/wip HEAD~3

Or, as suggested in Alia’s answer, use git switch -m, without git stash:

git switch -c topic/wip -m

--merge

If you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context.

However, with this option, a three-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch.

When a merge conflict happens, the index entries for conflicting paths are left unmerged, and you need to resolve the conflicts and mark the resolved paths with git add (or git rm if the merge should result in deletion of the path).


As mentioned in the git reset man page:

$ git stash                # (0) Save your work in progress
$ git branch topic/wip     # (1)
$ git reset --hard HEAD~3  # (2)  NOTE: use $git reset --soft HEAD~3 (explanation below)
$ git checkout topic/wip   # (3)
  1. You have made some commits, but realize they were premature to be in the “master” branch. You want to continue polishing them in a topic branch, so create “topic/wip” branch off of the current HEAD.
  2. Rewind the master branch to get rid of those three commits.
  3. Switch to “topic/wip” branch and keep working.

Again: new way (since 2019 and Git2.23) to do all that in one command:

git switch -f -c topic/wip HEAD~3

Note: due to the “destructive” effect of a git reset --hard command (it does resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded), I would rather go with:

$ git reset --soft HEAD~3  # (2)

This would make sure I’m not losing any private file (not added to the index).
The --soft option won’t touch the index file nor the working tree at all (but resets the head to <commit>, just like all modes do).


Leave a Comment