I feel it’s a balance. Each operation has a purpose.
Rebasing makes sense when you are working in a feature branch together with other people so you rebase the branch before you finally merge it into the main branch, instead of polluting the history with a hard to follow mess of sub branches for each person. Or when you yourself ended up needing to rewrite (or squash) some commits to clean up / reorganize related changes for the same feature. Or when you already committed something locally without realizing you were not on sync with the latest version of a remote branch you are working on.
Squashing with git merge--squash is also very situational… ideally you wouldn’t need it if your commits are not messy/tiny/redundant enough that combining them together makes it better.
![[Julia Evans] Combining Branches](https://programming.dev/pictrs/image/0fe7c7bd-b762-453f-bac7-ed2e34d44ba0.png){kind=link}
I feel it’s a balance. Each operation has a purpose.
Rebasing makes sense when you are working in a feature branch together with other people so you rebase the branch before you finally merge it into the main branch, instead of polluting the history with a hard to follow mess of sub branches for each person. Or when you yourself ended up needing to rewrite (or squash) some commits to clean up / reorganize related changes for the same feature. Or when you already committed something locally without realizing you were not on sync with the latest version of a remote branch you are working on.
Squashing with
git merge --squashis also very situational… ideally you wouldn’t need it if your commits are not messy/tiny/redundant enough that combining them together makes it better.