What is the benefit of having merge-commit if we follow a process of squashing commits before mergin-CodePudding

Say we have a repo R with develop as the branch where all folks merge their feature branches. Now if I am developing a feature which has 3 commits a,b,c and before merging into develop, our company follows a process of squashing those commits into single commit say a, then is there any benefit of having a separate merge-commit in develop branch when we actually merge, as it is creating 2 separate commits for a single feature.

CodePudding user response：

If you could do a fast forward merge, and if all of your merges contain exactly one commit, then there really isn't a benefit to using --no-ff (as proposed by Git Flow) to force a merge commit, since there is no information gained, with the exception of the author, date, and text of the merge commit message. In theory, any additional information in the merge commit could be appended to the single commit message details if desired (e.g. "... PR completed by John Doe on 2021-09-28 13:30:01).

Extrapolating on this, there's an argument to be made that you could use a fast-forward merge anytime there is exactly 1 commit, and then force a merge commit anytime there is more than 1 commit. This however might make the --first-parent view more varied, as it would potentially be mixing developer written messages with merge commit messages, (though perhaps that could be adjusted by your SCM tool). I work in a repo that uses Git Flow where the majority of PRs have just one commit, but I still prefer the --no-ff for all merges, just for consistency of knowing all the PR information is always in the merge commit.

My personal preference is not to force a squash in the first place, since separate commits have value (if the developers take the time to make them valuable). However, if we were doing a squash, I think I might lean towards a completely linear graph over forcing a tiny merge bubble every time, if the PR info could be added to the details of the commit message.

Side Note: if you're using Git Flow, I might still prefer to force merge commits when merging protected branches back and forth (release into main, main into develop, etc) so you can know when those branches were updated. Particularly the main branch, which may represent releases into production.

CodePudding user response：

What does company say about the process ? Why not ask them directly ?

One benefit is that your merge-commit might be urgently reverted with git-revert if something goes wrong. or even just :

git reset --hard HEAD~1

In that case your commit is gone, with all your work. In the meantime you might be asked to make a fix of things that caused the problem that initiated the revert. So you would simply checkout your feature branch, make the fix and merge again. So, having separate commits, just makes it a bit cleaner and gives a bit more possibilities to play around with git when things get nasty.

As the squash commit itself, it might be done for the sake of simpler review and has nothing to do with the final merge-commit.

Maintaining git on daily bases at my company, I can say the more information is in git the easier it is to deal with some hard situations that happen on regular basis.