Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider adopting a new git branching model #2779
As part of unrelated git reading, I came across this article describing a git branching model. Seemed fairly intuitive, and wasn't able to identify any immediate negatives with this approach.
@JeremyRubin by this, you mean that
I don’t think it would be an issue retaining certain release branches. Alternatively, is it possible to create backport branches on the fly from old release tags on master when needed? Or is that not a good idea?
Might also be worth discussing our general philosophy regarding backports - is it something we want to encourage? But that’s probably an entire issue on its own. :)
This is https://github.com/nvie/gitflow and my experience of working with this is it adds a significant amount of complexity for little (if any) benefit.
I have personally introduced Gitflow to a variety of projects over the past few years.
I would personally be strongly against using Gitflow for Grin - its overly complex and attempts to solve the problem the wrong way.
See here for a good explanation of why the internal github team itself does not follow Gitflow -
That being said - I am heavily biased toward a true "continuous deployment" approach.
Thanks for sharing @antiochp - git-flow adding unnecessary complexity is probably a valid criticism.
The github flow you linked to seems fairly similar to what we do today. The final two paragraphs of the conclusion section is interesting:
Which ones of the above are we? I prefer continuous deployment in general as well, but it doesn’t feel as though we are there today. It’s almost as we’re trying to be a bit of both here, which I am not sure is better than just picking a strategy and committing to it fully. Or am I wrong?
I'm torn because my previous experience of continuous deployment is not necessarily applicable to what we're doing here with Grin (but maybe it is if you look at it the right way).
On the one hand we may be doing long interval formal releases
And I'd argue that that the latter is the model we should be prioritizing - that every merge to
And the named versions, tagged and released as binaries are somewhat arbitrary snapshots of that over time.
I'd much prefer a formalized approach to backward compatibility alongside continuous deployment than formalizing the release process itself.
But I'm also aware this won't sit well with the Linux package manager types lurking around here...