Post #1813070

2026-04-30 13:08 UTC

Rebasing is not dangerous. You can always go back if something is not to your liking. You don’t rebase shared history, you use rebases to craft a clean, quality commit history for your own branches before merging. If everyone does this, then squashing is unnecessary, because garbage commits don’t exist. It is the far superior way of doing things if you actually care about having good commits. Keeping a quality history rather than squashing also makes many other git tools much better, such as git blame, git revert, git bisect, and so on.

Replies (2)

@mcv@lemmy.zip 2026-04-30 14:27

Rebasing is dangerous if you rebase shared history. If you rebase a local branch, you have to be aware of how much of that local branch you may already have shared. On top of that, if you’ve got a lot of commits you’re rebasing in a merge conflict that can become extremely repetitive. So ideally, you only rebase single commits that you haven’t pushed yet. As long as you do that: always pull main and rebase on top of that before you push single commits, rebasing is fine. But the more you deviate from that, the riskier it becomes.

Open ##1813207
@Miaou@jlai.lu 2026-04-30 22:22

That doesn’t make sense. There’s a world between “garbage commit” and “fancy new feature” and most of it is irrelevant to anything. I don’t want git bisect to make me check if “run clang-format” broke anything. I don’t want to revert a feature but leave in unit tests that will fail (or worse, the opposite). I don’t care when git blame tells me “rename X to Y”, I want to see the context that motivated this change. Squashed commits are atomic, built and tested. Anything in between is whatever reviewers let slip in. It’s easier to check a MR description is well written than 5 commit messages (that might get rebased without you noticing)

Open ##1827342