Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

During a previous consulting position, the developers where told to check-in code on a nightly basis, regardless if it complied or was complete. Managers were afraid of losing any code and said now we only lose one day at most.

The place I'm currently it is investigating whether to implement this.

Anyone have any pros/cons on this? Should developers be forced into check-ins?


migration rejected from Jun 29 '15 at 19:00

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by durron597, MichaelT, Dan Pichelman, Kilian Foth, enderland Jun 29 '15 at 19:00

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

what if they dont check in? will you fire them? – Anonymous Feb 26 '10 at 23:12
How exactly does checking in at the end of the day prevent lost work? It seems to me that "hit Save occasionally" and "don't put magnets in your workstation" are both more meaningful policies to have, and their ridiculousness [as policies] is illustrative. – Ipsquiggle Mar 3 '10 at 17:41
Please replace manager. – user1249 Jan 6 '11 at 12:03
How can you use continuous integration or even nightly build with such policy ? – David Jan 6 '11 at 12:33
David they don't use CI, I suppose they don't do unit testing instead use code&fix. Maybe it is a dead-march-project... management need some way to control the "progress" (lines of code in this case) to be able to say "We go forward". @Michael how does it look in real? – Marcin Sanecki Aug 20 '12 at 7:55

12 Answers 12

This is why DVC is a good idea. Developers can check in on their own machine whenever they like without messing up someone else's code.

As for backing up. For Git, I'd have a central server with copies of everyone's code accessible via ssh. Then as a commit hook, I'd have a script that would push changes to the server. This has the added bonus of making it easy to merge branches (as they're all on the same machine).

+1 for DVCS. I do a commit every day, but if it's broken, I just push to my own private copy of the repository on the server, so I still have a backup, but the changes aren't public yet. When it compiles, then you can push it to the public shared repository. – Scott Whitlock Jan 6 '11 at 11:56
With Git, you wouldn't need 2 repos on the server, you'd just have 2 branches in the same repo. – dan_waterworth Jan 6 '11 at 12:05
This has nothing to do with DVCS. Devs can make a branch, and some have concept of shelving, both of which address the "get the code off my box" problem. – Andy Jan 27 '12 at 2:51
@Andy - yea, except that in some / many / most (take your pick) non-distributed VCS, branching and merging are painful and error prone. – Stephen C Aug 20 '12 at 6:43
@StephenC That depends on the specific tool. Sourcegear Vault (no affilication, just happy user) has a great merge tool. SVNs merge is fairly good, except recent versions broke the Reintegrate branch option. The solution is not avoid branching or jumping to another paradigm, the solution is to pick a tool that makes those things easier. Often though its how you use the tool that matters; if you make a feature branch, you should be merging in trunk fairly regularly, which will minimize the changes of a conflict. – Andy Aug 21 '12 at 12:27

If you break my build, I'm going to break something of yours. There is never, ever sufficient cause to check in code that does not work or compile. I repeat, there is never a good reason to check in code that does not work or compile.

I need, and expect that I can revert back to any revision in the history and end up with a working build. This is absolutely critical for me, and breaking this logic defeats one of the best purposes of version control.

If management is worried about losing code, disks are cheap. Ask developers to back up their files prior to leaving. I don't think that would be very cumbersome. Still, a well designed network should already be doing that, even if people tend to work on laptops that they take home at night.


I can understand management's motivation behind checking in every day. They're seeing it as a form of backup to a (presumably) central server, thus protecting their biggest asset, the source code.

In and of itself, there's nothing wrong with that, however, those "check-ins" should be made to a "work-in-progress" branch (if you're using something like SVN or even a DVCS like Git or Hg) or a "shelve-set" (if you're using TFS - this is exactly what shelve-sets are for!). The next day, developers can continue working on their own "work-in-progress" branch, and only merge with the trunk when work has been completed and all relevant tests (if any) have passed. Rinse, repeat.

Others have suggested that using a DVCS will address the problem, and sure, it allows devs to check-in to their own repository on their own machine, however, this is likely not management's intention behind their idea of daily check-ins. The likelihood is that they want all source code (both "finished" and "work-in-progress" code) to be stored on a central server somewhere. It's also then likely that this central server is either off-site, replicated or itself backed-up to tape etc.

In other words, the "check-in every day" policy isn't so bad so long as it's part of a policy that also ensures that your working main trunk is not polluted with unfinished work.

If you're referring to my answer in the third paragraph, then reread my answer. – dan_waterworth Jan 6 '11 at 11:26
@dan_waterworth - I'm not specifically referring to your answer, Dan, but many others in this answer thread have also mentioned DVCS, which is fine so long as there's also that "central" backup (which you do indeed mention yourself). – CraigTP Jan 6 '11 at 11:49
ok, thanks. – dan_waterworth Jan 6 '11 at 12:07

I've always advocated checking in regularly (i.e. more than once a day), but only checking in code that compiles. Even if a feature isn't 100% complete, it provides earlier oportunities to determine if the work in progress is going to affect other parts of the code.

Here's an example of what your company is (hopefully) trying to avoid:

Many moons ago, I had a borrowed developer working on an IR&D project. Despite me badgering him to check his code in every day for a month he wouldn't do it. When he finally did check in the code it was working as long as there was only ever one user at a time. By developing a Java web application like a C project (everything was a static method, aka function) he caused a whole mess of rework for the rest of the team.

There are similar horror stories such as the original IR&D developer not using version control at all, and the current version of the software was in his local directory on his machine instead of the file server. He left the company, leaving the IR&D project high and dry (which is why I was brought in and dealt with the situation above).

That said, I'd rather know that there are issues and design choices that need to be addressed earlier rather than later. However, the trunk should always compile. I've never left for the day with a broken build. Whatever your solution, keep in mind the cautionary tale of the developer who wouldn't check in code, but also keep in mind the horror of the first person arriving for the day having to fix everyone's code before they can continue.

As with all things, there needs to be a healthy balance.

Edit If you ever do find yourself "blessed" with a developer who refuses to check in code for an extended period of time, you have some other problems that you need to resolve. If they refuse to check in their code, insist on a code review--you need some assurance that the code is going to function in your environment when it finally is. If they refuse that, they probably shouldn't be on your project at all.


Use a DVCS like GIT. Commit things that work and pass the unit tests. The rest that is not done yet, just stash it on your local machine and have a good evening and night.

Another answer pushing DVCS for a silly reason. Never heard of a feature branch or shelving? – Andy Jan 27 '12 at 2:53

If the workflow within the company is such that every check-in gets included in the nightly build automatically, then the check-ins must not break the build under any condition.
If the manager does not understand how bad it is to break the build, ask him who is going to explain to the management of the testers why they have not received any new versions to test for the last three weeks. And to upper management why we have not been able to meet the scheduled release dates.

If additional steps are needed before a check-in gets included in a build, then it is not a big deal to use such check-ins also as a backup procedure, although real backups would be preferable, if only because they don't/shouldn't require active actions by every developer.


The simple answer is no - if its broken or if its not finished then it shouldn't be committed. Version Control should not mindlessly be used as a backup system.

If they want backups they (management) should implement a backup solution - either explicit or implicit.

The real answer is more complex as has been identified by various people - but DVCS, for example, won't provide a backup unless the committed code is immediately (and automagically) pushed to a clone - of the Work In Progress - on another box.

So the bottom line is this - even if you have a structure in your VCS that allows commit early and commit often of notionally failing code by having a safe work in progress branch (that's another discussion) you should still have an independent backup solution.


If it breaks the build don't commit it. If management still want code checked in organize a separate branch for the non-compiling code and then devs can commit their broken code to that branch.


The rule of thumb that I've always heard is as follows:

Code doesn't exist until it has been checked into source control.

So my usual policy is that code should be check in on the basis of the completion of function, classes, etc as opposed to fixed times through out the day. If you are only checking in once a day then if something happens to your computer, you lose a lot more work than if you are checking in every time you are able to close out an issue ticket.

That said, where a project is in the life-cycle affects what you want to be doing with it. When you are still in the process of developing a new program from scratch you might be a bit more forgiving than if you are working the maintenance of an existing application.

Also, how the code is broken also makes a difference as well. If the requirement is for a function to be rewritten and you are only half done when it's time to call it a day then I say just update the code in such a way that it will compile and then raise some sort of flag such as System.NotImplementedException so others know what is going on. If you ripped out a bunch of code that affects several different parts of the application then it might be better to leave it out of source control so you don't disturb others work.


We had this policy at my last job, and it was never really problematic. We had user.daily or feature.daily branches for code that didn't compile or run, and once the code built and had undergone some basic testing (it doesn't segfault as soon as you run it, etc.) then it would get merged into the feature branch. Once a feature was complete and unit tested it would get merged into the master branch. This way nobody's build was ever unexpectedly broken, and we had code being stored somewhere other than the developers workstations.


We have a policy that developers should shelve their code in TFS before they leave. This allows code to be saved and backed up without breaking the build.


Requiring developers to commit code at the end of the day is crazy, but unless you are a developer its easy to see how it would make sense.

As developers, you shouldn't really go longer than a day without committing code anyways ... if it is going to take longer than a day to write a single unit of change (or whatever unit of measurement you use to justify a commit) then you should probably have broken it down into a smaller change anyways. If those multiple changes belong to a bigger feature, it should be on a separate branch anyway.


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