I've used VCS (mainly git) in the past to manage many existing projects and it works great. Typically with an existing project, I would check in each change I make to the code that either optimizes or changes the overall functionality (you know what I mean, in suitable steps, not every single line I change).


One thing I've not had so much practise at is creating new projects. I'm in the process of starting a new project of my own that will probably grow quite large, but I'm finding that there is a lot to do and a lot changing in the first few days/hours/weeks/the period up until the product is actually functioning in it's most basic form.

Is there any point in me checking in each step of the process as I would with an existing project? I'm not breaking the project with changes I make since it isn't working yet. At the moment I've simply been using VCS as a backup at the end of each day, when I leave the computer.

My first few commits were things like "Basic directory structure in place" and "DB tables created". How should I use a VCS when starting a new project?

  • Your title can be repunctuated into a question AND its answer: "What is the canonical approach to using a VCS? Right from a project's infancy" or indeed "What is the canonical approach to using a VCS right? From a project's infancy"
    – AakashM
    Jul 4, 2012 at 12:37
  • 1
    The title has been edited since I started the question. Whilst I can see what you're saying, that's not really the question nor the answer for the question I was asking - or at least not in that interpretation.
    – Anonymous
    Jul 4, 2012 at 12:48
  • @Anonymous-: I rewrote your title because it was in the form of a question deemed not constructive. Hope you don't mind, I did this in an attempt to prevent it from being closed early. Sorry if that confused you.
    – haylem
    Jul 4, 2012 at 15:34
  • @haylem - It's no problem, I agree with you entirely! I appreciate you trying to keep my question open - to which we now have a definitive answer. :)
    – Anonymous
    Jul 4, 2012 at 15:43
  • A (very!) quick tutorial on Git -> try.github.com/levels/1/challenges/1
    – MathAttack
    Jul 4, 2012 at 21:34

2 Answers 2


Start Simple

git init

Check-In Early, Check-In Often

Just do what you normally do with any project: "check in" for every set of changes that relates to a particular task or group of actions. If you use an issue tracker, then commit changes that relate to a task every time it's in a stable state (see this SO question on how often to commit). It may not be in a state of completion, just a stable one, in which the software is not failing to run or the site failing to be rendered. As Jeff Atwood says in his post:

If the code isn't checked into source control, it doesn't exist. [...]

I'm not proposing developers check in broken code -- but I also argue that there's a big difference between broken code and incomplete code.

Commit Often, Perfect Later, Publish Once

If the product isn't even close to a workable state, then just keep checking in changes as you see fit, using good judgment and common sense to group them together. You don't need to commit every single file's line change one by one, but committing everything as a large chunk will make it harder for you to rollback if necessary.

In the end, your VCS is here to help you. So help your VCS to help you!!

Don't Overthink It

Your first commits were fine. Don't overthink it. The most important thing is that they are checked-in. If you look at all existing open-source projects online that started from scratch and not from an existing codebase, they have has as their first revision something akin to:

created the directory structure (yay!)

Make it a Habit

At the end of each day, try to generate a log of what you've done based on your commit-logs. If the outputs you get from git shortlog and git log do NOT look satisfactory and useful, yet you've put in a significant amount of effort in the project during the day and checked those changes in, then you probably didn't do it right.

  • git shortlog should read like a broad overview of what you've done.
  • git log should read like the history AND story of your project.
  • These are good guidelines, and I'd emphasize "Don't Overthink It" (of course that applies to following guidelines too ... :) — getting out there and just doing it is the best way to learn, and people soon get a good feel for what style of usage works best for them and their project. Jul 5, 2012 at 3:44

What you are doing is the right approach.

You are using source control from day one - this will ensure that you have everything you need in source control and there's no point at which you can say:

I should be using source control but it's going to take too long to check in all of this stuff for the first time.

This is a major hurdle for people coming late to source control as they then think it's "too hard" to use. By starting early and committing changes often you have reduced that hurdle to a small step and anyone else who joins you on the project will be able to get to work straight away.

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.