← Back to context

Comment by sirmarksalot

7 years ago

Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you.

After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch.

In a merge workflow, you have to either fail forward (fix the problem, rather than backing out the merge), or reset/rebase the shared branch, and email repair instructions to everyone on the team.

Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.

  • It’s a lot of paperwork to avoid a perfectly safe and normal git command.

    • No it isn't. You'd always want to create a feature branch so that you can PR the fix - it's a change going into master, it should go through the normal change-going-into-master review flow. And you'd always have to run some command to indicate that this was the branch where you wanted to undo what you'd done to master. That the command is called "revert" is a little weird, but it's no more paperwork than any other command would be.