Principle developer tip: rewrite history to make yourself seem smarter.

Soft reset the whole branch and commit a series of atomic and semantic patches (eg separating code, test, and refactor changes) that tell a clean narrative of the changeset to reviewers, future blamers.

Senior developer tip: Squash ~~the evidence~~ management

"Nah I was in the network driver section"

I'd have a field day with that. Max line length 70 or 75, excessively verbose function and variable names, triple the normal amount of comments, extra whitespace wherever possible, tab width 8, etc. The possibilities are endless for that metric.

When metrics become targets they fail to be metrics any more

Campbell's law goes brrrrr.

You can always water it down. The point is to have some order in the commits. Otherwise is just messy.

You can always adapt to your how repo. But yeah, that's the point. If you can trust people to make changes on a repo then you should be able to trust them in using some kind of commit structure.

Generic names are probably used in order to crate a familiar, easy to remember, structurized commit format.

I do push often as I'm often switching between two devices. And I do make draft PR so I got an easy git diff that I can live reference with

You are not alone. This is the work git was built for.

There is a bit of benefit if you have code reviewed so separate commits are easier to review instaed of one -900 +1278 commit.

Squashing

The s "squash" command is where we see the true utility of rebase. Squash allows you to specify which commits you want to merge into the previous commits. This is what enables a "clean history." During rebase playback, Git will execute the specified rebase command for each commit. In the case of squash commits, Git will open your configured text editor and prompt to combine the specified commit messages. This entire process can be visualized as follows:

Note that the commits modified with a rebase command have a different ID than either of the original commits. Commits marked with pick will have a new ID if the previous commits have been rewritten.

https://www.atlassian.com/git/tutorials/rewriting-history

You can also amend for a softer approach, which works better if you don't push to remote after every commit.

The git commit --amend command is a convenient way to modify the most recent commit. It lets you combine staged changes with the previous commit instead of creating an entirely new commit. It can also be used to simply edit the previous commit message without changing its snapshot. But, amending does not just alter the most recent commit, it replaces it entirely, meaning the amended commit will be a new entity with its own ref. To Git, it will look like a brand new commit, which is visualized with an asterisk (*) in the diagram below.

You can keep amending commits and creating more chunky and meaningful ones in an incremental way. Think of it as converting baby steps into an adult step.