very true. As a noob github user I find my commits to be very "ugly". Git encourages you to write a short descriptive sentence of what you did. For example "added validation checks to users class".
Well the way I code is to jump around all over the place and make little updates here and there. The commit messages end up appearing on files that have absolutely nothing to do with the commit. It's a constant reminder of how to be more structured and orderly. And also to value your time better, since you want to package up and send the damned commit already, you just have to get it done.
Actually, one of the benefits of Git over, say, Subversion, is that it's much easier to hack away on multiple things, and then arrange a series of sensible, self-contained commits from your messy working directory.
It's not necessarily a great way to work at all times, but it's a handy facility to have. Personally I use it most in the early, somewhat experimental stages of a new feature or project, when I find it useful to mentally separate experimental hacking with organised committing.
For most things, though, I try to focus on one thing at a time, and here Git's quick-'n'-easy branching and merging helps out. Whenever I start something new, even if it's just fixing a minor bug, I'll create a new branch just for that work, often naming it after the ticket number in our issue tracking system. Then your being in that branch is a constant reminder of what you're supposed to be working on.
Well the way I code is to jump around all over the place and make little updates here and there. The commit messages end up appearing on files that have absolutely nothing to do with the commit. It's a constant reminder of how to be more structured and orderly. And also to value your time better, since you want to package up and send the damned commit already, you just have to get it done.
Works for me!