How I use Git

I’ve gotten into the habit of using Conventional Commits syntax in most of my projects. It plays nicely with the release automation tools I use and I find the structured format makes it easier to write good commit messages.

For commit titles, I follow the same approach I mentioned in Titles and captions — they don’t need to be complete sentences.

This ties back to my general philosophy about things doing one thing, but it applies to Git too. I’ve found that commits and pull requests are easier to review — and understand later — when they stick to one main purpose.

If I catch myself writing a commit message with “and” in it — like “Fix the parser and refactor some tests” — I take that as a sign that I should split things up.

In most of my projects (websites are generally an exception), I do my work in pull requests. I’m pretty heavy on automation (maybe I’ll write about that someday), and PRs give me a chance to see how my changes will behave before they hit the main branch.

When I merge a pull request, I almost always use a squash commit. I find the details of how I got to the end result of the pull request just add noise to the history.

There are a few cases where I skip the squash and do a regular merge instead:

I’ve found it’s cleaner to think of Git repos as being one of two things: either source code (the recipe) or the finished product (what I’m building) — but not both at once. Whenever possible, I avoid setups where build artifacts get committed back into the same repo as the code that created them.

Take this website as an example: the GitHub repo contains all of the Asciidoc source files and the Antora configuration, but the actual HTML, CSS, and JavaScript that make up the live site? Those get built and published separately.