4

I've been reading up on Adam Dymitruk's git workflow, and it all makes good sense.

The one thing I can't find any discussion on is fixing bugs in old releases. Picture the 'master' branch with tags at 7.0, 7.1, 7.2, 7.3, 7.4, 7.4.1, 7.4.2, 7.8, 8.2, and the most current 8.3

In production for a specific client is version 7.2, and a bug is found and must be fixed.

Fixing it in 8.3.1 and moving the client from 7.2 to 8.3.1 is unacceptable to the client.

So, is there a recommended workflow for this?

I could create a fork of the master branch from the 7.2 tag, call this branch release-7.2.x Then, treat 'release-7.2.x' like one treats the master branch - create from the baseline a feature branch (72bug), fix the bug, etc, and ultimately merge the feature branch into 'release-7.2.x', do a build, make a 7.2.1 tag, and put it into production. 'release-7.2.x' would then live on forever, as does the master, so that any more fixes to 7.2.x can be made on release-7.2.x.

Of course, one doesn't want to lose the fix from 7.2 for the current work, so one could create a feature branch from the current master baseline (8.3) and merge the bug branch (72bug) into this feature branch. This feature branch would be treated like any other feature for the current release cycle/sprint. Thus, at the end of the cycle the newest baseline (8.4) would contain the bug fix.

How have others using Adam's workflow addressed this situation?

Nevik Rehnel
  • 49,633
  • 6
  • 60
  • 50
N5NX
  • 135
  • 2
  • 4

1 Answers1

0

If you can't migrate the client to the current version, then there's really no getting around starting a new branch from the 7.2 tag.

Rather than fixing the bug on a 72bug branch and merging it into both the release-7.2.x branch and a current feature branch, however, I would suggest fixing the bug on a current feature branch, and then using git cherry-pick to backport the fix to the release-7.2.x branch. That will help keep your history clean, so that your current development doesn't suddenly seem to depend on an older version simply because of the needs of one client.

Wally Altman
  • 3,535
  • 3
  • 25
  • 33
  • Great, thanks! Sadly, we've found clients often have policies that restrict migration from older versions to newer versions, or the number of upgrades per calendar year. So, we have to live with this, like it nor not :-) Thanks again. – N5NX Jun 07 '13 at 17:17