7

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?

Improve this question
6
  • 1
    possible duplicate of How often should I/do you make commits?
    – Michael K
    Aug 9, 2011 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, 2011 at 15:20
  • @Mike Yes, I also think I missed that. What I'm using is SVN.
    – Sanghyun Lee
    Aug 9, 2011 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, 2011 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, 2011 at 0:25

5 Answers 5

Reset to default
29

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

Improve this answer
2
  • 2
    Heh, so many points for stating the obvious ;-)
    – quant_dev
    Aug 9, 2011 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, 2011 at 16:56
10

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

Improve this answer
1
5

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.

Improve this answer
4

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

Improve this answer
2

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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