These questions are definitely worth asking. After all, Microsoft was willing to shell out $7.5 billion dollars to acquire GitHub back in 2018, so developers of all skill levels should be sitting up and taking notice. But the truth is that Git and GitHub are connected much more closely than Java and JavaScript — but with some key differences setting them apart.
Read on to know the difference
What’s the difference between Git and GitHub? Well, to answer that, we’ll be taking a closer look at each one. But before we do that, let’s first discuss the concept of version control.
Version Control
What Is Git?
First developed back in 2005, Git is an extremely popular version control system that is at the heart of a wide variety of high-profile projects. Git is installed and maintained on your local system (rather than in the cloud) and gives you a self-contained record of your ongoing programming versions. It can be used completely exclusive of any cloud-hosting service — you don’t even need internet access, except to download it.
Compared to other version control systems, Git is responsive, easy to use, and inexpensive (free, actually). Git is also specially designed to work well with text files — which, if you think about it, is what code actually is. But one thing that really sets Git apart is its branching model. Branching allows you to create independent local branches in your code. This means you can try out new ideas, set aside branches for production work, jump back to earlier branches, and easily delete, merge, and recall branches at the click of a button.
And that’s it. Git is a high-quality version control system. But what about GitHub?
What Is GitHub?
In the discussion of Git vs. GitHub, it’s been said that GitHub is to Git what Facebook is to your actual face. What’s that mean? Well, it means that while Facebook is kind of like an online face database (of sorts). GitHub is designed as a Git repository hosting service.
And what exactly is a Git repository hosting service? It’s an online database that allows you to keep track of and share your Git version control projects outside of your local computer/server. Unlike Git, GitHub is exclusively cloud-based. Also unlike Git, GitHub is a for-profit service (although basic repository-hosting features are available at no cost to those who are willing to create a user profile, making GitHub a popular choice for open-source projects).
That’s because, in addition to offering all of the features and advantages of Git, GitHub expands upon Git’s basic functionality. It presents an extremely intuitive, graphically represented user interface, and provides programmers with built-in control and task-management tools. Additional features can be implemented via the GitHub Marketplace service. And because GitHub is cloud-based, an individual’s Git repositories can be remotely accessed by any authorized person, from any computer, anywhere in the world (provided it has an internet connection).
Through GitHub, you can share your code with others, giving them the power to make revisions or edits on your various Git branches. This makes it possible for entire teams to coordinate together on single projects in real-time. As changes are introduced, new branches are created, allowing the team to continue to revise the code without overwriting each other’s work. These branches are like copies, and changes made on them do not reflect in the main directories on other users’ machines unless users choose to push/pull the changes to incorporate them. There is also a GitHub desktop application available, which offers some additional functionality for experienced developers.
Other Git repository hosting services also exist; GitLab, BitBucket, and SourceForge are all viable GitHub alternatives, and GitLab even offers a built-in option which allows GitHub users to migrate their projects directly into GitLab.
GitHub is the standard nowadays not only as a source code repository but also as a place of collaboration for open-source projects: a lot of the interaction between project members and the wider community is made through GitHub Issues or Pull Requests.
As such, GitHub is often referred to as “the Facebook of open-source development”, and rightly so. GitHub has made the act of forking a project as easy as clicking on a button, arguably lowering the entry barrier for people looking to fix bugs on projects they use, making it trivial to also share this fix back upstream.
But, ironically, GitHub itself isn’t open-source.
Because of that, we decided to give GitLab a try when we bootstrapped Qaclana, and here is a list of things we’ve learned during this last months.
GitLab is a complete solution and the hosting of Git repositories is only part of the story, making it easy to get started. Deciding which CI tool or issue tracker to use can be postponed, so that you can just focus on your core project.
The integration with their own CI tool makes it easy to visualize the builds and pipelines. The killer feature, though, is `gitlab-runner`: just install it on your machine and enable this local runner on GitLab’s CI/CD UI and, suddenly, you have your own build executor. This is helpful to speed up builds and to analyze build failures. To have something similar for projects hosted on GitHub, tools like Travis or CircleCI would have to be used.
GitLab’s Issue feature is very similar to GitHub’s, but its Boards view is a huge improvement, making it easy to move cards among columns. This can be done on GitHub using external tools like waffle.io, but having “one UI to rule them all” is a major win.
Those are two of the major differences for Qaclana, but we do see other features that might be interesting to people in other projects. For instance, the ability to start Kubernetes clusters à la CodeFresh for testing or staging environments look very interesting.
Another noteworthy and interesting feature is the Container Registry. We are using it only for pushing intermediate images for the build pipeline, but it could be interesting to have it to host the actual images for a project that won’t, or can’t, use Docker Hub.
During this last few months, we’ve seen features being implemented in GitHub which were first available in GitLab and vice-versa. Technically, they are very similar and close to each other, with major differences mainly in the philosophy: while GitHub focuses on high availability and performance of its basic core features, delegating tangential or complex features to external tools like Travis or Waffle, GitLab tries to incorporate all features on a single, well-tested and well-integrated package.
All in all, these last few months using GitLab felt like using a mature Git repository on-par with GitHub regarding its core features, plus a well-curated set of plugins, all being part of the same single, consistent UI.
The only missing “feature” on GitLab is the vibrant community that is present on GitHub. But perhaps that could change soon?
And you, what’s your take on GitLab?
Source link