What is Git?
Git is a Version Control system that allows you to track the changes you make to files stored in a repository.
Git is most commonly used by programmers to store and track changes to their code, but is also used for tracking changes and progress on other text files or data sets – for example, it has become popular with Ph.D. students use it to store and manage the writing of their thesis’, and with authors writing complex books with many revisions.
Terminology
Here’s a quick rundown on the basic terminology regarding Git, and Git features:
Version Control
Version Control is a system that will track the changes made to files over time. Git is a Version Control system.
Version Control is useful as it allows you to look at the state of your project at a particular time, so that you can fix mistakes, or see where something went wrong, or simply so that you can go back to an earlier version of your code if you introduced a bug.
Repository
A repository is the vessel in which you store your tracked files, the commits that create them, and the branches which organize those commits.
Remote Repositories
Repositories can be synchronized between devices and users on a network. GitLab and GitHub act as remote repositories – acting as a central store for your projects so that they can be shared with others, or often as a method of backing up the project’s source code. These remote repositories can then be synchronized with your local device, allowing you to push code changes from your device to the central store.
Commit
A commit is a point in history in your repository. It contains all of the information about the files that have changed since the last commit. This could be editing, deleting, or creating files. Multiple changes can be stored in a commit.
Branch / Merge
Branches allow you to work on your code independently of other ongoing changes – creating an offshoot in the history which you can modify independently without worrying about it affecting your code. Any changes made can later be merged back into the main history (referred to as the master) if you’re happy with the changes.
For example, you may be working with a group of people on a project. You want to experiment with ‘Feature X’, but don’t want to risk interrupting the work of the others in the group if ‘Feature X’ breaks something in the project code. You’d create your own branch of the project, where you could experiment as much as you want without disrupting anyone else’s work on that project, and if ‘Feature X’ turned out to work well, it could be merged into the master branch which everyone is collaborating on.
Pull Requests
Before you merge those changes, however, you might want to let your project partners know what you’re up to. A pull request does just that – a feature to allow you to discuss your changes before you merge them into the main project.
Master
The main development branch of the project/repository. Every repository has a master branch by default.
Forking
Forking allows each developer to have their own development copy of the repository (the fork) so that they can work independently – further insurance that they don’t step on each other’s toes when working collaboratively.
About GitHub
GitHub and GitLab are both Git Repository hosting services that also provide collaboration tools and their own distinct features.
GitHub is the most popular Git host. It was started in 2008 and is currently owned by Microsoft.
Other collaboration features include project wikis, bug tracking, and public profiles.
About Git Lab
GitLab has been around since 2014 and shares its major functionality with GitHub (because they’re both based on Git, of course), but has a different target audience.
GitLab is a bit different and is geared more towards private projects where you want to work privately, or closely with a team. GitLab provides a full platform for collaborating on a software project and deploying it to hosting. GitLab holds fewer public projects but is perfect for your own projects that you may not want to share with the world.
Unlike GitHub, Gitlabs free tier allows for unlimited private repositories, so is more appropriate for your personal projects.
The Comparison That Matters
The core features of GitHub and GitLab are the same for the end-user – they both allow you to host, manage, sync, and share your code in much the same way. They both offer documentation and issue tracking tools.
I could put together a big table about the advanced features of each, but if you’re here that’s not what you’re after, you want to know which one to use while you’re getting started.
Here’s the main difference between the two:
The majority of GitHub projects are public, and it’s most common use is hosting public open-source repositories. Private repositories are available but limited for free users. Many GitHub users use their GitHub profile as a sort of public resume to show off the things they are building and the projects they have contributed to.
GitHub is intended mostly for the hosting of public repositories and is limited for private use unless you pay
GitLab is better if you want to keep your projects private, as it allows for unlimited free repositories. It also gives you more control about who you give permission to view your project to if you do decide to share it.
That’s really the nitty-gritty of it. And there’s nothing to stop you from using both for different kinds of projects.
