Three GitHub Features You’re Missing Out On

Did you ever have a friend you only ever saw in one place? Maybe it was a bar, your knitting club, or at the school gates. 

You think you have a pretty good handle on who they are. Then one day you see them in a different context. Suddenly you realize you know only part of that person. The woman with the hilarious stories is a police detective. The younger guy who doesn’t say much spends every Saturday night performing barbershop.

GitHub is that friend. You know GitHub as the place you host your code, review pull requests, maybe discuss issues. But there’s more. In particular, there are three key GitHub features that you’re almost certainly not using but that could make a big difference both to newcomers who want to contribute code.

Think about those times when you opened your first pull request on a project. Whether it was an open source project or a private repo at a new job, you probably wanted to make a meaningful difference but without taking too much on. 

Making that first merge is as much about learning the culture and conventions of the team or project as it is fixing a bug. How do you help newcomers to get started in a way that helps them feel like they’re doing something useful in a manageable way?

GitHub’s “Good first issue” label gives you a way to highlight those issues that help someone take their first steps with your codebase. For private repos, this can be a great way to help new developers on-board. In larger organisations, and especially those with an inner-source programme, the “Good first issue” label can help your colleagues in other teams to get familiar with your internal projects.

At this point, you might be wondering what’s so special about a label. Anyone can add a label to a GitHub issue. “Good first issue” really comes into its own for open source projects.

Anyone wanting to get started with your project can visit your repo’s /contribute page where all your good first issues are listed. Check out the contribute page for Node.js, as an example. And if a developer isn’t already familiar with a project, they can discover new opportunities through GitHub’s topics page. There you can browse “Good first issues” by categories such as machine learning or game engines.

Even better, though, GitHub uses what it knows about each user to add “Good first issues” that are likely to be a good fit and lists them on their Explore page. Go check out your own.

GitHub has done more to help people learn git than just about anyone else. GitHub’s Learning Lab makes it super easy to learn both git and GitHub.

But there’s way more to it than that. Learning Lab lets just about anyone create interactive tutorials that help developers to learn by doing. This means that you can use GitHub both to teach people and to learn new skills yourself.

Here’s how it works. As a course author, you create a course repo that includes the steps of your course and, crucially, the validation of whether the learner did the right thing or not. 

Each step in your course can trigger a webhook with a payload that includes the learner’s response. So, if the learner is asked to open an issue, Learning Lab would send a payload including the issue’s contents. Your course code then checks whether the learner did the right thing or not.

Creating your own courses is a great way to teach your technology to new developers, whether they’re new members of your team or potential users, by providing an interactive complement to “Good first issues”.

Continuous integration and continuous deployment are core parts of how many teams work. A successful commit to the right branch and a tool such as Heroku CI, for example, will run your testsuite against the code. If the tests pass, the commit gets merged. If not, the proposer gets to spend a while longer fixing their code. Add a tool such as Heroku Pipelines and you can automatically deploy compliant code to the environment of your choice.

But what about all those steps in a repo’s lifecycle that aren’t necessarily to do with whether a test passes or that occur before we run the testsuite?

GitHub Actions lets you define what should happen in response to certain events. Say someone opens a pull request on your master branch. You might want to check that the submitter has signed your contributor agreement before a human reviews the branch. With GitHub Actions, you can trigger your own code that takes the person’s GitHub username and checks it against your database of people who’ve signed the agreement. If they have, then the PR can proceed. If not, your code could close the PR and trigger an email asking them to sign the agreement before the try again.

Whether your code is open source or proprietary, you want it to be as easy as possible for newcomers to make useful contributions. “Good first issue”, Learning Lab, and Actions help you to take new contributors on a journey from their first pull request, through to learning the intricacies of your technology, to automating as much of their work as possible.