My biggest issue with rebasing is squashing commits can render git bisect useless for determining which particular change a bug was introduced. If you have 50 commits on a feature branch squashed down to 1, all I know is that your branch broke it, not how.

I don't need git bisect that often, but when I do, it's a life-saver.

That said, I totally endorse squashing small commits to generate a coherent commit - e.g., commit A has broken code in it, commit B fixes that, definitely squash those into C so that if I check out that commit when bug hunting, it compiles.

This is an interesting post, because it squares with my personal small team experience with rebase which goes against what I perceive as the common opinion. We were having some serious merge conflict issues and I explored rebase as a tool to avoid them, and in the process we definitely had some lost history. Really once the branch reaches any appreciable level of complexity, I think it's best to leave it as is and start up a new branch if you really need to redirect the PR.

My team use merge in the past. And we found out in git, merge commit may contains it own changeset. Our code suddenly missing, and when we check on both history, commit look fine. Lo and behold, file deletion happen on merge commit. It bite us hard and I never trust merge commit again. Its very hard to read on complex feature merge.

My team now only use rebase, clean up commit using squash, and fix conflict before landing commit on master branch are kind of natural using rebase. Lead developer also have easier time to check file changes.

It makes sense to me that merge commits would "contain changes" (i.e. that a merge commit's tree would have content that is not in either parent's tree), otherwise how else would you represent the result of resolving merge conflicts?