[Mithaldu]

If i understand you right, you want to do this:

    - Checkout master.
    - Start an interactive rebase of master onto the last
      commit before the series of commits you wish to remove.
    - Mark all the commits you don't care about as "skip".
    - Let the rebase run and resolve conflicts on the way,
      the same as you'd do with your current work flow.

[tokenizerrr]

This rewrites history, right? What I meant was a feature branch which got merged into master turned out to introduce unwanted behavior, so while a fix is rolled out to the feature branch I'd like to remove that code from master. What I currently do is revert (git revert, which generates a new commit) the merge commit(s) used to bring that feature branch into master, then when the fix on the feature branch is complete I revert the revert I just made and merge the feature branch again.

[Mithaldu]

You introduce explicit revert commits?

[tokenizerrr]

Yes, this is a feature of git: https://git-scm.com/docs/git-revert

I don't think rewriting the history of public branches is a good idea.

[purephase]

Exactly. I love this process, and endeavour to drop all dev/develop branches from the repos I'm working in. Sensational headline aside, I've seen a lot less untangling when feature-branching off of master and a judicious use of tags.

While it's dated at this point, I've always felt that the Github flow [1] works best (for the projects I'm involved with anyway).

[1] http://scottchacon.com/2011/08/31/github-flow.html