5

So I'm quite new to Git and DVCS in general, and I've been reading everywhere that, at least on private branches, "it is always good to commit all the time". The question is: why? I am using SourceTree (Git client with graphical interface) and I find it much easier to (stage and then) commit my code once everything is working and I'm done, since I can still see my diffs in SourceTree before committing.

So what's the reason for committing more often? And how often should I do it?

modellero
  • 213
  • 2
  • 6
  • 14
  • 1
    To minimize the risk of conflicts between two concurrent changes and to have small commit grains you can more easily reorder and move around. – chmike Feb 25 '15 at 09:43
  • 1
    Well, you can commit locally "all the time" and only push when everything is working. – vikingsteve Feb 25 '15 at 09:45
  • possible duplicate of [DVCS - How often and when to commit changes](http://stackoverflow.com/questions/1480723/dvcs-how-often-and-when-to-commit-changes) – jub0bs Feb 25 '15 at 09:47
  • @chmike "To minimize the risk of conflicts between two concurrent changes"?. I don't get this. If I'm the only one working on a project, then there's no risk of conflicts, and if there are more people working on a project, the "confilct" wouldn't appear UNTIL I PUSH my commits, so what's the point of making many commits, if they will still be pushed at the same time when I'm done? – modellero Feb 25 '15 at 11:06
  • @vikingsteve That's exactly my question: Why would I commit all the time? – modellero Feb 25 '15 at 11:11
  • @Jubobs The other question is "How often", and I know that the answer is "very often", so my question is: Why? – modellero Feb 25 '15 at 11:12
  • @modellero If you are working alone, then you don't have concurrent changes and no risk of conflicts except by branches. What will affect you is the granularity of the changes in a commit. With git you can manipulate commits, move, copy or delete them. A commit is then an atomic change to the code. You want then to have commits with small changes to keep the maximum control on the change history. It's not the frequency of the commit that is important. It's what changes they contain and how much control you want to keep on the change history. I call this the granularity of changes. – chmike Feb 25 '15 at 13:46
  • Another example of a great question, with factual answers already in evidence, closed because ... why? "Why should I backup often?" Is that "opinion based" too? There may be concrete factual reasons for more than one answer, leading to opinion on which answer to choose, but the answers are still concrete and useful. – NeilG Apr 12 '21 at 23:50

2 Answers2

3

The idea behind committing often is to sort of create a live feed for yourself of changes. I think it's also a safeguard in case you make a small change in your code, and something goes wrong and you lose the version you were working on. That way it reduces the necessity for human memory, and relies on (redundant) computer storage instead.

Josh Beam
  • 19,292
  • 3
  • 45
  • 68
  • ok, so I have to commit often to have a more granular history of my changes, which would allow me to revert these changes in case something goes wrong. Did I get it right? Also, let's suppose the following case: I change a file in a big project, which causes errors in 10 other files that need to be changed as well. Should I commit after changing every file? Or should I do it after all the files have been changed (and free of errors)? – modellero Feb 25 '15 at 15:20
  • @modellero, personally, in the example you gave, I would commit after every change you made, even if the files still have errors. This is the same principle as debugging, where you would comment out each line until you find a bug. In other, you want to create as few "gaps" as possible. If you make 100 changes and commit once, and then find an error 3 days later.... well crap, which of those 100 changes caused the error? It's easier to sort through 100 individual commits to narrow down a point of failure than it is to go through one giant commit and find the needle in the haystack. – Josh Beam Feb 25 '15 at 15:57
  • @modellero, instead of saying "it is always good to commit all the time", it might be better to say, "it is better to commit too much than not enough". – Josh Beam Feb 25 '15 at 15:59
0

It is good to commit often for the same reason that it is good to make frequent backups. Commit when you have code you don’t want to lose, say after a successful make check.

Unlike most centralized version-control systems such as Subversion or CVS, you can go back and polish up messy history after your code is ready but before you push or share it with the world, so git doesn’t pressure you to “get it right the first time.”

Greg Bacon
  • 134,834
  • 32
  • 188
  • 245