10

What is the general rule? When do you commit?

TIMEX
  • 259,804
  • 351
  • 777
  • 1,080
  • 22
    Never. Programmer should commit to git. – ChssPly76 Nov 11 '09 at 04:15
  • 2
    Possible Dupes: http://stackoverflow.com/questions/107264 http://stackoverflow.com/questions/1709676/ – Christian C. Salvadó Nov 11 '09 at 04:19
  • This is a good question if you're just learning to use source control. +1. – David Nov 11 '09 at 04:19
  • 8
    @ChssPly76 - Spoken like a true git. – si618 Nov 11 '09 at 04:24
  • 4
    @ChssPly76 I don't get all this noise about Git. Sure, it's awesome (and I do like it) for open source projects and it solves a lot of problems of centralized VCS (easy creation of branches, disconnected work, etc). But, please, explain me what DVCS solves for the average organizations IT group. In my experience, in such contexts, developers are always connected, don't branch because it annoys them (right or wrong, that's not the question), don't like or just don't know how to use the command line, don't like change, etc. So what would be the point of using Git for them? I'm very curious... – Pascal Thivent Nov 11 '09 at 05:59
  • 2
    Even if one does not like a tool for any reason - this question can still be answered as it really a general question for any given tool. – Critical Skill Nov 11 '09 at 06:11
  • @Pascal - it was a joke based on the fact that OP said "commit to SVN" rather than "commit to source control". I've got nothing personal against SVN (CVS, Perforce, Git, what have you). – ChssPly76 Nov 11 '09 at 17:37

12 Answers12

22

Commit early and often. It minimizes conflict resolution steps when working in a team. But don't commit anything that breaks your build. Ideally, continuous integration notifies the team when the build breaks.

Asaph
  • 159,146
  • 25
  • 197
  • 199
19

I try to commit whenever I complete a 'piece' of work - as long as the code compiles, of course.

Blorgbeard
  • 101,031
  • 48
  • 228
  • 272
  • 10
    Or to say it a little differently, _before starting_ a new piece of work. +1 – Brian Moeskau Nov 11 '09 at 04:47
  • 2
    This makes perfect sense for svn (i.e. you don't want to commit broken code for others), which starkly highlights why you want to use distributed version control on your local environment, because that workflow is thrown out when you can make as many local commits as necessary to reach an end goal, instead of having to stretch for some place that is a polite state for a centralized repository. – Kzqai Nov 11 '09 at 05:19
10

This is covered (and covered well) in an older post on best practices.

SVN best-practices - working in a team

I'm recommending checking out this post because it covers a lot of good ideas, not just how often to commit.

Community
  • 1
  • 1
David
  • 72,686
  • 18
  • 132
  • 173
6

If working on trunk, I commit whenever I hit a milestone that won't impact my teammates. When working on a private branch, I commit whenever I hit a milestone I don't want to lose (I don't care if it even builds). For personal projects, I use mercurial and commit constantly. It all depends on what works for you and your team.

Stephen Newell
  • 7,330
  • 1
  • 24
  • 28
4

When using Test Driven Development, I check in every time I've written a new unit test and gotten it to pass.

  • Write test
  • Ensure that the test is failing (otherwise the test is not effective or not needed)
  • Write new code for this test
  • Confirm that all automated tests pass
  • Check In
  • Refactor your work so that any duplication you introduced isn't there anymore
  • Confirm that all of the automated tests still pass
  • Check In
  • Go to first step.
Andrew Shepherd
  • 44,254
  • 30
  • 139
  • 205
2

It really depends on the situation.

  • If you're working within your own branch or using git, fire away
  • If there is an automated build process or continuous integration, you'll want to submit granular improvements
  • If you're working concurrently with others on a branch, you'll want to submit when you have solid granular improvements, but on more of a 'milestone' basis.

Generally when I work it's in my own branch, so I follow 2 guidelines

  • Commit if something is "complete". This is often used loosely - it can be a function, a class, a page, something that is complete enough that it can stand on it's own
  • Commit if it's a "This works, but it's ugly" situation. Committing here acts as a fallback as I go back and revise my ugly fixes into something more elegant. Worse case, I go back to the working solution, however ugly.
jcelgin
  • 1,164
  • 11
  • 21
1

I commit whenever I've done a unit of work: fixed a bug, added a feature, improved efficiency, etcetera. But I try to avoid long periods of silence. The advice in Don't Go Dark is worth reading.

Seth
  • 5,596
  • 8
  • 42
  • 56
0

Commit when you have code you don't want to lose. That doesn't mean you commit to trunk, if you are developing in a team, you should avoid breaking things for others. How much code do you want to rework if your editor destroys the file? An hour or two?

dajobe
  • 4,938
  • 35
  • 41
0

svn requiring commits to a remote server makes it hard to commit as often as you should, so I recommend trying out mercurial or git so that you can make local commits at all the times you want to and then send those commits to svn (via git-svn, or hg-svn) after doing your own cleanup if you must use a centralized svn repository.

The very fact that you're asking about how often to do commits implies that the centralized nature of svn is getting in the way of your workflow to some extent. You'll be glad of the benefits of a local machine repository once you get past the learning curve.

Kzqai
  • 22,588
  • 25
  • 105
  • 137
0

Programmers that comes from thin/distributed VCS or have used it before will commit in small changes or by features because local commit is very cheap. Then they would push to central repo once they need to sync. But because commit is very expensive with SVN, programmers that is using SVN (usually) commit daily which sometimes the changeset can be in a really big chunk and the commits might need be related by features. This is bad habbit.

So I try to take that best practice from DVCS usage into SVN aswell. Therefore I would commit to SVN by features so it would be easier for me to rollback once there is a problem in the changes.

Joshua Partogi
  • 16,167
  • 14
  • 53
  • 75
  • Personally, I've never waited till the end of the day to commit a set of modifications related to a feature change. And it's the first time I read people commit only daily because commits are expensive... Can you elaborate? – Pascal Thivent Nov 11 '09 at 05:28
  • "Commit is very expensive with SVN" ... huh? I commit with svn all the time and it's not a problem. I *do* think that commits need to be made on logically-related chunks of code, but I expect I would think that no matter what system you were using. Otherwise, how could I read your log message, and easily get your fix for Bug A but not your update on Feature B? – Michael H. Nov 11 '09 at 05:46
  • 1
    Committing at the end of the day is a hassle if someone breaks the build just as he is going home. – mob Nov 11 '09 at 06:08
  • I dont know if there is any "expense" attached with committing into SVN. I think it is more often a question of how confident one is of one's code, how well tested it is. Since a commit makes it visible to the world and you may break a build - at times people hesitate to do so -- a mindblock which can be easily dissolved by healthy practices. – Critical Skill Nov 11 '09 at 06:16
  • The expense is the bandwidth. If you are working in an MNC and distributed team than you will feel the difference. That is the difference between local commit with DVCS and central commit with CVCS. – Joshua Partogi Nov 11 '09 at 06:25
  • Come on, subversion sends diff between a local file and the most recent revision locally available on commit, meaning not much use of bandwidth. Pushing your change with Git at the end of the day will eat as much bandwidth. And if bandwidth is that much an issue, start to save it by not surfing on the internet >:) – Pascal Thivent Nov 11 '09 at 08:58
  • Right. But with git I only push when I need to. Compare it if you have to commit 20 times a day with SVN, and 20 local commits with Git and 1 push a day. – Joshua Partogi Nov 11 '09 at 10:08
0

What I usually do if I need to add a new feature or fix a bug, is to create a branch from wherever I need to, do my work there, get it code reviewed and than merge it back in. You could even break down your branches folder for each user (may not make sense if you have a lot of users) that each developer would keep their changes in.

Casey
  • 12,070
  • 18
  • 71
  • 107
  • To answer the original question, this way I can commit as often as I would like without worrying about breaking anything else and still keeping my code backed up in the repository. – Casey Nov 13 '09 at 03:23
0

General rule:

  • after doing an atomic change that makes sense.

An atomic change: is a "logical unit" change, which you feel easy to write it in the commit's comment.

Makes sense: It includes safe to update - compiles and not break features - which has the logical change you are not afraid to say in the comment.

When do I commit: When I made some change as mentioned in general rule, and I try to do it more often.

Some more good practices can be found here: http://ducquoc.wordpress.com/2011/06/09/svn-best-practices/

j0k
  • 22,600
  • 28
  • 79
  • 90
Anonymous Coward
  • 11
  • 2