2

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?

1

3 Answers 3

4

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.

5
  • I'm not sure if keeping historical information about feature branches is desirable or not. I suspect most of the time we don't need or want it, but sometimes we might, so I'm reluctant to get rid of it. I guess my hope is that, by adding tags to the dev branch it'd be relatively easy to filter out feature branch noise when I don't need it. +1 to this answer, though. The last point about surprising people is especially good. Maybe the next question would be "surprising and confusing" or "surprising but not confusing". Oct 6, 2021 at 14:56
  • @BenjaminBerman: The problem might be feature branches that live too long and have too many commits. Especially if a feature branch as a lot of useless "merge 'develop' into 'feature'" commits, which just adds noise to the history. The problem might exist in the feature branches instead. Oct 6, 2021 at 17:41
  • I'm thinking that, at least the way we currently develop, to get shorter feature branches we need to either use something like github forks + squashing, or we need to rely on something other than our VCS to backup our work. Oct 6, 2021 at 18:50
  • @BenjaminBerman: You could also try trunk-based development in conjunction with feature toggles, but this only works if you have good automated test coverage. Oct 6, 2021 at 19:08
  • @BenjaminBerman The standard way to "filter out feature branch noise" is with a --first-parent view. I just added an answer which touches on that. I also like the last paragraph of this answer and IMHO it's enough reason in itself to avoid tagging every merge. Regarding "If keeping the historical information about feature branches is undesirable"... I'm thinking "undesirable" might be "isn't useful in your case", which is true when devs have 30 commits of "code review comments" and "fix something"; squash is the answer to that. Also, maybe the SCM PR tool retains the branch history as well.
    – TTT
    Oct 29, 2021 at 20:14
1

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.

-2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.