Skip to content
Knowledge Hub/Article
Article

What Is Git? GitHub vs GitLab Explained

We explain how Git works, its basic commands, how GitHub and GitLab differ, branching strategies, repository security and GitOps.

Oğuzhan Gerçek··10 min read
What Is Git? GitHub vs GitLab Explained

Short answer: Git is a free, open-source, distributed version control system that keeps the full change history of a project's files. Every developer has a complete copy of the project, history included (a repository); changes are recorded as commits, parallel work happens on branches, and branches come together through a merge. GitHub and GitLab are platforms that host Git repositories and add pull requests (merge requests in GitLab), code review and CI/CD on top. Both offer a version you can install on your own servers: GitHub Enterprise Server and GitLab Self-Managed.

What is Git?

According to git-scm.com, Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. In the Pro Git book's definition, version control records changes to files over time so that you can recall specific versions later. In centralized systems such as Subversion, the server is a single point of failure; in Git, every clone carries the project's full history.

Git stores data as a series of snapshots rather than differences, and most operations need no network access. Everything is checksummed with SHA-1 before it is stored and is then referred to by that 40-character value. According to the project's plans, in Git 3.0 the default hash for new repositories will be SHA-256 and the default branch name will be main; there is no release date yet.

How did Git start?

According to Git's history, the Linux kernel project began using a proprietary distributed version control system called BitKeeper in 2002. In 2005, the relationship between the kernel community and the company behind BitKeeper broke down, and the tool's free-of-charge status was revoked. The Linux development community, and in particular Linus Torvalds, then wrote its own tool. The goals were speed, a simple design, strong support for non-linear development with thousands of parallel branches, a fully distributed model and the ability to handle projects the size of the Linux kernel efficiently.

Core concepts: repository, commit, branch, merge

  • Repository: The project's files and their full history; the metadata and object database live in the .git directory.
  • Commit: A record of a change. A file is first modified, then marked for the next commit with git add (staged), and finally stored in the local database when you commit (committed).
  • Branch: According to Pro Git, a lightweight movable pointer to a commit; creating one is as cheap as writing 41 bytes to a file.
  • Merge: Joins two or more development histories. If the current branch is an ancestor of the commit being merged, Git moves the pointer forward without creating an extra merge commit (a fast-forward).
  • Rebase: Reapplies commits on top of another starting point and leaves a cleaner history. Pro Git's rule is clear: do not rebase commits that exist outside your repository and that others may have based work on.
  • Remote: A copy of the project hosted on a network; the default name for the server you cloned from is origin.
  • Pull request and merge request: According to GitHub, pull requests are proposals to merge code changes into a project, so changes can be discussed and reviewed before they are merged. GitLab calls them merge requests.

Basic Git commands

A typical daily workflow looks like this:

git init                           # new project: empty repository
git clone https://git.example.com/example/project.git  # copy a project
git switch -c feature/search       # create a branch and switch to it
git add search.py                  # stage the change
git commit -m "Add search box"
git push -u origin feature/search  # send the branch to the remote
git switch main
git pull                           # get the latest main
git merge feature/search           # merge the branch's work into main

git push sends local commits to the remote repository. git pull first runs git fetch to download changes, then merges or rebases them into the current branch. git branch lists, creates and deletes branches, and git switch switches between them.

What are GitHub and GitLab, and how do they differ?

Git is a tool; GitHub and GitLab are platforms that host Git repositories:

  • GitHub: According to its documentation, GitHub is based on the open-source Git; it hosts repositories in the cloud and supports planning with issues and code review with pull requests. Microsoft announced its agreement to acquire GitHub on June 4, 2018 and has since completed the acquisition. GitHub Enterprise Server is the self-hosted version of GitHub: you can deploy it on a hypervisor in your own datacenter or on AWS, Google Cloud or Azure, and keeping it up to date is the administrator's job.
  • GitLab: Its documentation covers planning, CI/CD, application security, deployment and monitoring alongside Git. The Community Edition is MIT-licensed, while the Enterprise Edition comes under GitLab's own, more restrictive license. There are three offerings: GitLab.com as SaaS, GitLab Self-Managed, which you install and run yourself, and the single-tenant GitLab Dedicated.

The vocabulary differs too: a pull request on GitHub is a merge request on GitLab, and the counterpart of GitHub Actions is GitLab CI/CD. In Stack Overflow's Developer Survey, run from May 29 to June 23, 2025, 81.1% of the 30,065 people who answered the question on collaboration and code documentation tools said they had used GitHub regularly over the past year, and 35.6% said the same of GitLab.

Branching strategies: trunk-based development and Git Flow

According to DORA, in trunk-based development each developer divides their work into small batches and merges it into trunk at least once a day. Its research-based criteria are three or fewer active branches, merging into trunk at least daily, and no code freezes or integration phases. Teams that follow these practices achieve higher software delivery and operational performance.

Git Flow, published by Vincent Driessen on January 5, 2010, rests on two main branches, master and develop, plus feature, release and hotfix branches. In a note added on March 5, 2020, Driessen suggests that teams doing continuous delivery adopt a much simpler workflow such as GitHub flow. In his view, Git Flow can still fit software that is explicitly versioned or that has to support multiple versions in the wild.

Git security: leaked secrets, signed commits and protected branches

A password that gets committed stays in the history even if a later commit deletes it; according to Pro Git, nearly every action in Git only adds data. According to GitHub, the first step is to revoke or rotate the secret; even if you rewrite history, you cannot remove the data from other users' clones. Tools that catch leaks include:

  • GitHub secret scanning: Scans the entire Git history on all branches for hardcoded credentials such as API keys, passwords and tokens, and runs automatically for free on public repositories. Push protection is designed to stop secrets from ever being pushed.
  • GitLab secret detection: Secret push protection scans commits when you push and blocks the push if it finds secrets; pipeline secret detection runs in the CI/CD pipeline.

Practice PS.1 of NIST's SSDF (SP 800-218, version 1.1), published in February 2022, calls for protecting all forms of code from unauthorized access and tampering. Its examples include storing code in a repository with least-privilege access (see our IAM article), tracking every change with accountability to an individual account, commit signing, and having the code owner review and approve changes. In Git, git commit -S signs a commit, and GitHub marks commits signed with GPG, SSH or S/MIME as "Verified". Protected branch rules can require approving reviews, passing status checks and signed commits before merging, and in GitLab the default branch is protected by default.

Git, CI/CD and GitOps

A push or a pull request in Git can be the event that starts automation. GitHub Actions can run a workflow when a commit or tag is pushed or when there is activity on a pull request, and workflows are defined in YAML files in the repository. In GitLab, pipelines are configured in a .gitlab-ci.yml file and run on a push to a branch, a merge request or a schedule. We explain pipeline stages in our CI/CD article and the DevOps approach in our DevOps article.

The OpenGitOps principles (v1.0.0) carry the same idea into operations: the desired state is expressed declaratively and stored immutably and versioned, with its complete history. Software agents pull that declaration from the source automatically, continuously observe the actual state and try to apply the desired state. We cover IaC and drift in our Terraform and Ansible article and the desired-state loop in our Kubernetes article. We build pipelines in our DevOps & CI/CD Enablement service and handle day-to-day operations in our DevOps solutions service.

Frequently asked questions

What is GitHub? A platform that hosts Git repositories in the cloud and supports software development with issues, pull requests and GitHub Actions. It is owned by Microsoft.

What is the difference between Git and GitHub? Git is the version control system that runs on your computer; GitHub is a service that hosts Git repositories and adds collaboration tools on top. You can use Git without GitHub.

What is GitLab? A software development platform that offers planning, CI/CD and security scanning alongside Git repositories. It runs in the cloud as GitLab.com or on your own servers as GitLab Self-Managed.

What are the basic Git commands? git init and git clone create or copy a repository; git add and git commit record changes. git push and git pull sync with a remote, while git branch and git merge manage parallel work.

What is the difference between a pull request and a merge request? Both are proposals opened for review before code changes are merged. GitHub calls them pull requests; GitLab calls them merge requests.

Sources