Git tags as an alternative to --no-ff in gitflow

Question

In https://nvie.com/posts/a-successful-git-branching-model/, Driessen suggests using the --no-ff flag to make the history of commits for the dev branch clear. This is an easy flag for individuals on a multi-person team to forget to add, and it also has the disadvantage of adding extra commits to the history (commits which may not be obviously identical in the git log output). As an alternative, I'd like to propose adding a tag of the form dev_TIMESTAMP whenever we move the dev branch pointer to a new commit (and maybe using git hooks to automate this, though I have no experience with them). Does this make sense? What problems would I run into? What could be done to overcome those problems?

Answer 1

The main purpose of the --no-ff flag is to:

[avoid] losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

(from the blog post you linked to in your question)

If keeping the historical information about feature branches is undesirable, then consider a squash-merge instead: git merge feature --squash

This gives you one clean commit for each feature branch, and then this question is moot. The --no-ff option is only useful if you want the history of the feature branch preserved. It sounds like this is just unnecessary clutter for your team. Don't feel like you need to use it. "A successful git branching model" is often cited and used, but it is an idea. Use what makes sense for your team, and discard the things that do not.

Tags are meant to be little more than significant bookmarks in the history of your repository. Typically releases are tagged, not every merge to a branch. 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.

Answer 2

tl;dr: there are 3 advantages of using --no-ff in Git Flow. Your suggestion of tagging every merge into develop basically achieves one of those advantages, but doesn't really address the other two.

Details:

The 3 advantages of using --no-ff are:

1. 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 tagging strategy could achieve this goal without information loss.
2. 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".
3. Git has a built-in feature for looking at historical changes to a branch, in the form of git log --first-parent. This enables you to easily compare the state of the changes to a branch, which in Git Flow would normally be each of the merge commits. This is an extremely useful view to have available. In your case that view wouldn't provide much value and you'd have to manually compare the "merge tag" in question with the previous "merge tag".

Ultimately I think this comes down to personal taste. It appears your motivation is to avoid

the disadvantage of adding extra commits to the history

Yet, you'd be replacing those merge commits with at least as many tags. (Note you potentially could be adding more tags than the number of commits you'd save.) I agree with the statement in Greg Bughgardt's answer that mentions you can do it but it would be kind of odd, compared to using merge commits to represent the same thing.

Side Note: Oftentimes when people argue against Git Flow's --no-ff to create merge commits, they do so because it adds (in their opinion, unneeded) complexity to the visual graph. They then may proceed to show an example of a Git Flow graph with many merge commits from feature branches that started from older merge bases, and then compare that to a straight line graph. But that is not a fair comparison because the straight line graph only works if you rebase your feature branches first. If you also rebase your feature branches in Git Flow you don't get a complex looking graph at all; instead you end up with a "semi-linear" graph with clean looking bubbles.

Answer 3

It seems to me that you should be tracking your development releases, by release, not by merge.

In which case, how you do or don't track various merges, or even if a full feature gets merged or not, becomes unimportant; because, you roll back to a release, not a commit.