I used to commit files which I want to group. But one of my colleague said that committing whole working project is better than committing files. I think it makes sense but if I commit like that sometimes I have to commit several different works at once.

What is the best practice to commit?

  • 1
    possible duplicate of How often should I/do you make commits? – Michael K Aug 9 '11 at 14:38
  • The best answer for you is likely to depend on the type of version control system you're using: distributed system or not, for example. Can you tell us which system you use? – Mike Woodhouse Aug 9 '11 at 15:20
  • @Mike Yes, I also think I missed that. What I'm using is SVN. – Sanghyun Lee Aug 9 '11 at 15:23
  • The question seems ambiguous to me. What do you mean by "commit files which I want to group"? Do you mean that you're grouping them according to what issue/feature you are trying to add? – jprete Aug 9 '11 at 20:47
  • @Michael I already read that before ask this question but I couldn't find answer what I want. – Sanghyun Lee Aug 10 '11 at 0:25

Commit a single unit of work. Otherwise reverting the commit or remerging it elsewhere (different branch) will be painful.

  • 2
    Heh, so many points for stating the obvious ;-) – quant_dev Aug 9 '11 at 16:01
  • 1
    And keep each unit of work in it's own branch. Then you can commit, branch, merge, and rollback specific changes much easier. – CaffGeek Aug 9 '11 at 16:56

I usually use the commit early, commit often approach. This works better with a distributed system such as git. My basic workflow ends up being something like this:

  1. Create a topic branch to work on my feature, bugfix, etc.

  2. Make lots of little commits on this branch, whatever I want really

  3. Use Git's interactive rebase tool to clean up my branch's history into logical units of work

  4. Merge (or rebase) this back into master and push to our shared repository


Commiting files always poses the risk of checking in incomplete or untested code, so you need to be more careful. Nevertheless having individual commits for each unit of work is essential. So never commit the whole project unless all changes you made are related.


Do both. Commit your whole workspace but only related changes.

  • whole workspace so that you can test before commit;

  • only related changes so that it is easy to comment, merge, reference in a bug tracking system, ...


I like to commit related files together, or at the very least enough so that the project compiles when someone updates. Why? Depending on your version control tool, the entire project will be versioned as well. In Perforce, for instance, checkins are assigned a changelist number. These changelist numbers also serve as revision numbers for the entire directory. By checking in individual files, the code base will not always have a valid state at each revision. By checking in related files, I can go back to other revisions, not just for one file, but the entire project, and ensure that it's at a place where it at least compiles and hopefully runs correctly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.