back to list

Initial Commit.

Ah yes, the beginning. Inception. Origination. Genesis.

Depending on the kind of person you are, a project's beginning can be a big deal. How many times have we sat there as developers and planned out our next big project/ We've attended the meetings, we've sketched the schematics. We've had the numerous conversations around what we'll use as the front end stack. What's the API going to be written in? Which CSS framework? We've drank the coffee, and then the whiskey, and then the coffee again. And then, in one way or another, we receive the green light.

It is time, you say to yourself. It is time to get this show on the road.

You create your first file, or run some kind of generator that spits out various project config files Maybe it's some kind of boilerplate hello world template. Or you maybe even created it through Githubs Create repo guide. Whatever it is you've done, you've reached that time. It's time to commit. It is time to push. And what's in your mind is the first of many, many awesome commit messages. Either to yourself, or to lots of others that are not yourself.

Then this happens.

Best App Ever initial commit

Look. We've all been that guy. And it's ok. Theres nothing wrong with being that guy. It's just a commit message, it's going to all be overwritten soon anyway, right? And no one's ever going to look back on this and judge. Right? RIGHT?

Yes. Maybe. Who knows. You begin to ask yourself questions like "What if this project hits the big time?" What if everyone reads through this commit history?. Important questions indeed, so let's see what happens when we do just that...

Peering into the past

Running git rev-list --max-parents=0 HEAD --format=medium will give us the first commit of a repo. Is this useful in the real world? Probably not, but for the purposes of this article it's definitely coming in handy.

If we run this command git clone git@github.com:git/git.git && cd git && git rev-list --max-parents=0 HEAD --format=medium we can see Linus Torvalds' first commit message to git itself:

commit e83c5163316f89bfbde7d9ab23ca2e25604af290
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date:   Thu Apr 7 15:13:13 2005 -0700

    Initial revision of "git", the information manager from hell

Amazing.

And if we run it on the official PHP repo, we get this output (technically, I removed the SVN one):

commit 528006a3b49fd45d6b2803c7b7843b2e7d6929d6
Author: Dmitry Stogov <dmitry@zend.com>
Date:   Wed Feb 13 16:26:47 2013 +0400

    Open Source Release

Or Laravels?

commit a188d62105532fcf2a2839309fb71b862d904612
Author: Taylor Otwell <taylorotwell@gmail.com>
Date:   Wed Jun 8 23:45:08 2011 -0500

    initial commit of laravel!

Exciting stuff, and "Initial commit" is safe enough - but do you want to be "safe" or do you want to stand out? In an era where more and more voices are added to the development collective, it can sometimes feel like you should stand out. But you don't. Depending on your project, how your team works and the rest of it, your commit messages will likely be glanced at at best. Remember, it's the content of the commit, not the commit message itself that's more important.

Remember, it's the content of the commit, not the commit message itself that's more important. For personal projects the message isn't so important, just set the repo to private and write what the f&%k you want. Ultimately though, you're responsible for your own brand, so it's only natural to have a think about how that's coming across. Everyone has worked with the git commit -m "fixed some stuff" guy before. I've probably been that guy, and so have you. Nothing wrong with it, as long as everyone knows whats going on then theres really no issue.

A quick aside on some git working practices

When working on enterprise projects, i've found Conventional commits to be really useful. Highly recommended, read up on them, use them on large projects that need some help figuring out what does when where.

Reasons to use Conventional Commits, from the conventional commit docs :* Automatically generating CHANGELOGs.

  • Automatically determining a semantic version bump (based on the types of commits landed).
  • Communicating the nature of changes to teammates, the public, and other stakeholders.
  • Triggering build and publish processes.
  • Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.

Another thing I've gotten used to lately is writing commits using the present tense. Such as "fixes bug with foo". I've found this to be particularly helpful when going through commits to see exactly where something happened.

When working on agile projects, I've seen some teams prepending the ticket number to each commit, such as "TIK-41: fixes something in the thing". Personally I think this is too verbose, as you should already have the ticket number as part of your feature branch. But thats a discussion for another day.

I thought this was about the first commit?

Ok ok. Lets get back on track.

When thinking of alternatives to that boooooring initial commit, you can get sucked down a fairly large black hole looking for inspiration. It's unproductive, yet somehow compelling. And all of a sudden you're in a cycle where you're just determined to find the best initial commit mesage there will ever be.

Gif of Googling the best opening lines to books ever

I mean, no one is saying you can't use an opening Tinder line as the first commit to your new project 👀

For the longest time my go to first commit was the opening to one of my favourite books: git commit -m "The man in black fled across the desert, and the gunslinger followed." It's from The Dark Tower by Steven King. Amazing book series. This has gotten fairly stale over the years though, so sometimes I use the opening lyrics of probably the best song ever written by probably the best band ever formed...

git commit -m "I need to be myself" for your copying pleasure. And we can get to discussing music later.

Songs and books are great sources of inspiration, but what about others? Movies perhaps?. Hopefully you're getting the point of this article, which is to show you that an initial commit is more than just a meaningless message used for the intial conception of a repository of code. Initial commits are actually a vehicle for your creativity, and the options are endless. But if you aren't in the mood for coming up with your own, you can just use this line of code to grab a random one from https://www.whatthecommit.com :

git commit -m "$(curl -s http://whatthecommit.com/index.txt)"

and if you want to turn that into an alias:

git config --global alias.random-commit !"sh -c \"git commit -m '$(curl -s http://whatthecommit.com/index.txt)'\""

Then just commit it like this: git random-commit

There's even an npm module that will generate a random initial commit for you from a list. Because of course there is.

Initial commits are actually a vehicle for your creativity, and the options are endless.

Ok, maybe I'm overthinking this.

Sure, you could make your commits more purposeful, perhaps add the project description in there, or explain the intent of the project. Ultimately though, read the room. For professional reasons, git commit -m "Initial commit." works fine. On a personal project though, go nuts. Who knows, maybe one day you may even appear on the front page of commit logs from last night. Oh to be so lucky.