Add a git trailer to a merge commit to indicate if it came from a feature, a bugfix or a hotfix

[shaedrich]

For example:

Merge branch 'hotfix/1.2.3' into 'main'

Finish Hotfix 1.2.3

Type: hotfix

GitLab, for example, uses the CHANGELOG trailer for this purpose. (also see keepachangelog.com)

Or maybe more like Conventional Commits

[ChrisJStone]

Thank you for point this out. I was unaware of git interpret-trailers I will look further into this.

[shaedrich]

My pleasure. Looking forward to your opinion on this :)

[ChrisJStone]

I've been looking deeper into adding trailers to various messages that are "auto generated" I think a lot of them would fall under a "plugin" for adding platform specific functionality. I did see a couple "trailers" on the now defunct GitWiki that may be use full in general.

In regards to adding a trailer to a merge commit message, either all merge commits made would have to be of the squash type or --no-ff has to be enforced so --no-commit could be used to stop the merge and enter in a commit message.

Currently when only a single commit is made on a branch the default behavior "At least with feature branches" is to perform a fast-forward merge. From the discussions I've read the general consensus is that with single commit merges the extra merge commit would add little if any value to the commit history.

With a squashed merge workflow trailers could be easily added however this would break with "established convention" as per the original blog post when merging branches. A similar argument has been used when stating reasons to not fast-foward single commits.

Maybe it's time to re-evaluate the state of the branching model and what the "conventions" should be. Even Vincent Dressen has suggested a simpler model like GitHubFlow in his Note of reflection on A successful Git branching model

[shaedrich]

Yeah, the extension should be able to be used with different "implementations" into a teams workflow. One thing, that I think, works but could be improved on, is that git flow technically is already flexible by having arguments to its commands but it would be worth to have that configured beforehand during the initialization and set to GitHubFlow or the like so that you can run the commands ideally without almost any arguments and rely on the knowledge that the whole teams uses git flow consistent with its team's guidelines.

Is there, by chance a list of different git flow implementations like GitHubFlow besides GitLabFlow?

[ChrisJStone]

I have not see a list per say. What I've usually seen is more of a comparison between the different works flows Git Flow vs GitLabFlow vs Trunk Based development. I have not yet really done a deep dive on these, they are saved n my raindrop.io to read later, but in looking for other information I came across Enhanced Git Flow Explained and OneFlow – a Git branching model and workflow The post about one flow is from a series of articles about working with git.