[Closed] Branching model

[bijington]

I wanted to kick off a discussion around which branching model we want to start using in this repository.

For the record I believe the Xamarin Community Toolkit uses GitFlow.

For some initial reading this post seems to give a pretty decent overview of the 2 main models GitFlow vs GitHubFlow

For the record quite a bit of the following was taken from https://gitversion.net/docs/learn/branching-strategies/overview

GitHub Flow

GitHubFlow is a simple and powerful branching strategy. It is what GitHub uses and the branching strategy most open source projects use.

• Mainline development on main. main should be protected here.
• Work on feature branches, merge into main via a pull request.
• Works well for continuous delivery.
• Does not have a way to manage/maintain old releases.
• Only allows working on a single release at a time.

Would it be wise/possible to create a branch based off a release tag should a hot fix be required? Perhaps this might not be needed.

Git Flow

GitFlow is a more complex and complete branching strategy. It also gives much more control over when features and code is released.

• Development on develop branch.
• main only contains released code.
• Supports maintaining old releases (do we want to be supporting old releases and if so how far back?)
• Supports development on multiple releases at one time.

Choosing a branching strategy

There are a few reasons you would pick GitFlow over GitHubFlow, they are:

• You need to support multiple major versions at the same time.
• You need to work on multiple releases at the same time.

For example a new feature which will go in the next major version, while bug fixes/smaller features are still going into the current release

Summary

I wonder if it would be enough to go with GitHubFlow in the initial stages of development given:

1. We are yet to have an official release
2. The work appears much more structured with the proposal workflow
3. It is simpler in terms of development/contributions as there is a single branch to aim for

I guess my worry comes down to how we hot fix releases as I suspect there will be a need to do this.

Your opinion

Please anyone/everyone share your input on this 😄

[pictos]

I would say that we should keep the GithubFlow, with one branch. I don't think that we need to care about older versions and services releases, which will add too much effort on our side since we need to keep a lot of branches and maybe share commits between them.

If we don't want a preview package, which I think we don't need, we can keep the main and develop branches, where the main branch will be just for releases.

I guess my worry comes down to how we hotfix releases as I suspect there will be a need to do this.

And when we need to provide a hotfix, we do it by merging the fix on develop and merging it to main right after.

[brminnick]

For Hot Fixes, we can also branch from the Release Tag, which is what we do already for MauiCompat.

In this case, we'd merge the bug fix into the main branch, then we'd cherry pick that commit onto the hot fix branch (branched from the Release) and then create a new Release tag for that hot fix branch.

[pictos]

That works for me

[brminnick]

Notes January 2022 Standup:

• GitHub flow is simpler (Brandon + Gerald mentioned it is their preference)
  • Our Proposal workflow, Build Pipelines & Unit Tests should help ensure that bugs don't make it into main
• Xamarin Community Toolkit uses Git flow
• What is easiest + most frictionless for community contributions?

[bijington]

So long as our default branch is where the PRs need to be targeted then I think it should be relatively frictionless. Of course with GitHub flow there is only main so it reduces that extra little bit of complexity for both contributors and maintainers.

I vote for GitHub flow also 👍

[pictos]

GitHub flow 4 the win 🚀

[VladislavAntonyuk]

+1 for GitHub flow. I think it's better suitable for us (until we support only 1 version in production)

[brminnick]

That's 5 Unanimous Votes for GitHub Flow, then!

[CliffAgius]

Closed as completed