2

I maintain three codelines for each project: 'master' for latest development, 'test' for stabilization, and 'prod' for live code, plus any feature branches.

Periodically, I want to reflect all of the changes from one branch into another. Of course, pushing master into test to begin stabilizing for a new release. Or pushing test into prod to make the stable version live. But also, to bring bugfixes from test into master or even sometimes from prod into test (in the case of an urgent hotfix). There are also some branch-specific changes, such as URLs and keys. Git is wonderful, and I can't imagine the time it has saved me over other systems. But I'm not sure how to do this without running into trouble from time to time.

Deleting and recreating these three "primary" branches isn't practical because they back cloud environments, and because we have distributed developers. Similarly, rebasing is problematic because each of the branches is shared, and changes are pushed from each of them. I've been merging in both directions, as I did with other version control systems like Perforce: merge fixes from test into master, then new development from master into test. But that has caused serious issues that I don't fully understand.

How would you recommend managing these branches so that changes from each can be reflected into the others?

Thanks in advance for your thoughts!

Terrance Cohen
  • 81
  • 3
  • What "serious issues" have been caused by your merging strategy? – Michael Mior Jan 17 '12 at 20:13
  • I think merges should be only one way. That is, if `master` is for latest development, then do any work directly on `test`. – svick Jan 17 '12 at 20:16
  • @MichaelMior for example, after merging prod into test, their HEADs are the same, so merging test into prod results in no changes - I've lost anything that was unique to prod, and must reset --hard HEAD^ – Terrance Cohen Jan 18 '12 at 04:46
  • @svick the trick is how to get bugfixes on test back into master, and later take new dev from master and bring it into test. I suppose it's possible to make changes only to master and always cherry-pick into test, but that's extra overhead, and the two may have diverged making that difficult or impossible (e.g. the file was deleted in master) – Terrance Cohen Jan 18 '12 at 04:50

1 Answers1

2

I never found this kind of "fixed naming convention" working well for the integration branch and prod branch, especially after the first release into production.

I always tend to name those two branch after the current release I am building (test_1.0 and prod_1.0, or test_2.3 and prod_2.3, and so on).
That will limit the scope of the merges (in that they clearly are for a specific release, and I am sure I don't have in those branches some development mixed-in by mistake from another release).

If you want to have only one 'current dev' branch (master in your case), you must make sure to reset said master branch at the beginning of each new release.
A merge --theirs from prod_x.y to master can help, except merge --theirs doesn't exist. There are ways to simulate such a merge though.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks @VonC. That certainly seems like the fall-back position. It means that deployment now needs to know what version to deploy, rather than deploying the HEAD of the branch corresponding to the environment. But maybe that's going to be necessary. I can see advantages and disadvantages to keeping historical branches per-environment and per-version. Thanks! – Terrance Cohen Jan 18 '12 at 04:57
  • @TerranceCohen: "It means that deployment now needs to know what version to deploy, rather than deploying the `HEAD` of the branch corresponding to the environment.". No! They wouldn't deploy from the same repo. You can have *another* repo with a branch name "`prod`" to which the dev/integration team would push whatever `prod_x.y` branch has been validated. – VonC Jan 18 '12 at 05:06
  • I see, so development goes from master -> test_x.y -> test -> prod_x.y -> prod? And bugfixes go from test_x.y -> master. Does that preclude hot-fixes to prod? We have a small team, and I do most of the integration (to free-up the others to develop unencumbered), so I'm loathe to add too many steps to the process... – Terrance Cohen Jan 18 '12 at 05:17
  • @TerranceCohen: "Does that preclude hot-fixes to prod?" No it does not. You have a dedicated prod repo for that: in it, you can have a dedicated `hotfix` branch for said hot fixes. You can also have a dedicated "`retrofit`" branch for hotfixes you want to report back to your `dev_x.y` and `integration_x.y` branches of your original repo: you would cherry-pick what you need from `hotfix` to `retrofit` in the prod repo, and then you would *`pull prodrepo retrofit`* and merge `retrofit` to whatever `dev_x.y` and `integration_x.y` branch you want those hotfixes to be reported back in. – VonC Jan 18 '12 at 06:38