About Gabe Blair

I am a software engineer with 15+ years of experience in various technologies and practices, including object-oriented design, DevOps, cloud infrastructure, Ruby, Nodejs/Javascript, and PHP.

I’m also a musician and have a record label.

Why I built this site

Like others my age, I remember a time before git existed, and not only that, I remember the days before “coding” existed as it does today. I saw how Git completely changed the reality of working together collaboratively on software, and brought in a new era for development. I truly believe Git is one of the great inventions of our age, and that it has already dramatically changed the world (mostly) for the better. I think the majority of the most influential businesses and platforms online would not exist in the form they do today without Git.

I’ve encountered engineers in all stages of their careers who exhibit a fear of “breaking things,” “losing work,” “getting stuck,” etc., with Git. General awareness of how to use Git has gotten much better over the years, but there is still a widespread lack of understanding of the power and flexibility of this amazing free software. I’ve seen developers treat Git commits as fragile, precarious artifacts of the painstaking work we do; deep down, there seems to be a belief that commits should not be disturbed, lest we accidentally lose work forever, or munge it up so badly that we have to start over. Or, too often, Git is an afterthought, a quick tool to share code and store it somewhere.

This website is an attempt to increase awareness that, without having to go super deep into Git knowledge, you can cultivate a rich and valuable commit history that makes sense to you, other engineers, business teams, and even (if you want) users. Especially for solo developers or those on small teams, I hope you find something useful here!

I fully acknowledge there are a multitude of methodologies for using Git within a team of any size, and that the ideas contained in this site represent only a subset of those. For example, the approach I present here seeks to avoid merge commits, while it’s clear that the maintainers of Git itself do not feel this way. What is good for small teams may not be right for large open-source or enterprise projects, etc. However, the concepts presented here are invaluable in any context. Knowing how to get your own commit(s) to be fast-forward off a target branch, to not be afraid or feel out of control when using Git, is part of being an effective engineer, whether in a team of 1 or 1000.