Git workflow

[Kriti Godey]

We need to decide on our permanent Git workflow for releases.

Options:

• git flow
  • This is our current workflow with our develop branch
  • Since we don’t do continuous delivery, this makes sense to me but I’m open to other options.
• GitLab release flow

Please respond with thoughts.

[Brent Moran]

The first option makes sense to me.

[Dominykas Mostauskis]

Strongly in favour of GitLab flow and against Git flow. Git flow is too complicated.

[Pavish Kumar Ramani Gopal]

I am okay with either of these workflows.

However, what we currently seem to be doing is somewhere between both, but close to the git flow.

We do not have release branches, we've been treating master as the release branch. As we have a planned release 0.1.1, do we intend to have a release branch now and use that as an intermediary or continue to use master?

For eg., I'm currently working on having consistent behaviour for access level precedence in frontend and backend, which is planned to be part of 0.1.1, do I base my branch off of develop or master, or a separate release branch 0.1.1?

[Mukesh Murali]

I would choose the git workflow based on our use case.

Git workflow - If we are planning to support multiple versions

Gitlab - if we are not planning to support multiple versions(LTS, latest, nightly).

My preference would be to use Git workflow for Mathesar considering that our roadmap is more focused on users self-hosting rather than SAAS.

[Kriti Godey]

Pavish said:

We do not have release branches, we've been treating master as the release branch. As we have a planned release 0.1.1, do we intend to have a release branch now and use that as an intermediary or continue to use master?

For eg., I'm currently working on having consistent behaviour for access level precedence in frontend and backend, which is planned to be part of 0.1.1, do I base my branch off of develop or master, or a separate release branch 0.1.1?

This is in keeping with git flow. Most of the time, you don't have a release branch. I'll quote the blog post:

The key moment to branch off a new release branch from develop is when develop (almost) reflects the desired state of the new release. At least all features that are targeted for the release-to-be-built must be merged in to develop at this point in time. All features targeted at future releases may not—they must wait until after the release branch is branched off.

So we would make a release branch for 0.1.1 when all the issues in the 0.1.1 milestone have been fixed and merged to develop. Then we make a short-lived release branch to test and merge to master after testing. Release is a frozen version of develop.

---

It seems like we have a consensus building towards git flow. Dom, please make a longer argument for your position if you strongly disagree; I don't know what to make of "too complicated".

[Dominykas Mostauskis]

I'd like to hear your opinion too, Kriti.

General git flow cons:

- git flow is inflexible, it doesn't take into consideration team needs and always has the same set of branches; correct me if I'm wrong;

- it's bad for upstream-first bug fixing, git flow dictates that you merge hotfixes to the release branch directly and then do another merge into upstream (the develop branch); if you forget, the bugfix might stay downstream too long;

- GitLab flow is a natural next step after our previous flow (github flow, though we never referred to it explicitly, I believe); it's easier for us and for new contributors to grok.

I'm not seeing the advantage of using develop and hotfix branches in our use case. What's production (aka master) in our case? Demo? I don't think demo is worth it. If we're mostly doing releases and and occasional demo update, let's just do the gitlab flow with feature/bugfix branches, release branches, master branch and demo branch. I don't see any reason to also use develop and hotfix branches.

If someone disagrees, maybe they can make a case for git flow.

[Kriti Godey]

If we used Git flow, the master branch would only be updated when we make a release. This allows master to be stable at all times. I think there’s value in having a single stable branch.

For example, imagine a scenario where we’re building a large feature and have 3 of 6 PRs related to that feature merged in. Then someone reports a critical bug, which we want to quickly fix and make a release.

If we were merging all new development into master, we’d have to create a new branch off of the last release tag and cherry pick and whatnot to just fix the one bug and do a release. Otherwise, if we branched off of master, we’d be merging incomplete work in (or we’d have a larger burden on individual PRs to be complete in themselves, which would incentivize large PRs rather than small and iterative ones, which I hope I don’t need to enumerate the disadvantages of). If we have a develop branch, then we could just make a hotfix branch off master, fix the bug, and make the release.

if you forget, the bugfix might stay downstream too long;

This is a good concern, but there’s an easy fix – automation.

Decision

In the spirit of making decisions quickly, we should go with git flow and set up the master --> develop automerge automation. The majority of the team (who expressed an opinon) is already in favor, and if Dom or anyone else has further concerns, please feel free to DM me.

[Kriti Godey]

Issue for automation: https://github.com/centerofci/mathesar/issues/2664

[Rajat Vijay]

The first option and decision make sense to me.