As an internal developer for Code School, my job is to implement new features, test the site, and improve our codebase. One of the questions I get asked most often is about how Code School uses GitHub on our team. So, with the launch of our new Mastering GitHub course, there’s no better time to share our process than now.
I think most of us at Code School would admit that our workflow has changed quite a bit since we first started using GitHub. Beyond the Git repository hosting, GitHub has also developed a suite of well-crafted tools. We have all been using these tools — like Issues, Pull Requests and Gists — internally but they’re also useful to discover new open source projects that fit our needs. GitHub also makes it easy to find help from software maintainers so that we don’t have to dig for answers in forums and email lists.
GitHub’s team collaboration workflow give us a boost in velocity and overall it improves communication within the team. This is crucial for our team because it helps us keep our students focused on learning with no disruptions. It was only a few years ago that being able to fork a repository, make quick changes, and submit a pull request would have seem far fetched — or at least tedious. Now, we go through this process sometimes dozens of time a day and we barely even notice. This has made iterative software development at Code School more focused and more … fun.
Of GitHub’s many helpful tools, the feature we use most is Issues. On our main repository for codeschool.com, which is made up of 12,220 commits, we’ve amassed over 2,270 Issues and 620 Pull Requests — most of which are thankfully closed. The fact that we can easily link to a specific line of code when creating and reviewing Issues allows us to point out specific problems to whoever authored the code. That, in turn, lends to better conversations about bugs or features because we can clearly establish a context.
I think the purposeful simplicity of Issues makes it an excellent reporting and communication tool for software projects, both public and private. Its simplicity lowers the usage threshold amongst teams. For example, we can easily mention a person or a team within an Issue, which we often do with our support and marketing teams whenever they need to be involved.
Whoever is mentioned will be notified via email (or chat) to help clarify the problem at hand, which saves time for everyone. We then have a single thread to communicate about what changes are needed, who’s working on them, and when the Issue is finally resolved. This leads to better feedback, allowing our team to know about resolved Issues immediately and keeping our customers better informed.
There are also a few features that the Code School team doesn’t really use (yet), like Releases. That’s mostly because we don’t maintain a lot of internally versioned libraries. Usually, I tend to stick to a simple change log. GitHub’s notification center and social aspects are also features I don’t find myself using very often. Stars offer a less noisy way to remember cool projects. However, the social features for teams, like Pulse, give Code School a great overview of our work load — how many things we’ve tackled this week, how many features we’ve deployed, and how many bugs were fixed.
I’ll follow up with a second post related to our specific GitHub practices, but feel free to go give our new Mastering GitHub course a play in the meantime.