Let me preface this by saying that it's not urgent to implement this, but I think we should discuss it and keep it in mind. Also note that none of this is set in stone, as there are many ways to use git. (Read: I might be totally wrong about this.)
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
git branching strategy
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: git branching strategy
Hi!
This sounds like some major merging pain, and overhead for creating branches for each fix or issue... and it would mean that I'd have to cherry-pick each feature before releasing and going through each and every fix, and then possibly resolve conflicts between different branches, if they touch similar area of code.
If someone wants to take over maintaining the release process, I'm willing to give that up to other hands that could do this. But for me, this would be too complicating. I notice I have only little time left, and I'd rather like to put this time into actual fixes, features or support rather than meta-work like release-maintaining.
The approach sounds very interesting though, I can clearly see benefits in this, especially for larger teams and client/project work... do you have an example of a running git repository where this is employed for some longer period of time, and works well to learn from as an example?
Regards,
Garvin
This sounds like some major merging pain, and overhead for creating branches for each fix or issue... and it would mean that I'd have to cherry-pick each feature before releasing and going through each and every fix, and then possibly resolve conflicts between different branches, if they touch similar area of code.
If someone wants to take over maintaining the release process, I'm willing to give that up to other hands that could do this. But for me, this would be too complicating. I notice I have only little time left, and I'd rather like to put this time into actual fixes, features or support rather than meta-work like release-maintaining.
The approach sounds very interesting though, I can clearly see benefits in this, especially for larger teams and client/project work... do you have an example of a running git repository where this is employed for some longer period of time, and works well to learn from as an example?
Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
Re: git branching strategy
I don't see why this should be more painful in terms of merging? I think a painful merge will be the one required to get to 2.0. Small branches for issues and features would probably be less painful since there's simply less files to be merged, hence less possibilities for merge conflicts …?garvinhicking wrote:This sounds like some major merging pain
Creating branches is extremely cheap and easy in git. The hard part would be to keep branches in sync since we'd have to set up remote branches and everyone would have to use local tracking branches.garvinhicking wrote:and overhead for creating branches for each fix or issue
Something I hadn't considered: this whole process would actually require a review process for merging branches, and I think that's the part of it we can't provide.
I don't think so. Every feature or issue branch would only focus on a very small, well, feature or issue, which would be merged into master rather quickly after finishing it in order to avoid larger conflicts. git is surprisingly good at resolving those. It would, however, be problematic for larger features like the new backend.garvinhicking wrote:and it would mean that I'd have to cherry-pick each feature before releasing and going through each and every fix, and then possibly resolve conflicts between different branches, if they touch similar area of code.
To me, this is the ultimate deal-breaker. I don't want to impose further work on you, and I don't think anyone could handle release management better than you, so if this does not work for you, it's perfectly fine to keep it the way it is now.garvinhicking wrote:But for me, this would be too complicating.
Sadly, it's not a public repository, so I'm not at liberty or even able to share it. Also, the “works well” part could be discussed for this particular project …garvinhicking wrote:do you have an example of a running git repository where this is employed for some longer period of time, and works well to learn from as an example?
YL
Re: git branching strategy
I do remember to have seen something like this, but I can't remember where...
I agree with Garvin, this sounds way too much for us few... if we ever have so much more devs and pull requests for different versions, we can rethink this though.
[half-baked: ... Personally, I like having my "brain repository" to still remember what has changed. If I ever loose that having to trust git algorithms only, to know what has happened and needs to get merged up and down and everywhere, I currently feel like loosing control, which makes me feel unsafe with it...]
I don't think we'll have something like the 2.0 branch furthermore, after the "merge" back to master. Then master ist trunk and we will only have to backport issues to released branches, if there is a need.
I agree with Garvin, this sounds way too much for us few... if we ever have so much more devs and pull requests for different versions, we can rethink this though.
[half-baked: ... Personally, I like having my "brain repository" to still remember what has changed. If I ever loose that having to trust git algorithms only, to know what has happened and needs to get merged up and down and everywhere, I currently feel like loosing control, which makes me feel unsafe with it...]
Not really. It wouldn't even need a merge, since we could just copy include/, (default/ and 2k11/admin/) into master and that would be it.yellowled wrote:I'm a bit concerned merging the 2.0 branch will be really complicated
I don't think we'll have something like the 2.0 branch furthermore, after the "merge" back to master. Then master ist trunk and we will only have to backport issues to released branches, if there is a need.
Regards,
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: git branching strategy
That might be true as of now [insert scepticism here], but I don't think it will still be possible after changes to the backend JS. But let's cross that bridge when we come to it.Timbalu wrote:It wouldn't even need a merge, since we could just copy include/, (default/ and 2k11/admin/) into master and that would be it.
That might as well be true, and it might very well be the better strategy for our team.Timbalu wrote:I don't think we'll have something like the 2.0 branch furthermore, after the "merge" back to master. Then master ist trunk and we will only have to backport issues to released branches, if there is a need.
YL
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: git branching strategy
Hi!
Well, we could also go the other route - simply move ALL from the 2.0 branch into trunk. I think there should be little to none additions to the 'trunk' branch that are not contained in 2.0 already?
Regards,
Garvin
Well, we could also go the other route - simply move ALL from the 2.0 branch into trunk. I think there should be little to none additions to the 'trunk' branch that are not contained in 2.0 already?
Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
Re: git branching strategy
Uhm, I wouldn't be too optimistic about that.garvinhicking wrote:I think there should be little to none additions to the 'trunk' branch that are not contained in 2.0 already?
As of today, GitHub shows that 2.0 is “119 behind, 215 ahead”, and I assume that's in relation to master. Judging from the commit history, new backend development started in 12/2012, smartification of the backend maybe even earlier.
Since we haven't merged master into 2.0 since then, every change to master in that period of time would have to have been ported to 2.0. I'm not sure that has happened.
YL
Re: git branching strategy
I am! Those counted numbers do not tell you the real state, as they just are something like "shrinking" or "growing". My "brain repo" says, it is (say 'near' here, to not get bashed some day...) 100% ready to copy, even if copy may not be state of the art, since we would better like to merge the history (and have not even started to clean up).yellowled wrote:Uhm, I wouldn't be too optimistic about that.garvinhicking wrote:I think there should be little to none additions to the 'trunk' branch that are not contained in 2.0 already?
If you have a look at 'Compare' and then at 'Files Changed', you'll see I am right.
Regards,
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian