-1

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?

Qiulang
  • 10,295
  • 11
  • 80
  • 129
  • Your exact workflow is not entirely clear to me, but I can suggest creating hotfix branches off `master`, where you fix the bugs, then merge directly back to the `master` branch. – Tim Biegeleisen Dec 09 '20 at 03:34
  • No that's what I said in my question, I can't do that. I can't create a bug fix branch and use it as the merge base because the code I need is ALREADY in dev branch. – Qiulang Dec 09 '20 at 03:37
  • Then fix your workflow such that this doesn't happen. That's my answer. – Tim Biegeleisen Dec 09 '20 at 03:38
  • But how and that is my question. I believe it is always possbile that the code master branch needs is already in a "future" branch. – Qiulang Dec 09 '20 at 03:41
  • Have you already merged the feature branch into master once, and now you fix a bug in feature, and the question is how to bring that hotfix commit back into master? – Tim Biegeleisen Dec 09 '20 at 03:42
  • Right and I also need to show master is the root! That is the tricky part and my question. – Qiulang Dec 09 '20 at 03:44
  • Then you should cherry pick in this case, but a better long term solution would be to fix the bugs in _master_, and then rebase the feature/release branches on master to get the latest bug fixes. This approach leaves `master` as the source of truth for the other branches, which is the flow you really want. – Tim Biegeleisen Dec 09 '20 at 03:49
  • Of course I know that. But reality is that our test team will identify a couple bugs we need to fix and we will fix in dev branch and suddenly the customer support team tell us that we need a specific bug to be fixed in product asap. And hence the problem. – Qiulang Dec 09 '20 at 04:02
  • Please re-read the above comment `:-)` – Tim Biegeleisen Dec 09 '20 at 04:03
  • I did but what I told you is the reality and my question remains unsolved, .i.e is it possbile to avoid duplicated merge ? It seems not. – Qiulang Dec 09 '20 at 04:04
  • You've said in a comment that you can't create a bug fix branch because the fix is already in a dev branch. Can you explain your reasoning here? I would create a branch off master, cherry-pick the dev commits into the bug fix branch, and then merge that into master in the usual way (e.g. via a pull request). In other words, I don't see the problem of the fix being in the dev branch additionally - when you merge this into master, the duplicate commit will be automatically skipped, since master will presumably have it at that point in time. – halfer Dec 09 '20 at 13:18
  • It is not I can't but no use. According to your method, when merge the bug fix branch in to master, it is normally a fast-forward. How is that different from cherry-pick into master directly ? And my question remains, ie. I need to show master is root of all branch, so now I need an additional duplicated merge in dev. That merge is one I don't want. – Qiulang Dec 09 '20 at 13:33
  • I'm voting to close this as "needs focus" because the goalpost-shifting is getting to the point of self-contradictory claims. – jthill Dec 10 '20 at 07:59
  • Please tell me where you see the ”self-contradictory claims" I will just delete my question later. – Qiulang Dec 10 '20 at 08:01
  • @jthill I can't delete my question because you have answered it. So I rewrote it please let me know if it still has "self-contradictory claims" ? – Qiulang Dec 10 '20 at 09:34
  • @TimBiegeleisen I got 2 votes to close my question so I have re-wrote it. Can you take a look to see if it is more clearer than the yesterday's version ? Thanks – Qiulang Dec 10 '20 at 09:36
  • "git merge -s ours bugfix26535 will introduce an empty commit in dev. And that is the problem I want to fix in the first place!" from comments on my answer, but (a) you say in the question you introduce empty commits as standard practice, and (b) they weren't called out as any sort of problem before that. That's just for starters. – jthill Dec 10 '20 at 09:52
  • @jthill So I believe my second version has fixed that. – Qiulang Dec 10 '20 at 09:54
  • "we always do a merge from master to dev branch after that. The merge normally doesn't introduce code change in dev branch" is unchanged. I believe you're not making any sense at all. – jthill Dec 10 '20 at 09:58
  • Do you mean that merge is unnecessary ? – Qiulang Dec 10 '20 at 10:01

1 Answers1

0

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.

Qiulang
  • 10,295
  • 11
  • 80
  • 129
jthill
  • 55,082
  • 5
  • 77
  • 137
  • I update my question about why my problem happened in the first place and I feel that is quite common (at least that is what I find) – Qiulang Dec 09 '20 at 04:17
  • That's what this answer addresses, a bugfix you need to pick out of a longer branch. – jthill Dec 09 '20 at 04:18
  • I am not familiar with what you said so I need to investigate it first. Thanks. BTW, part of reason I update my question is because I feel it is not my unique problem, I also don't get why my question got closed vote. – Qiulang Dec 09 '20 at 04:22
  • I have been thinking about your solution and I come to the conclusion it won't work! git merge -s ours bugfix26535 will introduce an empty commit in dev. And that is the problem I want to fix in the first place! – Qiulang Dec 10 '20 at 07:38
  • Besides, your first step git checkout -b fixbug26535 $(git merge-base all active tips with the bug) is no use in my case. Because we have tried hard to make master the root of all branches (and causes my problem), so the result of that will be a branch just duplicate the master branch. – Qiulang Dec 10 '20 at 07:39