Linear GitFlow - branch development and release workflow

[eeberhard]

I want to propose a modified GitFlow workflow to keep our develop branch completely linear and make releases easier to deal with.

The regular GitFlow workflow has release branches that are created from development, then merged into main, and also merged into development. Hotfixes are created from main, then merged into main, and also merged into development.

My problem with this is that we will have multiple histories on development from the re-merging of release branches. Even worse, merging hotfixes stemming from main into development creates an upstream association, so that development cannot be said to be always ahead of main.

The adjusted workflow is similar, and illustrated in the sketch attached. The develop branch stays strictly linear. All feature, release and hotfix/bugfix branches stem from development. Feature branches are squashed and rebased onto develop through PRs. Release branches are merged into main, and then squashed and rebased onto develop.

The only consequential difference, apart from the rebasing strategy, is that no branches (including hotfixes) can ever be stemmed from main. I think we do not expect to have frequent releases, and releases are also not being automatically deployed (compared to a web development application). Therefore the rapidity of a hotfix release is not so crucial, and we can fix it in develop and release it from there instead.

Let me know what you think to this.

[domire8]

Why would the release branch have several commits after branching out from develop? For example to remove DualQuaternions? If the answer to that is yes, why would we want to squash and rebase that onto develop? Wouldn't that mean that we lose DualQuaternions on develop as well?

[eeberhard]

In my mind, the development branch is like a release candidate. We approve all features that go in there, meaning there shouldn't really be anything we don't want. The only thing right now is that we didn't start from a clean slate. So, if we say we don't want feature X in main, then I would argue that we don't want feature X in develop either.

The release branch can have several further commits that touch up documentation or fix / remove any remaining issues. It just can't introduce new features.

With the specific example, if we decide to remove DualQuaternion in the release branch, then that change should also apply to develop. DualQuaternion can be reintroduced as a feature when it's in a ready state. (It will be preserved in the history in any case)

[eeberhard]

Just to clarify this a bit further: if you want to have a development branch that contains features and code that is not intended to be released (so, that the development branch cannot be thought of as a "de facto" release candidate), then that means that each release is a standalone / dead-end branch that is not merged back anywhere. If main is intended to be up to date with the latest release, then this also implies forcefully updating main to the newest release head. This article explains that workflow quite well, and there's nothing wrong with it - it's actually quite nice - but my vote would still be to keep development as a semi-stable release candidate and to keep main as essentially a series of release snapshots at known states.

Keep in mind we can also separate in-development and release-ready code by using different build configurations. For example, if DEBUG, then include these experimental features, but if RELEASE, do not.

[buschbapti]

I like this last proposition of having debug and release configurations. Good job of thinking it through