Using GitHub at Automattic

As a Happiness Engineer at Automattic, I try to be generally aware of things that are happening across the company — or at least in the areas that touch, where I do most of my work. It’s impossible to keep up with every detail, but I need to be ready to reach out to a variety of teams if something comes up that’s related to what they’re doing.

Over time, I’ve noticed myself turning to GitHub more and more during my daily work at Automattic. Whether they are developing code, tracking bugs, or sharing resources, many teams are now using it. You can find public GitHub repos for projects as varied as Jetpack, _s (a starter theme), Babble (a plugin for multilingual WordPress sites), and Legalmattic (legal documents used for (You can also browse all of the public Automattic repos if you’re curious!)

I was aware of the basic idea behind GitHub and how it worked, but up until about a month ago I only ever opened new issues or added to existing issues, to track reported bugs. Recently, though, I cloned a GitHub repo and learned how to switch between development branches to locally test out features that are under development. And yesterday, I finally committed and pushed new code to an Automattic repo for the first time!

It was nothing earth-shattering — just a modified piece of JavaScript to share with my support team, so we can experiment with tracking support issues in a different way. But it felt good to understand how the whole process works. (And, I won’t lie, I feel pretty badass every time I learn to do something new on the command line.)

In addition to Google searches and tests I did on my private repo, here are a few tutorials and references that helped ease my mind before I made that first commit: