[daniellarusso]

One of the repos I interact with, the team rebases all their local branch commits to master.

It is very difficult to read the commit history and get a sense of anything except Jira issue codes.

One needs to look at the individual files and read the code to understand what the commit was for.

[nerdponx]

This is why the best Git workflows IMO involve rebasing and squashing the branch down to a couple of well-defined "logical commits", then merging that (with --no-ff of course) into master/main/trunk.

This forces individual programmers to think somewhat carefully about leaving a sensible commit history behind.

[jacoblambda]

I think that's a consequence of rebasing. If you just merge instead, you can use the branching/merging to get a sense of complete features/changes.

[nerdponx]

Right, I think there's a bit of subtlety lost here. "Squash and merge to trunk" is very different from "rebase on every pull on a feature branch" which is very different from "rebase and fixup/squash before merging to trunk" etc.

On a feature branch, whether you constantly rebase against master or merge from master probably should depend on the nature of the feature branch and what exactly has been happening on master. And it ultimately doesn't matter that much.

In my experience, as long as branches are ultimately merged to master with --no-ff, you can almost always recover a sensible commit history, and you should almost always end up with a sensible, tidy master to base new branches off of. If you rebase with squash/fixup on the feature branch before merging, all the better, because then you get nice "meaningful" commits on the feature branch. But even if that doesn't happen and the feature branch is a mess, at least you could write a meaningful merge commit message.

Maybe things get hairy with huge teams or huge projects that could necessitate a different workflow. But most developers are not working on projects like that.