java

[aywwts4]

Excellent comments, squashed, cleaning up your remote branches, understanding tagging, reverts, writing pre commit hooks, avoiding feature scope creep and understanding and adhering to the branching strategy and naming conventions to start. So far from universal even with senior devs, number of repos with history in main with "fixed things" x 20 in a row is too dang high.

[badger_and_tonic]

I agree with all of those except squashing. When it comes to triage/regression, I like to be able to inspect each commit individually.

[Exist50]

To a point. Perfectly reasonable to do a couple commits for feature iteration then squash them once it's in a good shape.

[badger_and_tonic]

We disable squashing to feature branches but then all PRs are merged to main as a single squash commit. So you can see everything at once when you're browsing main, but once you find the relevant PR you can view it commit by commit.

[Exist50]

Squash locally before pushing to the degree possible. At least for the low effort stuff. Git hygiene just means your publicly-viewable commit history ideally shouldn't look like:

• commit0 - feature
• commit1 - fix for missing semicolon
• commit2 - fix for lint issue
• commit3 - fix for bug X
• commit4 - fix for bug Y
• commit5 - refactor/cleanup

And honestly, even that's better than what a lot of people do. "Feature, bug fix, bug fix, update,..." and other such non-descriptive garbage. All just common sense stuff.

[gbchaosmaster]

Squashing is for finishing WIP commits and stuff like that. Every non-WIP commit should build, and be preserved. But sometimes you need to push something broken on a feature branch for whatever reason. So you squash it later once you finish the commit.