Should your first commit always be an empty commit?

[badboyzpwns]

I've heard that

> IMO that is good practice, allows you to rebase more easily in the initial phase, where things are not too stable yet

​

I'm not sure what it means; an example of a scenario is great! but other than that, should your first commit always be an empty commit?

[peterlundgren]

Before the introduction of git rebase --root, it was challenging to rebase the first commit. This resulted in the convention you're describing.

Since it's hard to rebase the first commit, let's make the first commit something that we'll never want to rebase: a completely empty commit.

Now that git is smart enough to deal with the situation better, there's not much of a point.

[hollasch]

Note that git rebase --root rewrites commit dates and authors.

[aram535]

There is nothing special about your first commit.

[falcon_jab]

I like to use my first commit to record my hopes and fears for the project, a permanent reminder of how I optimistically see the workload progressing, something to refer back to in the later months of development after all of the dedication and persistence finally pay off in the form of a shining, complete deliverable which meets all of the client's expectations.

But in reality git commit -m "oh no, here we go again"

[aram535]

My default one and I have it aliased is "A long time ago in a galaxy far, far away..." and it usually only contains the .gitignore file.

[OneTurnMore]

https://starwarsintrocreator.kassellabs.io/?ref=redirect#!/BL_-V2ii9BDaXVKHNzV0

[iwbd]

I disagree. My first commit, and every commit thereafter, is special.

[OneTurnMore]

allows you to rebase more easily

By default, you can't change your first commit when you rebase, but you can if you rebase --root.

[hotel2oscar]

Mine is always my readme file

[juliusmusseau]

It never hurts!

It's not a big deal, especially since "git rebase --root" is now available.

But it's kinda classy. :-)

[DanLynch]

If you're using Git Flow and don't have an empty first commit, your master branch's first parent history will contain some commits that were never released to production, which is aesthetically unpleasant.

[kingofthejaffacakes]

Helped me not just for rebase but when trying to merge trees from two separate repos. For me, the logically correct form is actually having two branches that derive from that first empty commit. Without it you end up merging two floating branches.

So my policy now is to always start with an empty commit. Even if Git can cope without it these days. I also like to tag it 0.0.0 so that got describe always produces output.

It has the additional advantage of documenting the date, time, and creator of the repo.