Over the past few weeks, I've been freelancing in a team which uses git. I still wouldn't call myself a git jedi, but I've learned some things, and I think we should think about how we use git for s9y development. I'm not sure everyone uses git the way I'm about to describe it, but I know I did at some point.
We use branches for versioning. Currently, we have
* master, which is the current dev version (1.7-rc4 at the moment)
* 2.0, which is for the new backend
* 1.6, which holds the soon-to-be deprecated version 1.6
Actually, I think we should use tags for versioning and branches for features or issues. That means our repo structure could look like this:
* master (branch) – current “bleeding edge” state of development
* 1.7 (tag) – snapshot of the (yet to be released as of today) version 1.7
* issue_xx (branch) – branch to fix issue xx
* feature_yy (branch) – branch to implement feature yy
What's the difference? There would be no more version branches, versions would be denoted by tags. We would not have to (what at least I have been doing) backport or upport changes from (or in) master. This could also make merging branches easier (I'm a bit concerned merging the 2.0 branch will be really complicated) since it is likely to reduce merge conflicts caused by changes made to both master and branch(es).
However, there are caveats to this approach, probably even more than I can see right now.
1. Feature branches which are being developed over a long period of time (like the new backend) will deviate from master a lot, so we'd need to merge master into the feature branch time and time again to make sure the feature branch still works properly with a current master. This could result in a complicated merge.
2. I'm not sure how to properly handle short-term bug fixes with this approach. As of now, we'd add those fixes to the 1.6 branch, tag a new version 1.6.x there and release that, correct? With this approach, we could only do bugfix releases as a snapshot of master, unless there's a way to add changes to a tagged version. Or we could keep a branch called “minor-releases” which always holds a copy of the most recent major release.
Yes, this sounds complicated now, but I think it will have two benefits: less confusion about what to commit where and less painful merging of branches. Of course I'm aware that the current system works for us and that this is a no-go if it imposes more work for Garvin in terms of preparing releases, but I still wanted to put it up for discussion.
YL