GitLab vs. GitHub

GitLab vs. GitHub is a comparison posed by more and more developers. Each service provides many of the same features – including logos with ears – making the choice pretty difficult. So we’re asking questions around the PINT, Inc. web development office to understand these services and their intricacies in a more meaningful way.

What is Git?

Git is one of the most popular software configuration management (SCM) systems. Its specialization? Version control systems (VCS). It is the definitive service leveraged by our contending cloud services GitLab and GitHub. Git is free and open source, and while it facilitates a broad range of use cases and project requirements, the SCM has become synonymous with version control, or source control, because that’s inherently what it is.

Version control systems like Git, record changes to a file or set of files over time so that you can recall specific versions later.

The idea is simple. But Git’s implementation is arguably what sets them apart from their competitors. In their own eBook, the makers of Git detail nuances between their tool and other SCM products. One such detail: Git doesn’t merely note the differences between versions. In fact, it takes a snapshot of each file in a version, even if an individual file doesn’t change. Understanding how Git handles version control is essential to effective use of the tool, so please see their documentation for more details.

Git Applied

Git is a command line tool. If you aren’t familiar with the command line, learning Git might seem a bigger challenge than it’s worth. Especially if you aren’t a software engineer. Third party applications have emerged to give you the basics of Git in a GUI (graphical user interface). However, they leave out a lot of essential functionality you might need when things go wrong.

Git Glossary

Here are some basic key terms and functions to help you understand the context of Git.

• Repository or repo
  A file directory with all of your files. It will contain another directory (.git) which holds the version control information and other things. Repos come in two flavors: local and remote. This is really where the cloud-tasticness of Git is aptly tested. Local repos hold all of your personal changes to the codebase. Remote repos hold the collective code base that everybody can access. And this is where version control systems come in handy: resolving conflicts between local and remote repositories, and their users.

• Commits & Messages
  Initiating those snapshots is easy. A commit contains your file changes and associates a message with it for quick documentation.

• Branch
  A branch can be thought of as an edition of a repository. Typical branch names include dev, stage, master, which will correlate to development environments. The messiest Work In Progress branch would be dev, where all new changes are committed. Once work has been done on a branch (adding a new feature or fixing a bug), it will generally be promoted (see Pull/Merge Requests below) to the next level in the hierarchy, ending up on a production branch which will be deployed live. You can create as many branches as you want, depending on your workflow.

• Forking
  Forking is a GitHub-specific feature that copies a GitHub repository to your GitHub account. You can think of forking as creating a new branch with a different user.

• Cloning
  Cloning does exist natively in Git, and is the non-proprietary version of GitHub’s fork function. Cloning a repository makes a copy of an existing repository to your local workspace.

• Pull Request
  A way to let users know what changes you may have pushed to a particular repository. Once you send a pull request, other users can review your changes and incorporate them into their repositories. Much like a peer-review process. This is especially helpful during Quality Assurance review.

• Merge Request
  This is what GitLab calls a Pull Request, and if you think about it, it does seem to make more sense, because you’re not requesting to pull the code (you already have), you’re requesting that your changes be merged back into the original repository.

• Branch
  A typical site workflow consists of three main branches: dev, stage, and production (or master). But there can be as many branches as needed. It’s usually best if they are created as such, and then destroyed when their fixes are pushed back to a main branch.

See the Official Git Documentation for details.

Why should clients care about GitLab vs. GitHub?

Web development clients should care if their web development agency is using Git. It is a filing cabinet for code so you can go back to see what was done. However, it also provides a way to see code taking shape into a project (if you’re into that sort of thing). It was originally developed in 2005 by Linux devs, including Linus Torvalds. It is free under the GNU General Public License.

GitHub builds on Git. It was released to the public in early 2008 and became a Silicon Valley investment darling. Users embraced the interface and social networking aspects of GitHub: as of this blog post publishing, there are 12 million users. And there are public and private repository options that all live on GitHub’s network.

But when it comes to GitLab, you can host your repositories on your own or third-party servers. Interest in this option has grown in the last few years, and truly spiked in the last year or so.

The latest version of GitLab also boasts many enhancements in performance and features.

How is Git different than a CMS?

A content management system (CMS) is not antithetical to Git. The latter has version control as its primary function, while the former has its primary function rooted in maintaining content without the need for background knowledge in coding websites. However, some content management systems do have a type of version control (like PINT’s proprietary CMS, PWP), But they are not as robust as the options within Git.

How is GitLab different than GitHub?

Functionally, GitLab and GitHub share most feature-sets, the biggest difference is that the UI’s (User interfaces) are different. GitLab embraces a left-hand side navigation bar, whereas GitHub prefers to place navigational elements horizontally. GitLab can be self-hosted whereas GitHub cannot, and GitLab includes many useful integrations out of the box, such as Continuous Integration (also self-hosted), whereas GitHub will point you to additional third party services.

What are the advantages of GitLab over GitHub?

If you self-host GitLab the advantages are many:

• Your data/code never leaves your corporate firewall
• Less proprietary lock-in, you are not dependent on GitHub’s release schedule, features (private repos), or uptime.
• GitLab is free (as in freedom and beer)
• GitLab Workflow (Issues, Milestones, Merge Requests, etc)

Why is PINT using GitLab?

Yes. We have migrated from GitHub to GitLab.

We were approaching the max private repository limit for our service level, an upgrade would have doubled our monthly costs for GitHub. So the investment in GitLab was balanced out by the possibility of an expensive monthly GitHub subscription.

In addition, some people feel much more comfortable not outsourcing PINT-proprietary code/intellectual property. GitLab addresses this concern. We can also speed up deployment and testing because the majority of our developer toolset now lives inside of our datacenter.

What’s the Advantage for PINT clients?

Moving into GitLab posed a great opportunity for the PINT team to clean up our existing repos and enforce guidelines and standards for revision control. With a repo for every client/project, we can use GitLab as a central source of truth for code and assets, rather than having them separated. This will help eliminate any confusion on client projects when team resources shift.

Plus, the nature of Git’s snapshots saves on the storage point. We immediately have a record of code changes. And we immediately have backups. Admittedly, that is not the point of Git – true backups happen at a snapshot or filesystem level on the server. Nonetheless, if a major site revision is under way, we have the old site in previous commits so we can revert if needed.

GitLab vs. GitHub

Git is a great tool. It has its shortcomings. But many things do (like the ears on GitHub’s logo). Despite their small differences, GitLab vs. GitHub is less a comparison of the two services, and more a comparison of your current and desired environments and management styles for website and software development.

Works Cited: https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

Updated April 19, 2016 to address differentiation between GitLab vs. GitHub.