When do you make your first commit?

Question

The Question:

Basically I want to know, when is the best/right time to make the first commit to source/version-control?

The Background:

I write and maintain a few projects on my own, mostly as a hobby or as volunteer work. When starting out on a new project I typically iterate very quickly, to get the look/feel of the site/app to where I want. Once that "framework" is done, I start working on individual sections or pages.

In the past, I haven't made the first commit until I was done with the first "alpha" build, where almost all of the initially desired functionality is there. I have never been to worried about screwing something up, because I am constantly testing as I am writing (webpages served from a remote dev server for example), and if I mess something up, I can revert pretty much instantly. I've never been worried about losing work, because the files are stored in two places (local machine and remote dev server).

Lately though I've been thinking that I should maybe be making my first commit at the very beginning of the project. Then make a commit when the framework is finished, when each page/piece of functionality is finished. This method would give me a better history of the changes I make, but I am wondering if there are any other big benefits to committing that early in the project.

The two most relevant posts I found, Using Source Control, and Source Control - If, Why, How to start?, don't really seem to give a good answer/explanation of when to make the first commit and why.

Answer 1

I usually commit a first initialization commit at the very beginning with a basic .gitignore (in rare cases this might even be blank) and/or a README explaining the project. This happens before I start working on the project.

I can understand very well your difficulties to decide what your first real commit should be when starting from scratch. After all, we want to make useful commits that actually contain something useful and working already. But especially at the beginning this is not really possible or easy. But this is completely normal. So you shouldn’t be ashamed to commit just what you have. Maybe try to pack it into semantical steps, like “add base application framework”, “add layout draft”, but even this is sometimes but possible, so go ahead and just commit something.

If you really want to clean up later, you can still rebase before publishing the project, so even those “WIP” commits will be rewritten into actually useful packages.

Answer 2

The first commit shouldn't be more important than any other commits of yours; it's just a commit like any other in your repo.

You should do your first commit wherever it feels logical to do it, that means, wherever you reach a point that the work you did is logical enough to justify one, and only one, commit; just as you do in your normal workflow.

My first commits are typically the empty project IDE files or a initial .gitignore.

Don't be afraid of commiting. Actually, you should feel the very opposite of it: commit often to aid you. Leave the bureaucratic neurosis to merging and tagging :)

Answer 3

The more commits you make the better. You can just open a new "dev" branch, develop and commit into that branch, finally merge it to master branch and get rid of the dev branch. I do commits if something works, or if I call it a day (usually I push it to origin after that)

Answer 4

I often like to commit a .gitignore file as the sole contents of the first commit.

Then, after I beat something into some sort of prototype shape, I may make an entirely new repo without all the junk in it, or do a lot of rebase squash-ing, or whatever. It depends on what, if anything, in the commit history seems useful.

Answer 5

I'm going to assume you are talking about the first commit when starting a new feature, not just the very first commit ever in a repo. I also think that you (like me) used to use SVN or CVS or something where a commit was immutable and immediately shared with others.

One of the nice things about using git is that that you can use a private rebase workflow. Under this workflow, I think of commits as different "kinds" of commits:

• checkpoint - a save point because I want to save my place, e.g. I'm about to refactor something I want to easily back out, or I need to context switch to some other task, or I'm just leaving work for the night

• development milestone - a significant point in development was reached, e.g. you finish coding a feature or you fixed a certain bug

• feature milestone - a significant point in develop was reached, e.g. a feature (or part of a feature) is code completed and passed initial testing

My checkpoint commits are very temporary - I'll reset them, amend them, rebase them, and squash them as I work. My development and feature milestone commits stick around until I'm done with the feature. Once I have completed the feature, I clean up my history and decide what I think is important to preserve in the project history when I merge and push - I'll reorder and squash down a small # of historical significant commits or even down to a single commit for the feature).

My point is to not sweat your first commit during development - checkpoint frequently as needed. Once you have more history after completing the feature and you clean up the branch, it may be easier to decide what should be the "first" (possibly only) commit in the feature branch.

---

Linus about private rebase workflow:

• http://lwn.net/Articles/328438/

People can (and probably should) rebase their private trees (their own work). That's a cleanup. But never other peoples code. That's a "destroy history"

...

Now the "clean" part is a bit more subtle, although the first rules are pretty obvious and easy:

• Keep your own history readable

  Some people do this by just working things out in their head first, and not making mistakes. but that's very rare, and for the rest of us, we use "git rebase" etc while we work on our problems.

  So "git rebase" is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree.

• Don't expose your crap.

  This means: if you're still in the "git rebase" phase, you don't push it out. If it's not ready, you send patches around, or use private git trees (just as a "patch series replacement") that you don't tell the public at large about.