Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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. –  Sangdol 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. –  Sangdol Aug 10 '11 at 0:25
show 1 more comment

5 Answers

up vote 27 down vote accepted

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

share|improve this answer
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
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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