The workflow is branch from shared history, rebase your branch as many times as necessary during development to craft a quality history, then merge back.

I rebase dozens of times a day and have never had a single issue with it.

If you're bothered by repetitive merge conflicts (which, in my experience, are quite rare if you're doing things correctly), that's what git rerere is for.

Rebasing is for crafting a quality history of your own commits (or getting your branch up to date with the trunk). Merging is for integrating your commits with the shared history.

[–] mcv@lemmy.zip 1 points 10 hours ago (1 children)

This is what I'm saying: it depends on your workflow.

[–] expr@piefed.social 1 points 5 hours ago

And I"m saying that doing with merges (and squashing) what should be done with rebases is bad. You can do it that way, but you shouldn't, because it makes for worse history and less usable git tools.