Devising a Git Repository Naming Convention

I’ve been around revision control for years, but it wasn’t part of my workflow until recently. Naming a repository without altering my project structure held me back. No more.

The semantics component of the Web Standards Project forever rewired my brain. Applying structure and meaning to things seeped into all my thinking. It’s not a paralyzing process internally, but ignoring it feels lazy. Thanks Zeldman. This vexes me.

On GitHub each repository needs a name, so naturally it has to meet these criteria:

  1. Descriptive
  2. Readable
  3. Consistent
  4. Contextual
  5. Future-friendly
  6. Extensible
  7. Reusable

We all think this way. Right guys?

For many Git projects I can’t discern anything from the name. Surely there’s a standard to follow? Nope. Letter casing and punctuation are oddly devil-may-care for a development construct. So I tweeted and Bryan Veloso of GitHub answered:

My Git projects are usually for websites though, so many languages are in play. We concluded modeling after the domain makes sense. ➔ ➔

For other projects, I’m inclined to keep the lowercase and dashes pattern:


More perfect

The GitHub for Mac ‘Clone In Mac’ feature creates a new folder named for the repo — potentially breaching a meticulously crafted project folder. I’m terribly vexed.

Git’s command line swoops in to save the day and my sanity:

# Clone the repo into a new folder named after the GitHub project
git clone [email protected]:username/project-name.git

# Clone the repo into a new folder named 'zebra'
git clone [email protected]:username/project-name.git zebra

# Clone the repo into the current directory (must be empty)
git clone [email protected]:username/project-name.git .

Now go forth and name/clone Git projects like a standardista.

Discourse Gravitated