If for some reason you need to revert the merge (either shortly after or later), it's easier to revert a single merge commit than it is to revert X number of commits between the two "merge tags".Your tagging strategy could achieve this goal without information loss. The primary purpose, and the one you are offering an alternative for, is when there is more than 1 commit getting merged into develop (or another shared branch) you can see that they were merged in together.
Your suggestion of tagging every merge into develop basically achieves one of those advantages, but doesn't really address the other two.
Tl dr: there are 3 advantages of using -no-ff in Git Flow. That isn't to say you cannot tag every major merge into develop, but it would be surprising to people familiar with most git branching strategies. Typically releases are tagged, not every merge to a branch. Tags are meant to be little more than significant bookmarks in the history of your repository. Use what makes sense for your team, and discard the things that do not. "A successful git branching model" is often cited and used, but it is an idea. It sounds like this is just unnecessary clutter for your team. The -no-ff option is only useful if you want the history of the feature branch preserved. This gives you one clean commit for each feature branch, and then this question is moot. If keeping the historical information about feature branches is undesirable, then consider a squash-merge instead: git merge feature -squash (from the blog post you linked to in your question) losing information about the historical existence of a feature branch and groups together all commits that together added the feature. The main purpose of the -no-ff flag is to:
0 kommentar(er)
