Standard Window: support releases for the Feature Flow (similar to Git Flow Releases)

Thank you for your Feedback! We will look into this!

In the Standard window, we have implemented Features but this is not exactly Git-Flow. Supporting real Git-Flow side-by-side isn't feasible. Can you please explain in more detail what exactly you are missing in the Standard window?

Hotfixes? - What exactly is your workflow?

Differentiation between develop and main? - Why exactly do you need both?

...

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.

I have implemented Git-Flow in the Log window and the new "Standard Flow" in the Standard window, so you can assume I know what I'm talking about and that there is a purpose to my questions.

As mentioned previously, the Standard Flow is derived from Git-Flow. Try it out: simulate concurrent changes to your main or feature branch in the remote repository, then hit Integrate and see what checks are made and which Git operations are triggered. It's fair to say that the Standard window doesn't employ Git-Flow and we essentially want to maintain it that way. However, that doesn't mean we won't improve the Standard Flow, which is optimized for a Git GUI (unlike Git-Flow). This is precisely the focus of my questions:

> 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.

How exactly are you using both branches? The develop branch is pretty obvious, but is this separate, single main branch really the perfect solution? And all this tightly defined release-branch logic... why not simply fork a release branch (or many, if there are multiple releases of your product) and merge them (possibly cascading)? What about all the tags which become created? Also, consider the "support" branches and "bugfix" branches which have been added after the initial version. Do we really have to distinguish between "hotfixes" and "bugfixes"?

As a side note, in his "Note of reflection" in the referenced Blog post, Vincent himself suggests re-evaluating his approach for your specific situation and considering GitHub Flow instead.

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!

Thanks for the details, and it's good to hear we're getting closer. Just a few more notes:

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

You could also have an additional "stable" branch that represents the latest "deployed" state. This branch would simply fast-forward on develop but would not have any own commits (i.e. a real fork). This more or less a light-weight tracking, release tags would be more heavy-weight (see below).

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

If releases contain bug fixes themselves, these could be release branches instead (that's what we have).

Now I'm wondering whether we should rename the subject to "Standard Window: support releases." It's not entirely clear what this would do, but at least it may attract others to vote and comment here.

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.

> 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?

Exactly.

> 

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).

That's also exactly what we are doing.

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

I have the following in mind: "main" represents the latest released/deployed version. And once you want to make a new deployment you simply move main a couple of commits forward. At certain milestones, when you make your deployment more public, you may in addition to that create a release-tag.

> 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.

I have done so now.

Thanks again for your detailed ideas!