Start Git with an empty commit

Submitted by Larry on 16 January 2017 - 5:45pm

Recently I've had reason to start several new projects with Git. That's nothing exciting (except for me), but it means I've been making a lot of first-commits, and often rebasing my early commit history before making it public. That, however, runs into an interesting problem: You can't easily rebase the first commit.

Sometimes that doesn't matter. Lately, though, I've repeatedly found myself wanting to change that first commit, often to remove a file that I included in the initial commit inadvertently.

Fortunately, Git offers a couple of ways around this situation. My personal favorite is to simply start the history with a null commit. Git normally won't let you make a commit if there's nothing to do, but you can easily disable that check. My new Git projects now tend to start like so:

git init
git commit --allow-empty -m "Initial commit"

Boom, done. Now my repository has a single commit in it, the contents of which... are empty. But that doesn't matter. I can now add/remove/whatever anything I need to, and my entire useful history will still be tweakable with a simple git rebase -i.

A helpful tip for your next project.

balagan (not verified)

17 January 2017 - 1:22am

Just had the same problem yesterday, as I forgot to add the .gtignore file at the beginning. Now it makes my commit log ugly, as it is located between added modules.

commit --amend works for the most recent commit, so if you just have the one starting commit, yes, you could do that.  Assuming you could restructure the commit easily that way.  If not, then you have to use rebase, which is where the difficulty in rebasing the initial commit comes in.  (Since rebasing needs to be against a specific commit, and there's no parent commit of the initial commit to rebase against.)

(I use commit --amend quite often, actually, for the same reason as you.)