git strategy to have a set of commits limited to a particular branch

I need to merge between dev and master frequently.

I also have a commit that I need to apply开发者_StackOverflow to dev only, for things to work locally.

Earlier I only merged from dev to master, so I had a branch production_changes that contained the "undo commit" of the dev special commit. and from the master, I merged this. Used to work fine.

Now each time I merge from dev to master and vice versa, I am having to cherry-pick and apply the same commit again and again :(. Which is UGLY.

What strategy can I adapt so that I can seamlessly merge between 2 branches, yet retain some of the changes only on one of those branches?

I would recommend a merge driver (scripts declared in a merge directive within a .gitattributes file) in order to prevent certain files to be affected by a given commit.
(for instance, if certain files must not be modified, that driver would be as simple as a "keep mine" merge. That has been used to merge only specific directories by example, or to track how config files are managed per branch.)

THE OP adds:

But I am looking more for a clever solution, if one exists, like "create a branch that has the undo commit only and apply it to master, fake it on dev"

Clever solution?...
Well I can propose git rerere (reuse recorded resolution of conflicted merge: if you merge to dev trigger a conflict, and if the resolution of that conflict is you effectively cancelling that merge, you can record that resolution, in order to have it automatically repeated during the next merge.

See Rerere Your Boat... by Scott Chacon for more in this command.

Lie to git: make the diff in a separate branch rooted at the branch point of your 'dev' branch. Then "merge" it into master without actually changing master: something like git merge -s ours devfix-branch (you do this on master)

Then go back to dev and merge normally: git merge devfix-branch. Now both dev and master will think they already have the devfix, and you can continue to merge to master.

It is left as an exercise to the reader to see if this actually works, or can be made to work.

I'd do this with a local branch (i.e. which was never pushed anywhere) in the dev repo which I'd rebase to the top of the dev branch whenever I pulled from master. It's not quite seamless, but I think it's a little better than cherry-picking.