Standard branch naming

[smolijar]

omgf uses dev instead of develop and release instead of release-* for individual minor releases, compared to the original article.

I understand that handling individual releases is a demanding feature, but renaming develop, seems like purposeless confusion, I suggest renaming to avoid inconsistency.

[jiripavelka]

It's been a while. The whole thing has been reimplemented. Also, there is a 'Note of reflection' at the linked article, that has not been published by the time of your post. Any shifts in your opinion?

1. Branch names

Default names don't follow the article for practical reasons. E.g. nowadays 'main' is more common than 'master'. However if your repository uses names from the article, the tool will adapt to it.

This will work for as long as you hit some of the branches from individual sets. Currently:

• production: main master production prod live
• staging: staging release rc preprod pre-production release-candidate prerelease
• development: dev devel develop next

You may as well define your own branches of any value using environmental variables. See variables starting with 'FLOW_'.

2. Release branches

This may still be an issue. The production branch ('main' by default) is now accommodated with 'main-${major}' branches for each major version. The point is probably obvious -- as to:

• attach CI/CD to a specific major production branch and
• hotfix major production branches individually.

It should not be a biggie to make the release branch work similarly. But I'm missing the point here. What is the practical application for this generally or in your case? Feel free to give me some thoughts.

Thank you for your interest!

[smolijar]

Also, there is a 'Note of reflection' at the linked article, that has not been published by the time of your post. Any shifts in your opinion?

Yes, I care less about the naming nuances. Even more so with the main/master initiative. I must admit I don't care that much about omgf either 💔

This will work for as long as you hit some of the branches from individual sets

Seems like a way to go 👏

This may still be an issue. The production branch ('main' by default) is now accommodated with 'main-${major}' branches for each major version. The point is probably obvious -- as to:

• attach CI/CD to a specific major production branch and
• hotfix major production branches individually.

I think this approach misses/misinterprets the gist git-flow pattern. If you want to "attach CI/CD branch" and so support long-lived environment branches, check out GitLab flow, it addresses this very issue. In git-flow, you'd rather fix this alternatively:

• deployment branch is reset on tags on master (not merged as regular branch)
• hotfixes are merged to master branch and have tags attached (see hotfix flow with git-flow), rather than using long-lived master sub-branches

It should not be a biggie to make the release branch work similarly. But I'm missing the point here. What is the practical application for this generally or in your case? Feel free to give me some thoughts.

The reasons are the hotfixes, as you described with the master sub-branches. The idea is not wrong, but it just needlessly shifted from release branches to master branch/es.

The concept of git-flow is confusing when applied to apps (e.g. with nighly, staging and production env deployment branches), but makes more sense when applied to distributed software, which needs to support several versions -- there is development branch (nightly, current), master branch (for stable code with tags marking versions) and release branches (untouched unless hotfixes needs to be applied, kept only for supported versions). Project like TypeScript for example is a good candidate for such robust flow.

I must say your reply is a tad late, sorry I lost bit of interest after the years. It is hilarious though you took the time to come back, for this I thank you I did my best not to leave you hanging! Best of luck with the project and take care!🤗