67

I've been reading Martin Fowler's note on Continuous Integration and he lists as a must "Everyone Commits To the Mainline Every Day".

I do not like to commit code unless the section I'm working on is complete and that in practice I commit my code every three days: one day to investigate/reproduce the task and make some preliminary changes, a second day to complete the changes, and a third day to write the tests and clean it up^ for submission. I would not feel comfortable submitting the code sooner.

Now, I pull changes from the repository and integrate them locally usually twice a day, but I do not commit that often unless I can carve out a smaller piece of work.

Question: is committing everyday such a good practice that I should change my workflow to accomodate it, or it is not that advisable?

Edit: I guess I should have clarified that I meant "commit" in the CVS meaning of it (aka "push") since that is likely what Fowler would have meant in 2006 when he wrote this.

^ The order is more arbitrary and depends on the task, my point was to illustrate the time span and activities, not the exact sequence.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Sled
  • 1,868
  • 2
  • 17
  • 24
  • 21
    You may commit your code if it compiles and performs some useful logic. Better to commit code in short cycles if you are working in a team environment. – Yusubov Jul 05 '12 at 20:35
  • 4
    Is Martin Fowler assuming a VCS that isn't distributed? – user16764 Jul 06 '12 at 00:22
  • 4
    Note the date on that article: May 1st, 2006. Git and Mercurial weren't even *begun* until April 2005, and my impression is that they really started getting traction in about 2008. I can't find any articles on Fowler's site that refer to either one of them prior to 2009. So this article from 2006 clearly assumes a centralized source control system like SVN. The advice is not applicable to teams using a DVCS. – Kyralessa Jul 06 '12 at 02:35
  • 2
    @Kyralessa: The article even states that "Subversion is the modern [version control system]". – che Jul 06 '12 at 08:40
  • 4
    First the code and then the tests? –  Jul 06 '12 at 09:32
  • @che, thanks for noting that. I didn't read the whole article; just looked at the date. – Kyralessa Jul 06 '12 at 14:37
  • @che actually this would still apply to DVCS – Woot4Moo Jul 07 '12 at 14:55
  • 2
    In a recent project I was almost forced to commit premature code in the name of _commit early_, _commit often_. The code was so buggy that the application could not be tested for a few days because many functions were not working. If I had followed my own judgement I would waited a few days until I was able to commit something more usable. Shame on me that I agreed to it. – Giorgio Jul 07 '12 at 22:12
  • 2
    You write small chunks of code that pass your unit tests. If your not able to check-in each couple of hours your check-ins are too large. Change your workflow and give it a go. – Jeremy Thompson Jul 08 '12 at 11:31
  • 2
    @Jeremy Thompson: This works well when you are developing code in which the structure is well-known a priori (I am working on a similar module right now): you write your unit test, develop the code, run the test, passed, check in. Other times the module is quite new and complex and you cannot easily break it up as you say. Then it may take a few days before you get a meaningful, coherent piece of code that you can check in. – Giorgio Jul 09 '12 at 01:37
  • That is more for Proof Of Concepts. I'm talking when the Product Backlog is full and a sprint iteration is planned/defined. That when I check in for each task. Its also ok to 'associate' changes with a work item when it compiles but is not resolved completely. Either way as long as the work gets done:) – Jeremy Thompson Jul 09 '12 at 01:46
  • 2
    @Jeremy Thompson: (1) a sprint lasts more than one day so you are not forced to check in every day. (2) I was not referring to a proof of concepts, I recently had to develop a complex module with very well-defined requirements, but it was simply complex: it could barely fit in one sprint (and, no, it could not be split into smaller units, it was just one complex function to be added to the system), and each chunk of work within that user story took 3, 4 days continuous and extremely focused work. Committing in the middle was simply meaningless. – Giorgio Jul 09 '12 at 05:00
  • @Woot4Moo: My arguments detailing why I don't think this is a good advice anymore can be found in my answer below. Feel free to criticise it :-) – che Jul 09 '12 at 08:07
  • The cited article does not say that committing every day is a rule to be strictly followed, but a "... general rule of thumb". – Giorgio Jul 12 '12 at 05:10
  • I don't think you can state one position is right or wrong without knowing what the local architecture and versioning rules are. – temptar Jul 12 '12 at 12:20
  • Depends a lot on the scope of what you're working on. Some days I make lots of commits, especially when I'm refactoring so the step-by-step process is visible in the history log. But tomorrow I'll be checking in a month's worth of work in one big commit — a rewrite of a whole subsystem, that's more like the "initial commit" in a new project than a change to existing code. – Wyzard Jul 13 '12 at 05:29

9 Answers9

110

I commit code several times a day. Whenever I reach a point where the code is complete enough to compile and doesn't break other things, it goes in.

You should look at breaking up your work so you can safely check-in a few times a day.

The rationales for this are two:

  1. Any work that is not checked in may be lost - your computer may have a catastrophic failure. In this case, the longer you wait, the more work you lose.
  2. The more work you do without checking in, the more code others will need to integrate when you finally decide that it bakes. This introduces more chances of conflicts and merge issues.
N4TKD
  • 214
  • 1
  • 5
Oded
  • 53,326
  • 19
  • 166
  • 181
  • 1
    +1 for answering with my answer before I could; mostly on sane break-up of work. That said, it's like many things (imo), a best practice that will occasionally need to be broken. – Telastyn Jul 05 '12 at 20:10
  • 3
    If you've got a serious problem with conflicts and merge issues, it means your project manager isn't doing his job. Multiple cases involving similar functionality should go to the same developer, precisely so that you *don't have* two or more coders stomping each other's work. – Mason Wheeler Jul 05 '12 at 20:19
  • 15
    @MasonWheeler - After 3 days of work that has not been committed, there is a very good chance that one has touched code that others have at the same time. If you have a bunch of programmers doing this, event the best project manager can't avoid conflicts from occurring. – Oded Jul 05 '12 at 20:22
  • 3
    @Oded: Maybe. I suppose my response is colored by my experience on a codebase large enough that our developers (about a dozen coders on the team) all tend to have non-overlapping responsibilities. Not sure how different it would be on smaller projects. – Mason Wheeler Jul 05 '12 at 20:27
  • 1
    @MasonWheeler - Smaller projects, in particular those that are green field can suffer badly from this (the infrastructure is so new that everyone making a significant change needs to change something...) – Oded Jul 05 '12 at 20:29
  • 1
    @Oded: Yeah. Different perspectives. We've been around for over a decade and become the industry leader in our field. That's about as far from "green-field" as you get. – Mason Wheeler Jul 05 '12 at 20:34
  • @MasonWheeler - Hehe... I suppose it is. Massive difference in perspectives :) – Oded Jul 05 '12 at 20:36
  • 1
    I do not understand why it should be necessary to commit more often on a smaller project: a smaller project is easier to manage and therefore it is easier to break it up into separate modules to be assigned to the different developers. I think too many conflicts are a sign of poor design. – Giorgio Jul 05 '12 at 21:28
  • 1
    Sorry, but if I am pulling their updates twice a day, then how likely are merge conflicts anyway? Also, checking in complete features leaves a much more usuable history in the VCS. The odds of catastrophic failure are so little and losing a day or two of work so minor that I don't really think that is a concern. – Sled Jul 06 '12 at 01:54
  • 3
    @ArtB - What if there is someone like yourself that only checks in every 3 days? Or once a week? You are relying on others doing the right thing. – Oded Jul 06 '12 at 08:30
  • @Artb: I work on 2 projects that integrate together at the moment, with 2 different code repositories. First one has about 10 developers, and sees between 5 to 25 commits per day. The other has about 35 developers (including come working on plugins) and sees often between 100 and 200 commits). If you don't update often, you don't know what you're testing. And if you don't commit often, you do meet conflicts very often, especially if you work in a "busy" area. So, twice a day, I'd say conflicts are quite likely **for me**, but that's because of the teams' sizes and activity. YMMV. – haylem Jul 06 '12 at 13:40
  • @Giorgio too many conflicts could be a sign of poor design or a sign of poor coding practices. Frequent merges allow you to detect both early. – philosodad Jul 06 '12 at 13:55
  • @philosodad: I would rather do the design beforehand: discovering that there is bad design through a merge conflict is IMO a bit too late, and probably a sign of bad practice. Maybe two developers started to modify (or maybe just to play around with) some common files without first discussing a common design and coordinating their work. – Giorgio Jul 07 '12 at 22:25
  • @Giorgio by definition of oversight, you can't determine what you didn't consider in your design beforehand, and by definition of human, your design contains areas of oversight. Saying that you would prefer to have good design doesn't obviate the value of having a check to see if you *actually do*. – philosodad Jul 08 '12 at 01:06
  • 3
    When I read the question, my response was "is that like asking if it's a good idea to shower every week"? – Andrew Grimm Jul 08 '12 at 12:05
  • 1
    @philosodad: I do not expect to have a perfect design before I start coding. Nevertheless I find the idea of checking in often and using (among other things) merge conflicts to detect design flaws a bit awkward. But this is just my opinion. – Giorgio Jul 08 '12 at 20:04
  • @giorgio I'm not advocating using version control for that purpose. You use version control to control your code. An *added benefit** of frequent checkin is that you gain information about many things, *including*, but not limited to, design flaws. The *lack* of merge conflicts is *also* information. As is whether it is awkward or easy to check in frequently. – philosodad Jul 09 '12 at 00:47
  • "After 3 days of work that has not been committed, there is a very good chance that one has touched code that others have at the same time.": I am in this situation right now: worked for two days without a check in, then checked in tons of changes (> 30 files affected) but no single conflict. Why? Because the whole team knows what I am doing (we discussed it before I started) and they do not change those parts of the code until they know I have completed this user story. Morale (IMHO): the main communication channel between developers should be speech not the revision control system. – Giorgio Jul 13 '12 at 07:07
  • 2
    @Giorgio - "they do not change those parts of the code until they know I have completed this user story.". Excellent. So, if they _needed_ to touch those parts of the code in order to progress _their_ stories, you blocked them for two days. – Oded Jul 13 '12 at 09:05
  • They _do not need_ to touch those parts because their user stories do not involve those parts. There is plenty of stuff to do in the project that does not involve the code I am working on at the moment, so their current user stories involve other parts of the code. This is what _planning_ is about. – Giorgio Jul 13 '12 at 09:26
46

I do not agree with this rule and I agree with what Mason Wheeler said. I would like to add a few ideas.

I try to commit every time I have a meaningful change to commit: this can be several times a day if I fix several small bugs, or once a week if I am working on a larger piece of software that cannot be used by the rest of the code in any meaningful way until it reaches a consistent state.

Also, I interpret committing as publishing a meaningful revision that contributes new functionality to the code base. I think one should try to clean up the code before committing so that other developers can understand the meaning and the purpose of the change when they look at the revision history. The fewer changes other developers see in the history, the better: when I look at the revision history I want to see increments that add some meaningful functionality; I am not interested in every small idea each developer had and wanted to try out before they reached the solution.

Furthermore, I do not think it is a good idea to use the SVN server (or whatever version control system) as a backup facility to which the current snapshot of the code is committed (provided that it compiles): you can use a USB stick or an external USB-drive or a network disk to mirror your current code so that it does not get lost if your computer breaks down. Revision control and data backup are two different things. Publishing a revision is not the same as saving a snapshot of your code.

Finally, I think that it should not be a problem to commit every now and then (i.e. only when one is really satisfied with the current state of the code) and avoiding merge conflicts is not a good justification for committing (too) often. Many merge conflicts happen when different people work on the same files at the same time, which is a bad practice (see e.g. this article, point 7). Merge conflicts should be reduced by splitting a project into modules with clear interfaces and as few dependencies as possible, and by coordinating the work of developers so that the code they work on overlaps as little as possible.

Just my 2 cents.

EDIT

Another reason against premature commits that came to my mind is that a (very) buggy version cannot be tested. If you are committing on the trunk and your test team is testing every day, they might have no testable version for a few hours (or for a day). Even if you do not try to fix the bug and just revert your changes, a rebuild can take a couple of hours. With, say, five testers working in your team, you have wasted 5 x 2 = 10 hours of the team's time due to inactivity. It happened to me once so I really try to avoid premature commits in the name of commit as soon as possible.

Community
  • 1
Giorgio
  • 19,486
  • 16
  • 84
  • 135
  • 24
    A 'commit' is not a 'publish'. 'Commit' means 'snapshot'; 'publish' is called 'push' in scm-lingo. Of course, SVN just merges both concepts into one, making many sensible workflows impossible, but that's a limitation of the tool, not of source control workflows in general. – tdammers Jul 05 '12 at 22:08
  • 3
    `Revision control and data backup are two different things` Yes, I definitely feel this way. – Sled Jul 06 '12 at 01:59
  • 1
    @tdammers: I meant publish in an informal way: As long as the code is on my computer it is my private changes to the common code. As soon as I commit it, it is published, known to the rest of the team and part of the official project history. – Giorgio Jul 06 '12 at 04:37
  • 1
    In that case, 'commit' is probably the wrong word. Many SCM's allow for local commits, and sharing your code with the rest of the team is a separate action, usually called 'push'. Again, SVN lumps the two concepts together, but that is a limitation of the tool, and if it gets in the way of your workflow, consider switching to a different SCM. – tdammers Jul 06 '12 at 09:02
  • @tdammers: To have a clear distinction between local commit and publish would be a step forward. In SVN I can use a separate branch for that though. But again, I wonder why I would want to keep track of a revision that does not make much sense to me? I am not convinced that I want a new revision (even a private one) just because it is 5 'o clock and I am going home. I prefer to have a backup instead. – Giorgio Jul 06 '12 at 09:34
  • I think this is a valid, possible interpretation of the (D)VCS workflow but by no means the only one. – Konrad Rudolph Jul 06 '12 at 12:04
  • @Giorgio: of course, "time to go home" is not a very compelling reason to commit. But ideally, you make a dozen commits per day or more, each representing a small incremental development step. Unless you drop what you're doing in the middle of such a step, you *will* have something to commit at the end of the day. – tdammers Jul 06 '12 at 12:16
  • @tdammers: This is an ideal situation. As I wrote in my answer, there are situations in which one can commit many small changes during a single day. Other times you have to work on some complex feature and at the end of the day you do not have something meaningful to check in. In such cases one check-in per week can be more appropriate. – Giorgio Jul 07 '12 at 07:46
  • "you can use a USB stick or an external USB-drive" in some office this will get you fired, beware. – N4TKD Sep 10 '13 at 20:55
  • @N4TKD: Why? Because they'd fear you want to steal the code? If an office has so little trust in their employees I wouldn't want to work for them. Anyway, using a second hard disk or a network drive, or working in a separate branch are all possible alternatives. – Giorgio Oct 26 '13 at 09:02
41

Slavishly adhering to any methodology or practice without understanding the reasons behind it is never a good idea. That's where cargo-cult programming comes from.

Therefore, "I should commit every day because Martin Fowler said so" is just stupid. And sometimes it's impractical too. If you're working on a complicated new feature, you might not reach a point where it's worth checking in until you've already worked on it for a few days.

This doesn't mean you should make sure everything's perfect before checking it in. That's a good way to lose work if something goes wrong. The correct thing to do is to develop and use good judgment on the matter. Rules of thumb can only help you so much.

Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
  • 2
    Then if it is complex feature integration/development, it is still a big loss not to commit it, maybe not to the trunk, but at least in a branch for this feature, that's what branches are for ! – Vincent B. Jul 06 '12 at 01:32
  • 2
    What do you mean 'worth checking in'? If it doesn't break anyone else's code, why wouldn't you check it in? – Kirk Broadhurst Jul 06 '12 at 03:05
  • 3
    "What do you mean 'worth checking in'? If it doesn't break anyone else's code, why wouldn't you check it in? ": because I do not want to keep old copies of the code just because they existed at some point in time. I want too keep an old copy of the code if it contains some useful information that I might want to retrieve in the future. Otherwise I am just producing useless noise in the revision history. – Giorgio Jul 06 '12 at 09:54
  • 3
    +1. I once worked in a team where we had to check code into the vcs every day, even if the code was a spike or a useless investigation. It proved inefficient and wasteful, particularly because it required periodic maintenance to clean the vcs up. It was a due to combination of paranoia over potentially risking losing a little time to redo something, and because the manager had read in a book that you should commit every day. An extreme example perhaps, but seriously, if you haven't the judgement to know whether it's "worth" checking something in, you're probably not well suited to the job. – S.Robins Jul 06 '12 at 13:43
15

Oded gave two important reasons to commit code as frequently as possible. I'll add a few more:

  1. While working on your piece of code, other might need some functions on that code. They shouldn't wait 6 days to get it. In this case my colleagues usually create a prototype in my piece of code, commit it, I add the body and commit it again. And this is usually done in a few hours.

  2. The 'common' code is for everyone to see every change as soon as possible. If the piece of code you're working on is totally separate from others' work and you will not have them wait, then it is recommended to create a branch for you to work on, and then, if everything is successful, merge it to the mainline.

superM
  • 7,363
  • 4
  • 29
  • 38
  • 1
    Why is this answer with (IMO) the only correct and accurate answer (point 2) so low rated ?! Of course that's the point of a branch! @Mason Wheeler: So you enjoy coding several days in a raw without commit a single time ? Then why using a version control system ?! – Vincent B. Jul 06 '12 at 01:32
  • 2
    This is the correct answer. If your task is many days of work before it is usable, then branch. Otherwise you commit whenever it works to ensure that team members have the latest version, they can test that it works, and they identify added/missing features ASAP. – Kirk Broadhurst Jul 06 '12 at 02:36
  • "So you enjoy coding several days in a raw without commit a single time ? Then why using a version control system ?!": Because eventually you do want to commit a revision, even though you are not forced to blindly commit every day. Rather, it is up to you to decide whether you commit several times a day or you work three days on a row without committing. I really do not see the point in committing some unfinished feature that nobody can use: just make a backup, the next day you can finish it and commit it. – Giorgio Jul 07 '12 at 22:08
8

I'm a strong believer in committing every logical change that is worth keeping. Commit often, and if code isn't worth keeping, revert it back to a clean state. The longer you wait to push/publish your code back, the harder it is to implement, and the more problems you'll run into. You'll also get feedback about your contributions a lot quicker:

  • do they break the build?
  • are you duplicating another team member's efforts?
  • are you doing something incorrect?
  • or are people waiting on things from you?

Small changes are a lot easier to manage.

Also, it's worth noting the difference between different version control systems. Some, such as Git (distributed), will allow you to commit and control your entire history locally, only pushing when you are ready to publish. Others, like SVN (centralized), will combine the two steps making small commits very inefficient.

Don't forget that your commits are essentially change documentation. When things go wrong, you'll be glad to have more history than not enough. A single commit for a weeks work seems useless to me. I'd just end up reading every single line of code changed rather than the summary of each logical chunk.

Adrian Schneider
  • 1,809
  • 1
  • 12
  • 10
5

I think most of the answers here misses one of the main points in Martin Fowlers statement. This is related to Continuous Integration. Code that isn't checked in (pushed/published/merged) into the mainline isn't tested.

This should not be read as an encouragement to commit whatever code you have in your local machine whenever it's time to leave the office. As pointed out by several others here that would be bad, would break the build and cause an unstable mainline.

However, it is an encouragement to try to make your changes in small steps that can be checked in to the mainline without causing problems. This encourages evolution of the code instead of ripping it all apart and rewriting.

Now, what's good about this way of working?

  1. Not committing large chunks of code or revolutionary changes reduces the chance of breaking the build.
  2. If your commit breaks the build it is fairly trivial to identify what the problems are, to revert it and then commit a fixed version quickly.
  3. By making sure all tests run on every small change in the code, you ensure that you don't introduce subtle bugs or regressions that can come from having code grow outside of the continuous integration scheme.

Of course not all changes lend themselves to this approach. As others pointed out, no rule is absolute. However, for changes that are expected to stay out of mainline for a long time, set up an alternative mainline with it's own continuous integration scheme and follow the same approach towards it. With the distributed VCS's of today that's a fairly easy thing to do.

harald
  • 1,953
  • 13
  • 16
  • +1: "Of course not all changes lend themselves to this approach." I think this is the point. I find Fowler's advice OK, but one should judge from case to case. Instead, this advice is often generalized to an absolute rule and followed without any further consideration. – Giorgio Jul 13 '12 at 07:14
  • @Giorgio, I absolutely agree with you on that. No advice should be taken as absolute rules, no matter who is behind it. – harald Jul 13 '12 at 20:33
  • Some more ideas on this. "Code that isn't checked in (pushed/published/merged) into the mainline isn't tested.": I agree that this is a good principle and one should not wait weeks before checking in and having their code tested. However, blind application of this principle can lead to a broken application that cannot even be tested (I have seen this live: the whole test team sits idle for days and cannot test _anything_ until the code is brought back into a usable state). Maybe what other users wrote is applicable to some situations but it is not in general. – Giorgio Jul 13 '12 at 21:12
  • 1
    Checking in unstable code is never ok. A commit that breaks the CI should be reverted. If you commit small incremental changes often, there's less chance of introducing such breakage than if you have a big change that has been left untested for a long time. It may also be easier to revert if it breaks the build. But as you say, sometimes there's no way outside of a disruptive change. Then by all means polish it as best as you can, and test thoroughly *before* committing it. The point is not following rules, but understanding where the advice comes from. – harald Jul 14 '12 at 08:08
3

Arguments for checking in every day:

  • Code is stored and backed up against harddrive failure
  • Activity can be recorded in commit notes (what did I do on Thursday...?)
  • Integration with existing code base happens earlier and in smaller chunks, hopefully identifying conflicts or merge issues sooner
  • Your team have visibility of what you have been working on
  • Your colleagues can work against your interfaces sooner, giving them more time to integrate with your 'big complex bit of code'
  • Your code will be real-world tested sooner, or at least exposed to more use than you will give it, leading to earlier identification of bugs or omissions.

Arguments against checking in every day:

  • Don't need to or don't want to
  • Haven't 'cleaned up' my code yet, it's a mess
  • Don't have time

I don't believe there's any good reason to check in less than daily apart from laziness or disorganisation. Nothing worse than see the code running in the development environment doesn't match the code in the development branch because someone 'hasn't finished yet' and thus hasn't checked in.

I'd love to be wrong on this so please let me know any legitimate argument against daily check-in.

Kirk Broadhurst
  • 4,199
  • 18
  • 27
  • "I don't believe there's any good reason to check in less than daily apart from laziness or disorganisation. ": I believe the opposite for exactly the same reason. I can take the time to look at the current state of the code and decide if it contains some relevant information that is worth remembering, or, if I am lazy and disorganized, I can simply check it in (and produce extra revisions with little information content) as long as it compiles. – Giorgio Jul 06 '12 at 09:57
  • 1
    I understand your point that one should not be lazy and clean up their code every day so that it can be checked in. On the other hand, when working on some complex code, this is difficult to achieve because the _clean up_ may take several hours, and you cannot spend several hours every day only to clean up your code. – Giorgio Jul 06 '12 at 10:04
  • @Giorgio So you spend several days cleaning up your code? I've given some good reasons for checking in daily - your reason is that you will have to clean up your code? Just write cleaner code straight up. – Kirk Broadhurst Jul 08 '12 at 22:56
  • This is not always possible, e.g. if I am developing from scratch some complex code (> 4000 LOC) which needs a lot of experimentation to get right. It is well possible that at the end of the day the code is a bit messy and I don't want to fix it until I get to a consistent state, which is a couple of days later. Unfortunately I am not so smart that finished, perfect code forms in my mind and I can always have it all written down in a few hours (i.e. at the end of one day). I had such an experience lately and the typical development cycle (from one consistent state to the next) was 2, 3 days. – Giorgio Jul 09 '12 at 01:20
  • @Giorgio do you not have a development branch that you are checking into? The code should be checked in so that other people can review and test it as well. – Kirk Broadhurst Jul 09 '12 at 01:31
  • I have the impression we are running on two parallel lanes. My point is not whether I should check in or not, but when. I would not check in something I still consider unfinished and not yet worth testing or reviewing. Take the analogous situation that you are writing some document. Do you want people to read a document containing half-finished sentences or paragraphs, incomplete or unclear ideas? No. You normally give them something that, while being a draft, you consider worth reading otherwise you are wasting their time (and yours). – Giorgio Jul 09 '12 at 02:22
  • I don't leave a document in an unfinished state at the end of the day - I'll make sure it's coherent and a readable 'draft'. Similarly, I won't go home mid-function if I'm coding. Another benefit of checking in every day is that it forces you to tie up the loose ends in your code, so that when you arrive next morning you have a logical start point. – Kirk Broadhurst Jul 09 '12 at 02:52
  • "I don't leave a document in an unfinished state at the end of the day - I'll make sure it's coherent and a readable 'draft'.": If the content is not too complex, yes, this is feasible: I have nothing against it and I do it as well. – Giorgio Jul 09 '12 at 04:25
2

If you're meaning "commit" as "merge into mainline", then you definitely should not be doing that everyday on a software project that's being released to the customers. You should be merging changes that are done and tested, so that the mainline is always working and releasable, and not in some broken state with half-finished features.

However, the luxury of working with today's distributed version control is that you can both keep mainline stable, and at the same time do your git/hg/whatever commit every time you feel you want to preserve the state of things. I do this once every few hours and definitely at the end of every day.

With DVCS, you can publish your work, collaborate on it with others in your team, and keep it up to date with changes in the mainline branch. You can do all this without polluting the stability of code your customers and/or other teams depend on.

In times when Subversion was the latest technology and there was no way to fork and merge feature branches without extreme pain, having a mainline where several different features were in simultaneous construction might have been the best approach. But this superiority does not scale beyond 2010.

che
  • 236
  • 1
  • 6
2

In Team Foundation Server you can 'Shelve' which is not the same as a check in, but just makes a backup of your code so that if your machine dies you have not lost the changes.

I have also seen software houses that have a 'developer line' and a 'mainline'. Devs are free to check in to the developer line whenever they deem fit and only the team leader has access to the mainline so they are responsible for copying code from dev to main when it is production ready.

Matt Wilko
  • 372
  • 1
  • 8