GitHub has become the gold standard platform for sharing code with everyone from the person sitting next to you to a developer on the other side of the world. As a team or product grows, so does its need for organizational structure and security. But even if your project or group of collaborators is small, you’ll learn that GitHub’s robust features help you proactively control access to your code.
“But I trust everyone on my team!”, you say. “My code is open to the world!”, you decry. That’s fantastic! But you still need to understand and be mindful of the most common threat of all: accidental git mistakes. By paying attention to who has access to which code – and what kind of access they have – you can safeguard against the summer intern rewriting history in your master branch, or the CFO inadvertently updating the release tags. I’ve seen it happen, and it’s ugly.
In this article, we’ll review best practices around:
According to GitHub:
Organizations are shared accounts where businesses and open-source projects can collaborate across many projects at once. Owners and administrators can manage member access to the organization’s data and projects with sophisticated security and administrative features.
An organization might be a company, a non-profit group, or a coalition for some kind of initiative – be it technical or philanthropic. Organizations are essentially a way to put one or more repositories under a single umbrella, and then designate roles for people to do certain things with those repositories or the account in general. Organizations have three permission levels:
“Member” is the default role, and implicitly grants a certain level of access to do things within the organization, such as viewing and creating teams within the organization, participating in public team discussions, redacting comments, and more. Members are obviously the most common kind of role, so we’ll continue to dive into this further.
But what if someone needs access to one or more repositories within an organization, but you don’t necessarily want them to be able to do all of the things mentioned above? GitHub has you covered there too, with the outside collaborator role. This is perfect for a consultant, intern, or someone who is contract-to-hire.
Again, according to GitHub:
Teams are groups of organization members that reflect your company or group’s structure with cascading access permissions and mentions.
In GitHub, teams aren’t just an arbitrary, bureaucratic concept; they are useful for modelling permissions and workflows for the ways your team functions in the real world (or enforcing the way it should function). You can create as many teams as you want, nest teams to reflect organizational structure, and add members to one or more teams.
The type of access members of a team have to a repository can be controlled at the team level, which is not only easy and powerful from an administrative standpoint, but also helps keep your code secure. For example, technical writers may need read access to the code, but they probably shouldn’t have write access. Or, you might have a QA department with manual testers as well as test engineers, and thus different access levels. Beyond the the type of access for a single repository, you can also give or revoke access to new/different repositories to the entire team all at once.
Teams can be visible or secret. As the name suggests, secret teams are only visible by the members within them, as well as repository organization owners. This can come in handy if your organization has a sensitive watch list of some kind, or is piloting a top secret mission! However, note that secret teams cannot be nested under parent teams or have child teams.
Teams can be mentioned with the @ symbol just like users, and you can request a review from an entire team on a pull request!
Read/write/admin access is a pretty clear issue that usually gets easy buy-in from executives and code administrators. We’ve already discussed how you can control this access using organizations and teams, which minimizes the management effort. But you can take your code beyond IP safety, and also protect its integrity by setting up branch protections.
Branch protections allow you to further refine the blanket write access granted to a team or specific users for a specific repository. Branch protections guard against:
This is especially important for your main code line (i.e. the master branch). You may also wish to protect in-progress branches (i.e. the develop branch) or previously-released branches. After you protect a branch, you can make push exemptions – not only for members, but for teams too! This is called a branch restriction.
To make the pull request process easier for everyone, you can set up required reviews to prevent merging anything that has less than the number of approvals that you choose. GitHub also has a feature called a CODEOWNERS file. This gives repository owners & administrators the ability to designate members (or teams) to be automatically listed on any pull request containing changes to certain files. You can specify different kinds of files, directories, or patterns (like you would in a .gitignore file), as well as different members/teams for different branches.
You can also configure required status checks, which enforce additional requirements for pull requests, such as ensuring the proposed code is mergeable and that the code builds successfully in your continuous integration system. If you’re a team lead or architect who is solely responsible for reviewing your team’s pull requests, you’ll really appreciate this feature because you won’t waste your time reviewing changes that won’t ultimately build.
Git can be leveraged to build code in CI systems such as Jenkins, Travis, TeamCity, and more. To discover more about continuous delivery pipelines with Jenkins in particular, check out Building a Continuous Delivery Pipeline with Git & Jenkins. There is also a robust offering of GitHub plugins for CI systems. These integrations are designed to work with GitHub specifically, so you can interact with them via GitHub’s site.
At this point, you might be thinking, “I trust everyone on my team, and I’m not worried about them intentionally not following the code review process or sneaking in bad code.” I certainly hope so! However, in my experience, about 90% of these kinds of problems are introduced unintentionally, by mistake. 9.9% of the time, it’s a team lead or architect trying to fix a problem someone introduced, and 0.1% of the time it’s a bad actor.
I once accidentally navigated to a GitHub organization page for a company I had left about 6 months earlier, only to discover that I still had write access to all of their repositories! Lucky for them, I had my white hat on that day, and I promptly notified them that they had forgotten to remove me from the organization. I wondered how many other people still had write access, too!
It seems like common sense, but your offboarding process should contain a checklist which includes removing the person’s GitHub organization access. While most people leave on good terms and aren’t malicious, even the remote threat of a former employee having access to your organization’s code is a huge liability for you and your company!
A more subtle need, however, is to remove a member’s old team access when they move teams. Often times, we know we need to add them to a team so they can get access to certain repositories, wiki pages, etc. But that is also a good time to evaluate whether they should also be removed from teams that are no longer appropriate or applicable.
GitHub’s organization and team features will not only make your life easier as a manager or administrator, but also help protect your code from threats, whether they are unintentional or not. This advanced protection will have you sleeping like a baby, knowing that unauthorized 3:00 AM force pushes and failed builds are a thing of the past!
As developers, Stackify works with GitHub often. Visit Stackify’s GitHub page, and you’ll see they have quite a few repositories and is a big part of Stackify’s ongoing work. Thus, it’s pretty important that developers understand how to work with GitHub and the various possibilities for working with repositories (like controlling the size of your reports) and code. Along those lines, one thing you’ll be doing at least periodically is checking out a remote branch, so we put together a brief tutorial to cover the ins and outs of working with remote branches in Git.
With APM, server health metrics, and error log integration, improve your application performance with Stackify Retrace. Try your free two week trial today
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
