This "stable" branch would be very close to the "master" branch in the standard Git Flow structure. The only difference I can see is that it would only be fast-forwarded instead of merged.

I think release tags and branches may both be justified, depending on the project.

A release branch would mark the start of the release process for a certain version and contain any changes on the way to the actual release. When the release is done, the commit containing the sources for this version gets a tag with this version number and if there is a stable branch, it's fast-forwarded to this commit at the same time.

Is that close to what you are doing?

The difficult part is merging those changes back into the development branch (since merging always has the potential to break things).

I think this could be separated from the release process, which means the release tag will always be on the last commit of the release branch. Any commit on the release branch might be merged into the development branch and in most cases the last one (containing all changes up to the release point) should be merged sooner or later to make sure you don't loose anything (but of course there might be exceptions to this rule).

In our projects we have the luxury of never working on several releases in parallel.

This means we can use the development branch for all changes that need to be done for the next release and creating a release doesn't need more than a tag on this branch.

In this scenario I only see a small benefit in an additional stable branch.

I don't understand why tags are considered more "heavy-weight" than branches.

From my point of view, branches are for tracking a process over several commits, while tags mark one exact state of the repo, which makes them the logical choice to mark the souce code for a certain version number.

Please feel free to rename this subject to attract more participants. It might help to get more input from other developers to see their needs.

My current conclusion is that it seems very hard to accommodate all possible work flows, while each of them might make sense inside the constraints of their project environment.

For us, the main branch is "where the latest released version lives", tagged with the version number of that release.

This makes perfect sense for our use cases. Most projects are company-internal software where it's important that the latest release is used for all installations (eg. product test stands).

The standard structure of developing inside feature branches and merging those to the develop branch fits very nicely for us. From a source code perspective, the develop branch is usually the latest version, that does not contain work in progress.

Release branches are very short-lived in most cases. From my point of view, we wouldn't really need those, because we don't have extended release periods - that's done in the develop branch since we never work on several releases in parallel.

My main reason for creating release branches is that this workflow is very easy to use in SmartGit. Most of the times, the next step after creating a release branch is "Finish Release" to merge it into main + develop (so the release branch is never actually pushed to the server).

Our CI workflow reacts to the version tag to create a release build as well as a release on our internal Gitlab server.

This could work without a main branch, too (since we are using the tag creation as the trigger rather than the commit to the main branch). Once again, the Git Flow standard workflow in SmartGit is very convenient to use, which is the main reason for doing it this way.

We don't use hotfixes or bugfixes at all.

So I think our minimal workflow would actually be closer to the Git Flow Light than standard:

One main branch that plays the roles of both main and develop branches.

Feature branches are branched from main and merged back to it.

Releases are created directly from the main branch into itself, which means nothing more than creating a version tag.

The only thing the standard window is missing for this is a "create release" button. But this wouldn't be more than an additional button to open the "add tag" dialog and I don't see why we shouldn't do this with a right click.

Thank you very much for making me think more deeply about our process!

I was referencing the Git Flow features that can be found in the log window.

The options that can be configured and used there are features, releases, hotfixes and support branches (if you chose "Full" mode).

In our team we are only using features and releases and we have configured CI work flows that rely on the way SmartGit handles the branches and tags when creating a release.

If the features in the standard window are not exactly Git-Flow: What are they?

Are they the same as we see in the log window?

If not: Pleas use icons that look significantly different and make it very clear to the users that this is not the same feature.

Your question about differentiation between develop and main sounds as if you never heard about the Git Flow concept.

This is what I am talking about: https://nvie.com/posts/a-successful-git-branching-model/

That is exactly what SmartGit provides in the log window (plus some extra options).

Recent versions of git include this as well with a slightly different implementation. But I like the way it's done by SmartGit better (SmartGit offers an option to chose which of the two should be used - that's great!).

Not having separate main and development branches sounds like "Light" mode. This is fine for some projects, but the "Full" mode provides better options to manage release builds.

Sorry to say so, but your questions sound as if the people working on the standard window were not really aware of the functionality SmartGit already provides in its other windows, which might lead to inconsistent behaviour and duplication of efforts. To me this looks like a communication issue inside the development team.