Take the 2-minute tour ×

It seems to be a generally accepted good practice not to push invalid, broken, or incomplete code. But one of the huge advantages of version control systems is that it gives you a remote place for your code, so you can work on the same codebase from more than one place.

Suppose you are working on a feature with a couple other developers, and a bad winter storm is announced; everybody agrees to go home and keep working rather than get caught in the storm, but nobody is at an ideal stopping place. What do you do?

  1. Create different branches for each developer and commit your changes to that, push those branches to remote and hope you can clean it up later on remote without making life difficult?
  2. Create a different remote just for incomplete code?
  3. Copy your code to your personal flash drive and hope you don't lose it later, or get caught violating company policy?
  4. Something else?

(We use git, but I would hope the answer could be general to any version control system.)

share|improve this question
I'm not sure this can be DVCS agnostic as this is exactly what DVCSs are for! –  jk. Jan 28 '13 at 15:46
Easy: go home, ssh into the office, continue where you left off... –  tdammers Jan 28 '13 at 15:50
@jk. yes, I didn't really mean agnostic to DVCS, I meant general to all version control systems. Updated. –  kojiro Jan 28 '13 at 16:03
add comment

6 Answers

up vote 13 down vote accepted

Take it a step farther than just creating a branch to solve this specific problem and move to creating a branch for each feature, bugfix, etc... that you decide to implement. Each of these branches should be expected to have broken code in it any any time. Once the code is been completed it can be merged / tested against the main branch of your repository.

This will allow you to solve the current issue of where to store incomplete and broken code and help in organizing your thoughts and ideas. If you want to try a new crazy feature in your spare time you simply create a branch for that feature and begin working on it. You can put it away for two months in a broken state and pick it back up at a later date by merging back in changes that have made it into your main branch.

A good outline of a branching in this manner using continuous integration (CI) can be found here: http://nvie.com/posts/a-successful-git-branching-model/

share|improve this answer
I find it convenient to rebase or sqash-merge several commits together into a coherent changeset before sending upstream for merging. This way, each commit is ideally a logical step in the evolution of the software (rather than half-step). –  gahooa Jan 28 '13 at 20:12
+1 for the "master-develop" branching strategy –  Gary Rowe Jan 29 '13 at 16:36
add comment

If you're using a DVCS then it's as simple as "4. Create a remote repository for each developer."

For most CVCSes, you really have to use branches. TFS offers shelvesets which can be used for this purpose.

share|improve this answer
+1 for mentioning branching strategy and or shelveset can make this ok in CVCS, but agreed DVCS is really the best way to solve this problem. –  Jimmy Hoffa Jan 28 '13 at 15:46
add comment

This is where good branching strategies shine -- nothing incomplete should get into master but it don't mean that incomplete and work in progress code can't hit the shared repository. There are lots of good reasons to do that such as backup / switching machines / switching locations / help & review / gives us seniors a good idea that the juniors are doing more than playing WoW.

share|improve this answer
add comment

Branches are your best option. The golden rule is to not break the build. Assuming that is the main trunk and is properly building, then creating a branch and putting your temporary work there is fine. I much rather see incomplete work stored in version control than left on a computer that gets destroyed though.

share|improve this answer
add comment

If you work with CVCS you can try rolling with one trunk. I've seen this done very well a few times. The thing to do is to have continuous integration with unit tests, and contiguous testing on that trunk.

One rule: Don't break the build and don't break functionality.

But, there are some 'incomplete' checkins that are acceptable. For example, if you're going to add a feature and you need to check in some model classes that aren't used anywhere - that's OK, just mention what they're for in the commit logs. If you need to extend an existing class to have more functionality - that is also OK.

Frequent checkins like that have 3 benefits:

1) Everyone will see your 'direction' early. They will be able to coordinate with you on their work, and use your changes if they see value in them. One problem with branching for features is that people can simultaneously invent the same wheel.

2) Your stuff will be tested early. One problem with branching for everything is that there needs to be 2 rounds of testing: one for the feature done in branch, and one for the feature after the merge.

3) If things get broken they will be caught by other developers even before it goes to QA. Bugs are better addressed as early as possible.

One caveat: this will work on small-medium sized teams. At some point people start stepping on each-other's toes too much and you will be forced to branch.

share|improve this answer
add comment

In normal usage, I wouldn't commit changes to source control until a feature is complete and tested. The "bad winter storm" seems like a rare occurrence, which might warrant special rules. If someone was not at an ideal stopping place, then I would ask them to save those changes to another drive, or perhaps zip them up and email them to the team lead. If both of those are prohibited by your work environment, then I would break the normal usage and just have them commit the incomplete code to source control. If it breaks anything, then it is pretty easy to rollback. And this should be a rare occurrence rather than the norm.

share|improve this answer
The winter storm was just an example. It happens quite regularly that (at least senior) devs need to relocate while code is incomplete. It's also useful for junior devs to be able to push code to a shared location for help and review. –  kojiro Jan 28 '13 at 15:37
This can be a dangerous practice; see codinghorror.com/blog/2008/08/… and from Martin Fowler: Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress. Often people initially feel they can't do something meaningful in just a few hours, but we've found that mentoring and practice helps them learn. at martinfowler.com/articles/continuousIntegration.html –  Mike Partridge Jan 28 '13 at 16:24
add comment

Your Answer


