How to reduce the merge-redundancy, which is used to make sure master is the root of all, in our Git workflow?

Question

We use the "Git workflow" by Vincent Driessen, 2 long lived branches master/dev. We believe we need 2 long lived branches instead of one in github flow because we do enterprise (2B) business. Our customer prefer a stable product over our latest features.

After each release (merge dev into master) our test team will identify a couple of bugs we need to fix in the next release, we then fix them in dev branch. The new features we develop are merged into dev branch too. The bug-fix branch and feature branch will be deleted after they are merge in to dev.

But suddenly the customer support team gets some angry call from the customer and tell us that we need a specific bug-fix/feature to be in product quickly. This situation interrupts our normal workflow and introduces the question I am asking.

Because the code changes our customer needs are already in dev branch, we cherry-pick the wanted commits into master (even though we are full aware of the problem that cherry-pick will introduce). Cherry-pick seems the only option here.

But we always want to make sure the master branch is the base for all the other branches, we always do a merge from master to dev branch after that. The merge normally won't introduce code change in dev branch but just to show the branch tree to everyone that master is the root.

I know I can rebase dev branch on master to avoid that merge. But rebase is not ideal either for couples of reasons (I didn't list them here to avoid sidetracking my question)

So is there other way to make sure master is the root of all and also avoid duplicated/empty merge?

Answer 1

The full-fat (I dare say canonical) way to excruciatingly-and-sometimes-gratifyingly-properly apply a commit across branches is

git checkout -b fixbug26535 $(git merge-base all active tips with the bug)
git cherry-pick the bug fix
git checkout where-the-fix-came-from
git merge -s ours bugfix26535

(So if you've got master, dev1 and dev2 and the bugfix is conveniently at the dev1 tip,

git checkout -b fixbug26535 $(git merge-base master dev1 dev2)
git cherry-pick dev1
git checkout dev1
git merge -s ours bugfix26535

)

and now you've got a nice mergeable bugfix branch that won't carry unwanted changes to or create unnecessary conflict in any of the tips it might get merged to. You can merge that to master and dev2 at your leisure.

But because we always want to make sure the master branch is the base for all the other branches, we always do a merger from master to dev branch after that.

You can do that before or after merging the bugfix to master, because the proper ancestry for its changes is already recorded.

To wander towards persnickety about your recording, base your bugfix on the commit that introduced the bug, then merge to the merge base from above to get all the common updates done at once. Ascii graphs of the resulting history will be messy, but the structure will record absolutely everything about what happened and why.