GitLab is very similar service to GitHub, but doesn’t have as many users with around 30 million registered users according to the company.

It was launched in 2014, 6 years after GitHub.

GitLab offers all the major features that GitHub does, including:

• Allowing users to fork a repo (copy it so they have their own version they can work on).
• Submitting pull requests, known as merge requests in GitLab.
• Publishing wikis, changelogs, issues and bug tracking.
• Continuous integration.
• GitLab pages (same idea as GitHub pages).
• Etc.

One of the main differences between the two services is that GitLab is open source which means you can download the source code from here and self host the service on your own servers or on a cloud provider.

The second key difference is that GitLab offers its own deployment platform built on Kubernetes. With GitHub you would need to use an external platform, like AWS or Heroku and trigger your deploys there.

Github Flow

The GitHub Flow is a lightweight workflow. It was created by GitHub in 2011 and respects the following 6 principles:

1. Anything in the master branch is deployable
2. To work on something new, create a branch off frommaster and given a descriptively name(ie: new-oauth2-scopes)
3. Commit to that branch locally and regularly push your work to the same named branch on the server
4. When you need feedback or help, or you think the branch is ready for merging, open a pull request
5. After someone else has reviewed and signed off on the feature, you can merge it into master
6. Once it is merged and pushed to master, you can and should deploy immediately

Advantages

• it is friendly for the Continuous Delivery and Continuous Integration
• A simpler alternative to Git Flow
• It is ideal when it needs to maintain single version in production

Disadvantages

• The production code can become unstable most easily
• Are not adequate when it needs the release plans
• It doesn’t resolve anything about deploy, environments, releases, and issues
• It isn’t recommended when multiple versions in production are needed

GitLab Flow

The GitLab Flow is a workflow created by GitLab in 2014. It combine feature-driven development and feature branches with issue tracking. The most difference between GitLab Flow and GitHub Flow are the environment branches having in GitLab Flow (e.g. staging and production) because there will be a project that isn’t able to deploy to production every time you merge a feature branch (e.g. SaaS applications and Mobile Apps)

The GitLab Flow is based on 11 rules:

1. Use feature branches, no direct commits on master
2. Test all commits, not only ones on master
3. Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel).
4. Perform code reviews before merges into master, not afterwards.
5. Deployments are automatic, based on branches or tags.
6. Tags are set by the user, not by CI.
7. Releases are based on tags.
8. Pushed commits are never rebased.
9. Everyone starts from master, and targets master.
10. Fix bugs in master first and release branches second.
11. Commit messages reflect intent.

Advantages

• It defines how to make the Continuous Integration and Continuous Delivery
• The git history will be cleaner, less messy and more readable (see why devs prefers squash and merge, instead of only merging, on this article)
• It is ideal when it needs to single version in production

Disadvantages

• It is more complex that the GitHub Flow
• It can become complex as Git Flow when it needs to maintain multiple version in production

Similarities between GitHub and GitLab

Here are some of the key similarities between GitHub and GitLab:

• Tracking. Both GitLab and GitHub offer fantastic issue tracking capabilities that enable status changes and the ability to assign owners to each issue. Additionally, bug reports can be sent instantly to both GitLab and GitHub.
• Issues. Both GitLab and GitHub are capable of quickly setting up the status, assignees, or milestones for multiple issues at a time to easily filter them based on any type of property.
• Integrations. Both GitLab and GitHub have a wide array of 3rd party integrations available to strengthen workflows and boost productivity. GitHub has a marketplace of 3rd party integrations for specialized tools and applications. GitLab offers numerous integrations for development and DevOps teams.
• Support community. While GitHub’s support community is considered slightly bigger, both solutions offer a strong community of developers who contribute to the update and upkeep of GitLab and GitHub.
• Labels. Both GitLab and GitHub provide easy inclusion of labels to provide a simple method of categorizing issues, merge requests, or epics based on descriptive titles such as “bug” or “documentation” which are very helpful for tracking.
• Description templates. Developers can add a description template to issues or merge requests in both GitLab and GitHub by selecting a template for effective communication.
• Enterprise solutions. GitLab and GitHub offer enterprise-level capabilities for development teams and organizations. While GitLab is better positioned in the enterprise environment, both solutions fare well in enterprise settings.
• Wiki-based project documentation. Both GitLab and GitHub keep a separate system for documentation that is called Wiki and is built right into each project as a separate Git repository.
• Edits. Both platforms allow upstream maintainers to collaborate on a source branch and edit into a fork. This way, maintainers can make small fixes or rebase branches before merging, which reduces iterations of community contributions.
• Merge approvals. Both platforms enable developers to ensure merge requests are approved by one or more people. These approvals allow the development team to pre-define the list of approvers for every merge request in a project to improve coding quality.
• Revert commits. GitHub and GitLab are capable of reverting commits or a single merge request via each platform’s UI.

Other key features that are shared between GitHub and GitLab include pull request, fork/clone repositories, code review, and markdown, to name some more – you can view a more detailed list here. Next, we are going to focus on the differences between the two platforms.

Difference between GitHub and GitLab

Here are some of the key differences between GitHub vs GitLab:

• Built-in Continuous Integration/Delivery. GitLab is known for its built-in Continuous Integration/Delivery for free, which is something that GitHub does not offer. Instead, GitHub’s offering lies in 3rd party integrations that enable Continuous Integration/Delivery.
• Innersourcing. With GitLab, internal projects allow developers to promote inner sourcing of internal repositories – this is something that is not offered by GitHub.
• Authentication. In GitLab, permission is granted based on people’s roles while in GitHub developers can grant read or write access to specific repositories.
• Data import/export. GitLab offers far more detailed documentation on how to import/export data from external vendors while GitHub’s documentation is not as detailed. GitLab is capable of importing projects and issues from more sources than GitHub can. With that being said, GitHub does offer a tool called the GitHub Importer to bring in data. With regard to exporting, GitLab offers a comprehensive solution to export wikis, project repositories, project uploads, webhooks and services, and issues. On the other hand, GitHub is slightly more restrictive in terms of export features.
• Deployment platform. GitHub does not come with a built-in deployment platform and requires a 3rd party integration with an external application to deploy applications. On the other hand, GitLab leverages Kubernetes for a seamless deployment experience.
• Private repositories. GitLab offers free private repositories for open source projects while GitHub does not.
• Comment tracking. GitHub is capable of providing the full history of a thread of comment updates – GitLab does not support this.
• Issue transport. In GitLab, developers can easily move issues between projects – all links, history, and comments are copied to be referenced in the original issue and the newly moved issue.
• CSV file export. GitLab is capable of exporting CSV files of issues to default notification email addresses as attachments.
• Confidential issues. GitLab’s Confidential Issues module creates confidential issues that are visible only to project members with Reporter access level or above.
• Issue weights and milestones. In GitLab, developers can assign weight to issues to manage them via Agile practices, which is not something that can be currently done by using GitHub. Additionally, GitLab, unlike GitHub, allows developers to create and manage milestones at project and group levels to represent an Agile sprint or a release.
• Burndown charts. Unlike GitHub, GitLab offers Burndown Charts as part of milestones that allow developers to track progress during sprints or while working on new software versions.
• Application performance monitoring. GitLab collects and displays performance metrics for applications to determine the impact of a merge and monitor production systems.
• Cycle analytics. GitLab provides a dashboard to perform analytics about time, planning and monitoring activities.
• Monthly new features. GitLab is known for its monthly updates of new features and improvements that are made religiously on the 22nd of each month.
• Bare metal servers. GitLab can run on bare metal servers for full control of disk I/O, CPU, RAM, and more for easy horizontal scaling.

Besides the ones we just pointed out, the main difference between GitHub and GitLab rests in the philosophy each platform presents. GitHub is more focused on high availability and infrastructure performance while GitLab is more focused on including as many features in a robust and well-integrated platform for a complete and centralized DevOps process.