Git commit style: All changed files at once or one at a time?

Question

I am saving my work at night with a single commit for many files. I wonder if it would be better to commit for each file but this seems like a lot more work.

I have no problem with the way things are now but I plan to put my code on GitHub and I want it to be easy to understand.

I'm wondering what the rest of you who use git are doing. Also if you could kind of spell it out for me. I'm new to Git and I've been using TortoiseGit and gitk in Windows.

Answer 1

When to commit and what to commit is an art, and there are no black-and-white rules. That being said, there are habits that are easier to understand than others.

In general, I think you should optimize your commits for understandability - if you go back and read the diff for the commit, can you figure out what you accomplished in the changes?

If you want to be more specific, here's a long list of what I think are do's and don'ts:

• Don't commit after every single little change - every line changed, every file changed, etc.
• Don't work for an entire day and make one gigantic commit at the end of the day.
• Do separate out commits for different features - e.g. developing feature foo vs. fixing bug #2.
• Do a separate commit for moving/renaming files, because it's easier for Git to track this way.
• Do think about optimizing for revertability: If you dislike a change that you made, is it easy to undo it even after new changes have been piled on top?

Answer 2

"Easy to understand" means also:

• commits representing not just "checkpoint" (like they would if you committed after each file modification), but a coherent state of the code
• easy to git bisect (ie each commit should represent a change in a task, which compiles and add an evolution or a new feature, and not a "checkpoint commit", which would make the git bisect fails way too soon)

See "understanding the Git workflow" for more: you need to differentiate:

• private branches (that you never push), where you can commit basically at any time, and
• public branches (that you will push on GitHub), which needs to be clean-up and have meaningful commits.

So pay attention to the "fast-forward" merge that Git uses by default: don't forget to clean-up the history of branches you are about to merge that way into public branches.