The general rule is to keep check-ins small and check-in often. But sometimes the task requires large changes to the underlying framework. Then checking in before compeleting the task will break the project until you check in the finished work.

So what strategies do people use to reduce the risk of losing work, or deciding something you are doing is the wrong approach, then changing your mind after removing the code and trying another approach?

When I can, I'll check-in half done work commented out, or if it compiles and nothing is using new files I'll check them in. The larger the change the more likely I am to branch the project and then merge back when I have everything working again. Another option if the source control system allows is shelf sets, which are basically small branches. So when I finish for the day or come to a decision point, I'll shelve my changes, and then if something catastrophic happens, or I want to come back to that point, I can.

  • What source control systems are you familiar with?
    – user1249
    Oct 30, 2010 at 11:24
  • @Thorbjorn: Svn, Perforce, and Team Foundation Server. They've all got their pluses and minuses Oct 30, 2010 at 13:46

4 Answers 4


I use git, so my answer is "branch". Branch, and commit piece-meal as you complete the various bits.

Push your commits upstream as you're happy, so your colleagues can review the changes without disrupting trunk.

When everyone's happy with the code, merge and you're done!

(What I tend to do for relatively long-running branches is periodically merge trunk (master, in git terminology) into my branch, so the two branches don't diverge too radically.)

  • 1
    You don't need to qualify with "I use git" - I'd suggest that the answer is to branch full stop. The key though is to make sure that the feature branch is kept up to date with the trunk, that means merging in the changes from the trunk as often and is reasonable.
    – Murph
    Oct 30, 2010 at 11:56
  • I haven't used branching with subversion, but I'm told it's enormously easier to branch in git. I branch whenever I have a feature that's not trivial. Apparently, that's not practical with subversion, hence my qualification. I'm glad to hear I didn't actually need to qualify though. Oct 30, 2010 at 18:35
  • So basically the best strategy is to branch as soon as the size of the task is non trivial, and merge the trunk to the branch as much as needed to keep it like a normal checkout of the trunk, with the benefit of source control of the intermediate stages. Oct 31, 2010 at 22:28
  • 1
    @Dominic Basically, yes, but I take "size is non-trivial" to mean "anything more than a single line that a peer can immediately see is right or wrong". Dec 19, 2011 at 14:10

I think the answer is going to vary based on what sort of version control system you're using: centralised (e.g. subversion) or distributed (e.g. git). I don't have any real world experience with using a distributed source control system so my answer is based around what we do with subversion.

If there's a large change in progress which will break our trunk build over a period of time, or that will really disrupt the rest of the team in some other way, then we'll create a branch. I would say though that you should do as much as you can to avoid having to do that - most changes can sit side-by-side with the rest of the code with little effort. For example, you could trigger code paths into the new code (with simple if statements or you could inject the new versions based on config settings if you're using a DI framework). Then when you've finished you just change the the config to the new version, test everything, delete the unused code, test again and finally delete the config setting. You can't always do that but because of the overhead of maintaining a branch I think you should always check if that is possible.

If you do branch I think the mistake that I often see people make is not keeping their branch up-to-date with the trunk. You should be constantly merging changes from trunk into your branch while it exists so that when you've finished the reverse merge of everything back again is fairly trivial.


In out team we use subversion, and we normally commit small changes directly to the trunk. For larger tasks, the developer working on it typically creates a private branch, which is merged into the trunk once it is done. Then the private branch is deleted. Naturally, while the private branch exist its owner should check into it often.

We try to avoid having long-lived branches and trunk-to-branch merges, because that requires careful bookkeeping. Instead we have relatively short-lived branches that are only merged back to the trunk once, and get deleted soon after.

And we have a rule that nothing can be committed or merged to the trunk until at least one other person looks through the changes and approves them.


Just like the usual comment from SQL server people "it depends"

If you can, i would suggest you create a branch on the code so you can continue to apply small checkins of your work. Once completed, perform a merge backinto the main trunk.

Yes there is some chance of reowrk duplication of effort doing this. but at least you will maintian a trail of work you can rollback it it proves to be a dead end.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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