Commit whole project or commit files?

Question

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?

possible duplicate of [How often should I/do you make commits?](http://programmers.stackexchange.com/questions/74764/how-often-should-i-do-you-make-commits) — Michael K, Aug 09 '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 09 '11 at 15:20
@Mike Yes, I also think I missed that. What I'm using is SVN. — Sanghyun Lee, Aug 09 '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 09 '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 00:25

score 29 · Accepted Answer · answered Aug 09 '11 at 14:23

29

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

answered Aug 09 '11 at 14:23

quant_dev

5,117
2
22
26

2

Heh, so many points for stating the obvious ;-) – quant_dev Aug 09 '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 09 '11 at 16:56

score 10 · Answer 2 · answered Aug 09 '11 at 14:26

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:

Create a topic branch to work on my feature, bugfix, etc.
Make lots of little commits on this branch, whatever I want really
Use Git's interactive rebase tool to clean up my branch's history into logical units of work
Merge (or rebase) this back into master and push to our shared repository

The page you shared does not exist. – Menai Ala Eddine - Aladdin Aug 30 '23 at 21:37 — Menai Ala Eddine - Aladdin, Aug 30 '23 at 21:37

score 5 · Answer 3 · answered Aug 09 '11 at 14:31

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.

score 4 · Answer 4 · answered Aug 09 '11 at 14:37

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

answered Aug 09 '11 at 14:37

AProgrammer

10,404
1
30
45

score 2 · Answer 5 · answered Aug 09 '11 at 14:39

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.

Commit whole project or commit files?

5 Answers5