> For that matter, why merge? Rebase it on top. It's so much cleaner. It's atomic and hermetic.

With an explicit merge, you keep two histories, yet mostly care about the "main" one. With rebase, you're effectively forgetting there ever was a separate history, and chose to rewrite the history when "effectively merging" (rebasing).

There's value in both, mostly seems to come down to human preference. As long as the people that will be working with it agrees, I personally don't care either way which one, granted it's consistently applied.

Rebasing is slower in practice to trunk based development and CI, while merging and squashing are moving farther away.

Squashed PR allow you to see a single commit, while rebased PRs show up as multiple. The squash has the defect that you can’t rebase PRs that were on top.

But a MERGE… is a single commit on Master, while keeping the detailed history!

- We just don’t use the merge because they are ugly,

- And they’re only ugly because the visualizers make them ugly.

It’s a tooling problem. The merge is the correct implementation. (and yet I use the rebase-fast-forward).