Perhaps one of the most important aspects of API development is source control. Proper implementation of source control can lead to more efficient, effective development, with fewer bugs, dependency conflicts, and operational errors.

One of the most popular forms of source control in the modern development environment is GitHub. According to official figures, Github boasts a community of 11 million people, with 27 million current projects. Today, we’re going to broach exactly why Github is so popular, how it can be integrated into modern API project development, and why one might consider doing so.

What is Source Control?

Source control traditionally allows for the management of source files and components; this entails creating a master file, file hierarchy, or file system that is then controlled and collated between various versions of the files being edited. Each time a file is edited, a revision is kept, allowing not only for work to be saved and preserved, but for historical records to be kept in case a revision must be rolled back due to a bug or error.

This rather stringent definition of source control is somewhat dated, however; in the modern era of collaborative development, source control is far more focused on continuity than it is in preservation.

Why Developers Love Github

Github is an incredibly popular service, and there are quite a few reasons for its beloved status in the web development community.

Collaborative Editing

With so many developers and editors active in a single project, a group effort can be very daunting — how can a revision specific error be highlighted, versioning maintained, and validity of the original file checked?

Enter Github. GitHub allows for the collaborative power of multiple developers on the same project, while allowing strict versioning and source control. While a semblance of control is important to maintain continuity, GitHub has the added (and incredibly important) benefit of making code development within its system more agile, reducing response time and increasing quality.

When an editor makes changes to the original source code, this is kept as a revision, and is tied directly to their IP or user account. This directly ties innovation with responsibility, and is a sort of built-in error checking system — if a revision causes functionality to fail, it can be rolled back with minimal disturbance to the code platform.

When a new project is created using the source code as a base, it is called a fork, allowing for multiple concurrent projects to sprout from the same code base, encouraging creativity while preventing the feature and scope creep that dooms many self-managed projects.

Similarly, projects can be merged when opted for by both developers. This allows for development to be forked into a different project, where users can error check, collaboratively add code, and manage new features. Once commits, or changes, are integrated into the branch or discussed through a Pull Request, these commits are then added to the original project.

Issue Tracking and Resolution

What about projects that don’t require collaborative editing? What about private, small team affairs? GitHub has a lot to offer these types of teams, as well. One of the greatest of these offerings is the integrated issue tracking system.

Any project will inherently have issues that arise during development — with Github’s integrated issue tracking, tickets can be created for these issues using a wide variety of keyboard shortcuts and shorthand systems. These issues can be sorted by age, update time, and number of comments, and can be filtered by open or closed status, labels, milestones, and assignees.

While this is extremely useful for collaborative editors as well, this tool is simply indispensable for startups, small teams, and individuals. Whereas large collaborative environments will almost always eventually weed out issues and errors, smaller teams have to effectively track issues in order to not be overwhelmed by the large number of items they are tracking. With two or three developers handling hundreds of errors without a proper tracking system, something will fall by the wayside.

Community

Perhaps most importantly, GitHub is by definition, form, and function a development site based in community. With so many active users over so many projects, having a site that brings together disparate developers working on their own projects and materials not only amplifies the decisions, choices, and talents of those individual developers, but creates a massive pool of development talent that we’ve previously touted as incredibly important.

This pool of creative and technical talent, when leveraged through forks, merges, and pull requests, can be focused into far more effective and efficient development than personal approaches. Additionally, the fact that each developer is working on their own materials creates an environment of developing for future functionality, a focus on vigilant consistency, and an extremely effective methodology of validation and reporting.

As an added benefit, the Github community is necessarily one of common methodology. For this reason, there is often an added benefit of having an in-built internal culture of security — after all, when developers share responsibility for a code base, nobody wants their code to be responsible for a massive security vulernability or failure in P2P datastream encryption.

Language and Platform Agnostic

One of the most attractive prospects of GitHub is the fact it is truly agnostic. Whether a developer is creating a REST-centric API, utilizing the power of quasi-experimental languages like Go, or using relatively proven languages such as Scala and Java, GitHub supports the inclusion of your application.

Unlike other platforms that are “agnostic” within a broadly defined scope (i.e., agnostic as long as the language compiles on iOS, agnostic as long as the language is primarily mobile-focused, etc.), GitHub is truly and completely agonistic, making it a wonderful tool for both learning and innovation.

Because the service can both be hosted privately (as in the case of Github Enterprise) or on the cloud, it’s truly mobile and agnostic in terms of basic functionality and support. Additionally, many services can be tied in directly to a project repository. As an example, GitHub can be connected to API Blueprint, allowing for direct and automatic updating as the project evolves.

General Benefits

The best argument for GitHub is really a non-quantitative one — its design supports developers. Many of the features of GitHub support the average workflow of a developer — which makes sense, given that Github was invented by a group of like-minded software developers.

GitHub supports open data, the concept that projects are more powerful when expanded upon freely. Github allows for a greater ecosystem of developers by its design. Iterative deployment is wonderfully done, as each new commit is recorded and can be forked into a new project.

While it could be argued that these aren’t universally good ideas for every single project, the simple power of collaborative, open-source development within a developer ecosystem is hard to quantify, but clearly beneficial to those who wish to employ and leverage it. For example, many API providers without endless engineering resources may rely on a thriving ecosystem of third-party libraries to help extend their API into various languages and platforms.

Caveats

It’s true that for some developers, using GitHub may not be an ideal option. Projects covered under NDAs (Non-Disclosure Agreements), for instance, will generally not use things like Github due to the transparency of the system; though there is a private repository option, this requires a service upgrade, and will often still not be acceptable for privacy concerns.

Even hosted documentation can be problematic — with the ability to fork, a malicious user could fork documentation, change it, and mark it as official despite the fact that it is not. There is no official way by which a repository can be summarily removed through copyright claims or due to malicious use, and pull requests to administrators or moderators can often take a very long time. Even if a repository is upgraded and made private, anything already forked before being turned private would still exist, and would in fact be more visible than the private repository.

Conclusion

Even with these caveats, many use-cases involving API development and maintenance fit well with the GitHub philosophy. GitHub is a unique approach towards development. Individual development definitely has its benefits — granular control and privacy — but collaborative editing, in most use-cases, is a superior approach.

A thriving community, powerful versioning support, and an integrated issue tracking service would make this is a wonderful choice all by themselves. Add in platform agnostic code hosting, a culture of security, and a powerful methodology of collaborative editing, and not using GitHub becomes a hard sell in and of itself.

Additional Resources

• API Management Using Github
• API Hosting Example – Basecamp
• Version Control on Github Repositories