DEV Community 👩‍💻👨‍💻

Cover image for Oops, I just pushed a git commit to the wrong branch.  What now?
Nick Raphael
Nick Raphael

Posted on

Oops, I just pushed a git commit to the wrong branch. What now?

We are currently running off two active branches in our git repository. And by accident I just committed an update on the wrong branch and pushed it. Luckily, getting out of this mess isn't hard.

The erroneous commit is 65c356c8c

First, lets pull the commit from Branch1 into Branch2 where it should be...

   git checkout Branch2 
   git cherry-pick 65c356c8c
Enter fullscreen mode Exit fullscreen mode

This pulls the commit across into the correct branch. Great. We can now push the commit is normal. But what about the commit still sitting on Branch1 in my local index? Lets fix that now.

   git checkout Branch1
   git reset --hard HEAD~1
Enter fullscreen mode Exit fullscreen mode

This will reverse the last commit.

As with all git issues, the secret is to not panic. Jump on the net and find a simple solution.

Top comments (18)

Collapse
 
lietux profile image
Janne "Lietu" Enberg

The fact that Git allows you to edit history is one of the biggest issues with Git - if you make a mistake, don't try to hide it, but actually fix it - reverse commit and push. No need for push -f (every time you do that, you should think you are doing something incredibly wrong) and potentially ruining other people's ability to sync with the repository as well.

git revert 65c356c8c

After fixing the branch, you can of course continue to cherry pick the commit to your other branch.

Collapse
 
nickraphael profile image
Nick Raphael Author

I completely agree. I think this is a better solution than my post. Let me run this past you...

First I can get the commit into the correct branch with:
git checkout Branch2
git cherry-pick 65c356c8c

I then undo the other commit with:
git checkout Branch1
git revert 65c356c8c

Is that your suggestion?

Collapse
 
lietux profile image
Janne "Lietu" Enberg

Well your #1 priority should be to fix what you broke. Since revert does not remove the commit, you don't need to hurry with "saving it" or anything - first revert and push to fix what you broke, then you can go about cherry-picking it to where you needed the code in.

Collapse
 
baukereg profile image
Bauke Regnerus

Force pushing is absolutely fine in case of personal feature branches.

Collapse
 
smeijer profile image
Stephan Meijer

No it's not. We also have this rule, and I so do it. But it's not "absolutely fine".

A reviewer might already have checked your branch before. And by changing your history, you remove the option for them to only review your latest changes.

The entire review must now be done all over.

Comments that were bound to a specific commit, are now gone as well.

Thread Thread
 
baukereg profile image
Bauke Regnerus • Edited on

Agreed. That's why I said "personal" feature branch, before it's touched or reviewed by anybody else.

Then again, I don't mind a force push to prevent commits like "oops forgot semicolon". Commits like that are pollution and won't help anybody in the future trying to look back in history. I usually remove them when a pull request is ready to be merged.

Comments are temporary anyway and no replacement for documentation.

After all it's about knowing what your doing. I prefer communication/education over arbitrary rules in my team.

Collapse
 
shazam19 profile image
Shamsad

In this case you will have to force push (push -f) your branch (Branch1). Force pushing a branch is generally not a good idea, unless you are absolutely sure that nobody else has pulled from that branch.

In this scenario revert is the safest choice to remove unwanted changes from a branch that's already been pushed.

Collapse
 
mgohin profile image
Maelig • Edited on

Better use git push --force-with-lease to be sure you don't override your colleagues work if they pushed before you pushed force.

More info :

Collapse
 
sivaraam profile image
Kaartic Sivaraam

Yeah. Its good to use --force-with-lease instead of --force. Its also worth noting the case in which --force-with-lease might not work as you expect it to.

Quoting from –force considered harmful; understanding git’s –force-with-lease:

A more subtle problem is that it is possible to trick git into thinking that a branch has not been modified when it has. The main way that this would happen under normal usage is when Bob uses git fetch rather than git pull to update his local copy. The fetch will pull the objects and refs from the remote, but without a matching merge does not update the working tree. This will make it look as if the working copy of the remote is up to date with the remote without actually including the new work, and trick --force-with-lease into overwriting the remote branch, as you can see in this example: ...

Thread Thread
 
mgohin profile image
Maelig

that's evil ! :)

Collapse
 
jessekphillips profile image
Jesse Phillips

Since you pushed the branch, be sure to communicate to all collaborators.

Collapse
 
dimitri_acosta profile image
Dimitri Acosta

To be honest, I prefer to use git revert so I don't have to delete anything from the history

Collapse
 
bourhaouta profile image
Omar Bourhaouta

Looks like you're playing with fire 🔥

Collapse
 
vigneshthedev profile image
Vigneshkumar Chinnachamy

Also, don't forget to push Branch1 and Branch2 at the end :).

Collapse
 
siimsoni profile image
Kristjan Siimson

As others have already pointed out, if you use a remote repository, tread with care.

Collapse
 
chema profile image
José María CL • Edited on

Thank you! I've read the discussion comments and I learned a lot from you :)

Collapse
 
itsparser profile image
Vasanth

Adding to that, You can just cancel the commit and sustain the code by replacing (Hard with soft)

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.