Re-define branching model

[renestalder]

Currently, master is deploying to production. @retoinniger now changed the default branch to release/1.1 for the moment, so that it's less of a risk to accidentally make changes on master. Also, master is now protected, so only pull requests can make changes to it and at least one review is enforced for a merge to take place.

For the next release, we should establish a branching default. Common patterns are develop/master/feature branches (Git flow), master/production/feature branches (GitLab flow).

[Aerzas]

To lessen the risk to have unwanted code deployed to production, we should probably set it up on a tag push, either iterative release tags or simply a production tag. Since the current developments are quite straightforward and not really dependents on each others we could image a very simple workflow.

Let's imagine this branching model:

• master is the branch for validated features, any feature starts from it and is merged back to it once approved.
• a feature/[issue_id]-[short_description] branch is created when a new issue/feature is tackled.
• a release-[major].[minor].[patch] tag is created on the prod branch when we want to emit a release.
• a production tag is pushed on the prod branch when we want to deploy a release on production (the same for other environments if we have).
• hotfixes could processed like normal features

[Aerzas]

Quickly checking Netlify capacities, it seems that it's not possible to trigger deployments on tags (example discussion: mochajs/mocha#3206). The way the service reacts seems more close to the GitLab flow where branches are named per environments.

Let's imagine this variant:

• master is the production branch.
• develop is the branch for validated features, any feature starts from it and is merged back to it once approved.
• a feature/[issue_id]-[short_description] branch is created when a new issue/feature is tackled.
• hotfixes could processed like normal features
• a deployment would be triggered by a merge of develop into master (are tags still need in that context ?)

[renestalder]

in your approach, this would make develop the standard branch. I always find this a bit confusing as develop needs to be the standard branch on GitHub so pull request target it automatically. At the same time, I want to be able to simply come to the repository and download the last stable state. With the develop branch being standard, this is not possible. I have to switch branches first. The download functionality would target the develop branch otherwise.

I would consider the following pattern:

• production: reflects the state on the live site.
• master: de facto development branch as it's the common default branch in public repositories. Everything ever merged lands on master and can in parallel be cherry-picked to production if it's a hotfix (and not a squash).
• Feature branches, as you say, but without strict naming, e.g. feature/whatsoever. Because I don't assume a pull request needs a ticket, so the ticket number is obsolete. A pull request can also come out of the blue and contain all information and discussions.

[ralf57]

@renestalder I am fine with your suggestion. I would have preferred to use tags (and drop the production branch altogether) but AFAIK Netlify prefers to work with git branches so let's stick to the production and master branch as default

[ralf57]

Is there anything else to be done?

[renestalder]

I think the way It currently is with simply just deploying master automatically does the job IMHO.

[ralf57]

Closing since there's nothing else to be done.