Consider adopting a new git branching model

[lehnberg]

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.

Thought it could be worth discussing, in particular in lieu of our previous conversations and snafus based on our current approach?

[JeremyRubin]

I think that it's better in this case to have develop be the master branch. I also think you will want to be able to maintain release branches permanently in order to do backports

[lehnberg]

I think that it's better in this case to have develop be the master branch

@JeremyRubin by this, you mean that develop and master branches and their use cases in the above example are combined into a single branch named master? In your opinion, what are the benefits with this approach?

I also think you will want to be able to maintain release branches permanently in order to do backports

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. :)

[antiochp]

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.
It is primarily aimed at teams that work closely together (and I would argue less toward the OSS model).

I have personally introduced Gitflow to a variety of projects over the past few years.
I no longer use it for anything and regret the additional complexity introduced with this.

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 -
https://githubflow.github.io/

That being said - I am heavily biased toward a true "continuous deployment" approach.
And this obviously introduces some bias against a rigid "feature" and "release" branch strategy such as the one taken by Gitflow.

[lehnberg]

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:

For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it's use.

For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.

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?

[antiochp]

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 v1.0.3 -> v1.1.0 with weeks (or months) between releases.
But on the other hand we do have master which should always be deployable.

And I'd argue that that the latter is the model we should be prioritizing - that every merge to master is effectively a new release/deployment. Anybody can grab master and have a reasonable expectation that this is the "latest version" and that it works as expected.

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... 😀

[lehnberg]

Topic was discussed in the last governance meeting, where the meeting opted to stay with the current model, with an action point taken to document this better to make it easier for newcomers to understand and follow. Closing.