0

We have two branches, staging and prod. Features are worked on then merged into staging. They are tested then cherry-picked into prod. We have one commit in staging, but want to split it into two different commits for prod.

Will this cause any issues with merge conflicts in the future having two different git histories for each branch or as long as the branches end up in the same state it is OK?

user7692855
  • 1,582
  • 5
  • 19
  • 39
  • I have objections to your present strategy. First, *don't "cherry pick" into prod.* What's running in prod should be composed of branches. Too much otherwise depends on you doing the 'picking' *completely* and *correctly,* and that's too much to ask. The commits in each environment should be identical, as are the branches that are committed. – Mike Robinson Aug 25 '20 at 19:01
  • To clarify: when you begin a new production update, first start a branch. Now, merge specific *whole* development-branches into it. Finally, merge the completed branch, with its sub-branches, into main – and "tag" the production branch with a dated tag to denote each release point. Resist the urge to "rebase" or "consolidate" the branches or commits in any way. – Mike Robinson Aug 25 '20 at 19:02
  • I understand its not ideal, but this is the system we have to work with for the time being. I'm wondering if instead of doing a cherry-pick of a single commit, having two commits with the same net effect will cause issues further down the line. – user7692855 Aug 25 '20 at 19:04

1 Answers1

-1

Rather than cherry-picking (which leads to commit duplication and missed functional dependencies), I would merge the selected feature branch again to prod.

That is akin to the gitworkflow (one word), and allows you to select only the feature branch you want to prod.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250