You should commit waaaay, waaaay more often than once a day. Every small piece of logically fitting together change should go into one commit, so the git history tells a story, it's easy to revert and easy to understand how the code get to the current state and why. you also should write elaborate commit messages to all commit.

I commit dozens of times a day, make half a dozen branches, pick commits between them, and generally (ab)use git as a normal part of my workflow. I will generally push one or two of those commits in the end, typically a Frankenstein creation comprised of all that has come before.

There are so many ways to approach a problem in any given codebase, and I rarely know which will be the best without experimenting. Having tools that reduce the burden of experimentation and branching is incredibly powerful.

I commit dozens of times a day with zero aliases, and it never really gets in my way. If you’re comfortable with git, leveraging it can almost certainly improve your productivity—if you can rebase, splitting a branch into two branches is a fairly trivial task. Even if all you do is commit often, you can do things like aggressively refactor without worrying that merging will be a costly endeavor—just rewind to the last manageable commit if you stick your neck out too far.

On the day to day work, git use is simple; it’s with large major version upgrades, refactors, merging many branches together, and spiking/research where the more advanced features really shine.

To each his own, but I'd say committing once a day. That's unless I'm wrong in thinking that doing so means your commits are quite big and could be broken up into smaller, more manageable changes.

Personally, I like it when `git diff` displays only one or at most three screenfuls of changes that haven't been committed.

Not fixing several tickets a day.