There is lots of talk about how it's not easy to "undo" a merge in git. Short version: if you undo a merge commit, it also tells git to never merge those changes back in in the future.
Is there something I can do when doing the merge in order to abate this problem? There are plenty of situations where undoing a merge would be really, really useful, just in the normal course of software dev, and more crucially, in controlling the state of a release branch, when changes need to be rolled back.
edit
I have seen the solution in this article and don't really consider it a solution, more of an explanation of the problem. It requires
- always use --no-ff
- remember all your undone-merges when you want to bring back in code that depends on them (this could be a few hours, days, week, or months in the future…)
what I want
Here is how it works in Subversion. Let's say I have a branch called "release-candidate", which is what we run on the staging server and where we try out features. Let's say I merge in feature A branch. In Subversion, it's all one changeset, and all history for all files is merged. Let's say we don't like it, so we want to take it out. We just undo that single changeset, and don't have to think about anything else. We can merge feature branch A back in at any time in the future without having to remember that we at one point merged it in and took it out.
I'd like to be able to get as close to that flow as possible. I'd like to optimize for "not having to remember stuff in the future", even if it makes things take more steps along the way somehow. (this might be impossible...)