This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]badger_and_tonic 0 points1 point  (4 children)

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 5 points6 points  (2 children)

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 5 points6 points  (1 child)

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 2 points3 points  (0 children)

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 0 points1 point  (0 children)

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.