GitLab vs GitHub: same concept, different names
Intermediate
Why this matters
Teams change platforms, and instructions written for one are used on the other every day. Almost everything is the same idea under a different label, so knowing the handful of real differences means you can read either set of documentation without confusion.
What is identical
Git. Every command in Sections 4 to 8 and 11 to 12 behaves the same: clone, branch, commit, push, fetch, merge, rebase, tag. The remote is a URL, the protocol is HTTPS or SSH, and nothing in your local repository knows or cares which platform is at the other end.
That is worth saying plainly, because most of what you have learned in this course is unaffected by this lesson.
What is renamed
| Concept | GitLab | GitHub |
|---|---|---|
| Proposed change | Merge request | Pull request |
| The container for code | Project | Repository |
| Grouping | Group and subgroup | Organization, with teams |
| Automation | CI/CD pipelines, .gitlab-ci.yml |
Actions workflows, .github/workflows/*.yml |
| Automation unit | Stage and job | Job and step |
| Contributor role | Developer | Write |
| Admin-of-one-thing role | Maintainer | Admin |
| Code fragment | Snippet | Gist |
| Browser editor | Web IDE | github.dev |
| Board | Issue board | Projects |
The terminology map is the full version of this table, including the words Git itself uses.
What is genuinely different
Five differences change how you work, rather than what you call things.
1. Containers nest on GitLab; teams nest on GitHub. A GitLab project can live several groups deep, and access granted on a group applies to everything inside it. GitHub repositories always sit directly in an account, and access is organized through nested teams instead. GitLab organizes the code, GitHub organizes the people.
2. The roles are not aligned. GitLab's Maintainer manages the project, its members and its protected branches; GitHub's Maintain does not manage rulesets or collaborators, which is GitHub's Admin. Translating "make them a maintainer" literally gives someone the wrong access in either direction.
3. Review verdicts. GitHub has a blocking Request changes verdict; GitLab does not, and uses unresolved threads plus approvals for the same job. On GitLab, "unresolved threads block the merge" is a project setting; on GitHub, one reviewer's Request changes blocks it until cleared.
4. Automation shape. A GitLab pipeline is stages containing jobs, and every job specifies an image. A GitHub workflow is jobs containing steps, and steps often uses an action someone else published, which is a much larger ecosystem of ready-made pieces. Reading the other's file is easy; writing it takes a little learning.
5. Where the platform stops. GitLab ships more of the toolchain in the box: issues, boards, CI/CD, a container registry, security scanning and deployment environments are one product. GitHub is more modular, with Actions and the Marketplace filling the same gaps by assembly. Neither is better; it changes where you look for a feature.
Smaller things that catch people out
- Draft status: GitLab uses a
Draft:title prefix, GitHub a separate draft state. - Merge options: GitLab offers merge and squash; GitHub offers merge commit, squash and rebase.
- The default branch protection: GitLab protects
mainby default on a new project; on GitHub a new repository has no rules at all until someone adds them. - Issue closing:
Closes #12works on both, in the merge or pull request description. - Forks: identical in concept and in workflow.
- Personal tokens: GitLab has scopes, GitHub now has fine-grained permissions plus older scopes.
Moving between them
If you know one platform, your first day on the other is mostly finding where things are:
- Learn the two words that matter: merge request and pull request, project and repository.
- Find the equivalent of the page you use most, which is the list of proposed changes.
- Read the roles table and work out which role you have, because the names lie about their power.
- Open the automation file in the repository and read it; the vocabulary differs but the shape is recognizable.
- Keep the terminology map open for a week.
Common mistakes
- Translating roles literally. Maintainer and Maintain are not the same power.
- Looking for subgroups on GitHub. Repositories do not nest; teams do.
- Expecting a new GitHub repository to protect
main. It does not until someone adds a rule. - Assuming Request changes exists on GitLab. It does not; threads and approvals do that work.
- Believing the platforms differ in Git. They do not, at all.
Try it yourself
Goal: prove to yourself that the Git part is identical.
- Create a small repository on the platform you use less.
- Add it as a second remote in an existing clone:
git remote add other <url>. - Push a branch to it:
git push other my-branch. - Open the proposed change on that platform and note what its tabs are called compared with the one you know.
- Write down the three words you had to translate.
Expected result: the same local repository pushes to both platforms with the same commands, and the only differences you noted were in the web interface.
Show solution
Step 2 is the demonstration. A repository can have any number of remotes, on any number of platforms, because a remote is only a URL. Everything platform-specific happens after the push, in a browser.