loading...

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

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

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.