What to do when you commit to the wrong Git branch pt. 2
In this post, you’ll learn not only how to undo and commit to a new Git branch but how to move commits to another branch.
- September 15, 2020
What it means to commit to the wrong Git branch
The end of the world. Just kidding! This mistake is not unheard of and can happen to just about anyone — expert or beginner.
Let’s say you’re running off two active branches in your Git repository and one day you accidentally commit an update to the wrong branch which you then push to your Git server (for example Bitbucket). Uh-oh!
It’s worth noting that setting branch permissions on your Git server is good protection against this mistake since it can be used to block direct pushes to mainline branches and enable you to enforce the use of feature branches and pull requests instead.
For the sake of argument, we’ll assume you’ve performed a number of commits to the wrong branch. Now what?
Don’t panic!
When you realise this has happened, you need to stop and check which of the commits associated with the wrong branch have been shared with other people i.e. pushed to your Git server.
The golden rule is to: Never rewrite the history of a branch that you have already pushed to a Git server and shared with others.
Let’s say you have two branches that exist on the server:
- MG-200-correct-branch
- MG-201-wrong-branch
You thought you were working on MG-200-correct-branch, but you were actually working on MG-201-wrong-branch.
First, you’ll need to run a command that allows you to see what commits have and have not been pushed to the server:
Here’s some example output:
afada1d (HEAD -> MG-201-wrong-branch) change on wrong branch (local)
630c250 (origin/MG-201-wrong-branch) change on wrong branch (pushed)
9a208bc (origin/develop, origin/MG-200-correct-branch, origin/HEAD, develop, MG-200-correct-branch) Task-123: activity
The “–oneline” argument keeps the output short (one line per commit) and the “–decorate” argument reveals what commits your references are pointing to.
The references in red starting with origin/ are remote branch references. A remote reference tells you what the server branches were pointing to when you last talked to the server (i.e. got changes from it via a fetch or pull).
The references in green are your local branches. If it has been a while since you shared your changes (pushed), these references will not be aligned with the remote branch references.
The above output shows:
- The latest commit you shared (pushed to the server) associated with MG-201-wrong-branch is 630c250. We know this because the commit has the remote branch reference “origin/MG-201-wrong-branch” next to it.
- You are on the local branch MG-201-wrong-branch and have made one commit locally to this branch (afada1d).
Let’s first get all of the changes where you actually intended for them to go, i.e. to branch MG-200-correct-branch.
You do this by getting MG-200-correct-branch to point to the commit where MG-201-wrong-branch is currently pointing:
git reset --hard MG-201-wrong-branch
After this, the output of “git log –decorate –oneline” looks like:
afada1d (HEAD -> MG-200-correct-branch, MG-201-wrong-branch) change on wrong branch (local)
630c250 (origin/MG-201-wrong-branch) change on wrong branch (pushed)
9a208bc (origin/develop, origin/MG-200-correct-branch, origin/HEAD, develop) Task-123: activity
You can now share MG-200-correct-branch since it has the correct commits on it:
… and the log output is now:
afada1d (HEAD -> MG-200-correct-branch, origin/MG-200-correct-branch, MG-201-wrong-branch) change on wrong branch (local)
630c250 (origin/MG-201-wrong-branch) change on wrong branch (pushed)
9a208bc (origin/develop, origin/HEAD, develop) Task-123: activity
So all is now well regarding MG-200-correct-branch, however, you still have the wrong commits associated with MG-201-wrong-branch so there’s still a bit left to do before you can celebrate.
The good news is, you’ve not yet pushed (shared) your afada1d commit to MG-201-wrong-branch so you can sort that once again with reset (maybe your main go-to Git commands when you need to fix problems):
git reset --hard HEAD~1
This at least undoes the local changes made on MG-201-wrong-branch, and the Git log now looks like this:
630c250 (HEAD -> MG-201-wrong-branch, origin/MG-201-wrong-branch) change on wrong branch (pushed)
9a208bc (origin/develop, origin/HEAD, develop) Task-123: activity
Note that you can no longer see the references for MG-200-correct-branch: that’s because they are no longer reachable from where you currently are in the Git commit history.
However, the final problem to solve is slightly trickier. Your commit 630c250 was pushed to the server (shared with others) and as stated earlier, rewriting the history of a branch that has already been pushed to a Git server and shared with others is a big no-no.
For this reason, it is best to make a further commit that effectively undoes the changes you erroneously committed and pushed.
So usually the best solution is to effectively make a further change that undoes the code changes pushed.
Luckily, Git provides “git revert” command for such a situation:
After you push the change (git push origin MG-201-wrong-branch), your Git log looks like this:
88431f1 (HEAD -> MG-201-wrong-branch, origin/MG-201-wrong-branch) Revert “change on wrong branch (pushed)”
630c250 change on wrong branch (pushed)
9a208bc (origin/develop, origin/HEAD, develop) Task-123: activity
To prove that your file changes are no longer on MG-201-wrong-branch, use a git diff:
For which git diff returns no output if the commits represent the same repository content.
Finally, you can checkout the correct branch and continue with your day! 🙂
Job done!
We hope you found this blog useful, and if you need further assistance, please do not hesitate to speak to one of our experts.
Clearvision provides training for businesses of all sizes, covering an array of software applications and systems including Git to help you achieve your goals.
Philip Armour
Phil has been working in software development environments since 1998. He is Atlassian Certified in Jira Admin (ACP-100) and Agile Development with Jira (ACP-300) and has a deep understanding of Git and the wider ALM toolset, having helped bring about many positive tool transformations through his consulting work.
Atlasssian expert resources
Visit our blog for expert news and articles from the Atlassian world. On our resources page you will find recorded webinars, white papers, podcasts, videos and more.
The Software Blog
Read our blog for articles offering best practice advice written by Atlassian experts, as well as the latest news concerning your software.
Software White Papers and Guides
Dive deep into Atlassian software with our white papers and guides on individual tools, partner products, services, and best practices, written by the experts.
Expert Webinars
All of our webinars are pre-recorded and available to watch on-demand. Enjoy everything from partner features to application demos and updates from Atlassian experts.
