Looking at other people's code I vastly prefer a feature branch with a summary name of the feature "new-checkout-flow" or whatever and then the commits as they where without squashing/rebasing. Mine tend to have quite a few commits cycling through:
- Stub in [classes/models/etc] for checkout flow
- Add basic test coverage
- Fix my API for easier testing
- Decouple foo from bar in new flow
- New checkout flow mostly tested
- New flow UI cleanup and add comments
- Fix nasty [N+1/O(n^2)/etc] performance bug in new flow
- New flow feedback from acceptance testing
- New flow ready to merge
- [And often enough/honestly] "WIP to share with..." or just
"WIP" for work in progress, "Fixing bug in" or whatever reality there was.
Going back at `git blame` etc 5 years later i can see from the branch names linked to the commit the why it was added and from the commit messages I can see something of at what point in the mental processing of designing/implementing that exact line made it it.
On the other side of the coin I hate looking at git blame to find a bunch of now irrelevant stuff, like fixes to code that were only ever in your branch. I don’t generally care about the discoveries you made along the way (at least not in commit form) unless I’m doing the review for it to go in the main branch, and even then it’s more of a curiosity than anything particularly relevant to software quality.
I wanted "squash merge" to work for me to handle this. Full history in the feature branch for detailed git blaming and a single 1000-line merge commit in main with "New Checkout Flow" but i never fully groked getting it to work when you are merging upstream branches into you feature... You end up taking credit/blame for the upstream commits on main and I feel like you could overwrite the real history of that.
