As someone who also uses Git exclusively from the command line, without any TUI wrappers, I agree with a lot of this. The parts about commits being revertable, bisectable and in general _atomic_ are very important, and IME the only correct way of using version control.
One exception: conventional commits. I find them very useful even on solo projects, since a) they make it easy to spot the type of change at a glance, and b) they force me to keep commits atomic. That is, if I'm ever compelled to make a commit that is both a `fix` and a `refactor`, usually out of laziness :), sticking to a conventional commit message is a quick way to determine what needs to be split into a different commit. These conventions really shine when used in a team, as they improve communication and keep the history tidy (along with all other benefits of atomic commits), but so far I haven't had the luck to work on teams that agree to adopt them. Using these commits to generate changelogs would be wrong, as changelogs should almost never be autogenerated (though these days maybe AI does an acceptable job at it), but they're still useful to keep track of the number of fixes, features, etc. that were produced in a release.
And a tip: in addition to plain shell and Git aliases, I've found scmpuff[1] and delta[2] to be invaluable in a Git CLI workflow.
One exception: conventional commits. I find them very useful even on solo projects, since a) they make it easy to spot the type of change at a glance, and b) they force me to keep commits atomic. That is, if I'm ever compelled to make a commit that is both a `fix` and a `refactor`, usually out of laziness :), sticking to a conventional commit message is a quick way to determine what needs to be split into a different commit. These conventions really shine when used in a team, as they improve communication and keep the history tidy (along with all other benefits of atomic commits), but so far I haven't had the luck to work on teams that agree to adopt them. Using these commits to generate changelogs would be wrong, as changelogs should almost never be autogenerated (though these days maybe AI does an acceptable job at it), but they're still useful to keep track of the number of fixes, features, etc. that were produced in a release.
And a tip: in addition to plain shell and Git aliases, I've found scmpuff[1] and delta[2] to be invaluable in a Git CLI workflow.
[1]: https://mroth.github.io/scmpuff/
[2]: https://github.com/dandavison/delta