13

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.

Nayuki
  • 17,911
  • 6
  • 53
  • 80
loop
  • 3,460
  • 5
  • 34
  • 57

2 Answers2

20

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?
Nayuki
  • 17,911
  • 6
  • 53
  • 80
  • 2
    +1 especially for the notion of version control as a mechanism for recording so that you can undo individual changes. – tripleee Sep 15 '11 at 04:22
  • Thanks. My bias towards separating logical changes is inspired by the ease of use of `git revert` and `git cherry-pick`, and also by [Darcs](http://en.wikipedia.org/wiki/DARCS) which is change-oriented rather than snapshot-oriented. – Nayuki Sep 15 '11 at 04:33
  • "Don't commit after every single little change", see [Should I commit cosmetic changes?](https://stackoverflow.com/questions/2049129/should-i-commit-cosmetic-changes) – MAChitgarha Sep 14 '18 at 09:34
12

"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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    +1 The `git bisect` point is particularly important, I think - when your history is made up of the smallest commits that represent changes that make sense together, bug bisection is a joy... – Mark Longair Sep 15 '11 at 06:06
  • 1
    @test: quote from the article "Understanding the Git workflow", checkpoint commits represent "frequent commits that back up your work but captures the code in an unstable state". The issue with a checkpoint commit isn't that it include one file or many file, but that it doesn't represents a meaningful change and (worse) that it might not even compile. And that spells trouble for the `git bisect`. – VonC Sep 16 '11 at 03:50