If your feature branches have independently working commits, go ahead and branch. Most people’s feature branches are developer diaries instead of potentially releasable products. Merging them would make everyone’s lives worse, so of course they get squashed.
Rebases are a bit weird since they mostly help during bisecting but still require production-ready commits in feature branches.
Who is "everyone", in "it would make everyone's lives worse"? Worse in what way, exactly? What quantifiable metric are you using to judge "worse"?
I agree that some feature branches can be developer diaries, but I'm not sure why throwing away the diary is a good thing, and why the repo should only contain "releasable products". Sounds like an aesthetic preference rather than something concrete.
> still require production-ready commits in feature branches.
I make a point of requiring that anyway. You gotta learn to build incrementally, repeatedly landing squashed mega-commits into main is just a recipe for future pain. To level up as a software developer, learn to create incremental work. git rebase -i is your friend.
I’ve had my share of rebase -i and I’ve gotten fed up with it, though GitHub plays no small part in that. Years ago when I worked with gerrit it made more sense. I just stopped caring because of the tool.
If your feature branches have independently working commits, go ahead and branch. Most people’s feature branches are developer diaries instead of potentially releasable products. Merging them would make everyone’s lives worse, so of course they get squashed.
Rebases are a bit weird since they mostly help during bisecting but still require production-ready commits in feature branches.