Git push (force) after merging commits into another branch

Question

We use git with different branches. A colleague made a mistake and committed (+ pushed) a few different commits to the wrong branch (dev branch).

The branch he committed to should be merged into 'master' anyway. I wonder if these steps would be safe:

Merge changes from dev branch into master
Push all changes to origin/master
In dev branch - revert so all commits are dropped
Push (force) to make sure the remote repository is in sync (e.g: drops all wrong commits)

Will these pose any issues in the repository later on ? (e.g: with the merge commit and the fact that the original commits were removed) ?

score 0 · Answer 1 · answered May 06 '16 at 09:00

0

The original commits will not be removed. They are still in the master branchs history, just not anymore in the dev branch history. You shouldn't get any issues except for the rewritten history of the dev branch that will force everyone who got that "wrong" state of the dev branch already and based work onto it to rebase their local branches like described in the help of git rebase.

answered May 06 '16 at 09:00

Vampire

35,631
4
76
102

on which branch do we need to run git rebase, and why ? – lysergic-acid May 06 '16 at 23:56
If you do not revert the commits (making new commits that revert the unwanted changes), but do a reset to really drop the commits from that branch, you rewrite public history and everyone already fetched that old history will need to rebase each local branch that has this old history in their history, because now this history changed and they would reintroduce that wrong history on push. – Vampire May 07 '16 at 00:10

score 0 · Answer 2 · answered May 06 '16 at 09:01

The steps you're proposing would surely do what you expect. Just one clarification: git revert actually creates a new commit (which un-does what the commit we're reverting did). Consequently, in the last step, you will not need to force in order to be able to push.

Note that if you're willing to force push (I assume you know the consequences) you may do something easier:

let your colleague reset his dev branch so that it doesn't not contain the commits you don't want (eg: git reset --hard <sha1 of commit before he merged>
let him push force, to actually drop the wrong commits (git push -f origin dev)

and now he is back to where he was before the wrong merge, so he can start again, using the correct branch.

More precisions: let's say you had the following commits

-- A -- B
        \- dev
-- C -- D
        \- master

and the your colleague added commit E to the wrong branch. Then, with the steps you're proposing, you'll have:

-- A -- B -- E -- E'
             \     \-- dev
-- C -- D ----F
               \-- master

where F is just a merge commit, and where E' is the revert.

As we can see: as far as code is concerned, each branch will be in the expected state. However commit E will not, topologically, be removed from dev.

I actually meant git reset (in some GUI tools this is called Revert). Also, what are the consequences for force push in this case? (there should be no further commits in the dev branch) — lysergic-acid, May 06 '16 at 23:57
Subtle bad things can happen when we force push, if someone else already pulled the branch: if he doesn't pay attention, he may end up out of sync with the forced pushed content, and may re-push the stuff we just deleted — gturri, May 07 '16 at 08:18

Git push (force) after merging commits into another branch

2 Answers2