I think ultimately it's a matter of scale. Sometimes it can be useful to look into the details of the development of a single feature, but in a large project, that rarely happens. I'm not a fan of squashing, but for large projects, it helps to keep your history manageable.

[–] expr@piefed.social 8 points 1 day ago (6 children)

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.

[–] Miaou@jlai.lu 1 points 1 day ago (2 children)

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)

[–] trem@lemmy.blahaj.zone 1 points 1 day ago

You're right that there is a risk, that rebasing introduces compile errors or even subtle breakages. The thing is, version control works best, if you keep the number of different versions to a minimum. That means merging back as soon as possible. And rebases simultaneously help with that, but also definitely work best when doing that.

There may be reasons why you cannot merge back quickly, typically organizational reasons why your devs can't establish close-knit communication to avoid conflicts that way, or just not enough automation in testing. In that case, merges may be the right choice.
But I will always encourage folks to merge back as soon as possible, and if you can bring down the lifetime of feature branches (or ideally eliminate them entirely), then rebases are unlikely to introduces unintended changes and speed you up quite a bit.

load more comments (1 replies)

load more comments (4 replies)