I’m confused. Is the workflow to rebase branches and squash merge into main? Because that’s what I do at work and it works quite well. You get atomic PR merges

I’m confused. Is the workflow to rebase branches and squash merge into main? Because that’s what I do at work and it works quite well. You get atomic PR merges so reverts are easy and you get the clean history for a PR so people can in theory review commit by commit. Although if you want to use merge commits in your own branch, I don’t care because it all gets squashed. I don’t fully get using rebase to merge PRs cause then it’s exposing the commits of the PR, when in fact the PR should be considered atomic code changes. But I suppose for workflows where PRs are not considered atomic code changes, rebasing could make sense. Really, what this boils down to is a confusion between commits as a save point and commits as an atomic code change. With my aforementioned process, commits inside a PR are save points, I.e. I need to just save my code before leaving work, while commits on main are atomic code changes (and therefore should correspond to a single pull request). In the rebase-everything approach all commits are atomic code changes, which I find a little too obsessive since you need to make sure your code is always working when you commit or rewrite your history so that is true.