I'm probably over-thinking this and it might not matter in the scope of things, but I'm wondering how people build up initial versions of their projects in source control? I'm talking about when you start with nothing but an idea, so no forking an existing project or anything.

  • When do you do your commits before having an official or even unofficial version?
  • At what point do you start branching for features, or do you this right away?

I'm so used to working with existing code bases that I'm not really sure I know if there's a "best" way to build up a project history.

  • 7
    You're probably overthinking this. What you should definitely do, however, is throw a party to celebrate that first commit... – yannis Dec 1 '11 at 20:47
  • 1
    Make sure to have punch and pie at the party, more people will come. – unholysampler Dec 1 '11 at 23:59

When do you do your commits before having an official or even unofficial version?
Follow the philosophy of committing as often as possible. I use Subversion most of the time. As soon as I have any code that I wouldn't want to lose, and I would want to revert to if I screw something up, I do my first commit.

At what point do you start branching for features, or do you this right away?
I wouldn't do this until after the first release, or if there are multiple developers that need to work on the same areas of the codebase for different purposes that might not be released at the same time.


I typically just start using a local mercurial repository and committing to default. If it grows legs, I'll push it over to the central repository and setup continuous integration and such.

Branching is much more of a tactical decision. If the development is linear, I'll often just stick with default until I need to have concurrent versions out there -- like something a bit more fixed for QA or integration testing. At that point I'll add the long running development and release branches.

If the the project requires a bit more experimental development, I'll use named branches to contain the experiments from the get go. Merges are fun and easy in HG so you might as well use them.


Follow the unit of work pattern :)

Whenever you finished a part of a feature and the code compiles then commit.

Don't worry about the commit messages until you get to release the code into the wild. When it comes to that, many projects delete all the revision history and re-initialize the repository. Then and only then does it makes sense to over-think it.

This way you get to have many pet projects and the few that get good enough get to be released.

As to when to use branches I'd say if you are alone then you might not need them. Pick one feature at a time and complete it.


I start by committing some text file that outlines what I'm trying to accomplish, or even a rough-draft of that. I continue committing frequently until I get to some point that is some useful milestone -- a point worth coming back to if I get off track. At that point, I branch and continue development on the branch. Once the branch gets to a useful milestone, I merge it and start another branch.

Some people argue that you don't commit until it compiles. I argue that you commit all the time to a branch but don't merge to mainline until it is strictly better than mainline development.

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