What Is Git? Git vs GitHub, Explained

Git is the free, open-source version control tool that tracks changes to code over time; GitHub is a website that hosts Git repositories online and adds collaboration features on top. They're not the same thing — you can use Git entirely on your own computer without ever touching GitHub, and GitHub itself is just one of several companies that host Git repositories (GitLab and Bitbucket are two others). The confusion is understandable since most developers encounter both at once, but the distinction matters once you're trying to understand what a tool actually does.

What is Git?

Git is a distributed version control system — software that records changes to a set of files over time so you can recall, compare, and restore specific versions later. Linus Torvalds, the creator of the Linux kernel, wrote Git in April 2005 after the free license Linux kernel developers had been using for BitKeeper, a proprietary version-control tool, was revoked. According to Git's documented history, Torvalds needed something fast enough to apply patches in a few seconds, a distributed workflow similar to BitKeeper's, and strong protection against silent data corruption — and concluded no existing free tool met those requirements, so he built one.

"Distributed" is the key design choice that separates Git from older, centralized version-control tools like Subversion or CVS. In Git, every developer's local copy of a repository contains the entire project history, not just the latest snapshot. That means you can commit, branch, and review history without a network connection, and there's no single point of failure if a central server goes down — though most teams still agree on one copy (hosted on GitHub, GitLab, or similar) as the shared, authoritative version.

Git is free, open-source, and released under the GPL version 2.0 license. Per Git's own site, it's built to handle very large codebases quickly — it still manages the Linux kernel's own history, more than 1.4 million commits, in about 5.5GB — and in the 2022 Stack Overflow developer survey, 96% of professional developers reported using it, making it the default version-control tool across nearly all of software development today.

The core concepts: commits, branches, and the staging area

A few terms come up constantly once you start using Git:

• Repository (repo): A folder that Git is tracking, containing your files plus the full history of every change made to them.
• Commit: A saved snapshot of the project at a point in time. Each commit records the state of your files, a timestamp, a message describing the change, and a link back to its parent commit — forming a chain that is your project's history.
• Branch: A lightweight, movable pointer to a specific commit, typically used to work on a feature or fix in isolation before merging it back into the main line of development.
• Staging area (the "index"): A middle step between editing a file and committing it. Running git add moves changes into the staging area; git commit then saves exactly what's staged as a new snapshot — letting you commit only part of what you've changed.

A typical local workflow looks like: edit a file, run git add to stage it, run git commit to save a snapshot with a message, and repeat. None of that requires an internet connection or an account on any website — it's all happening on your own machine.

What is GitHub?

GitHub is a cloud-based platform, now owned by Microsoft, that hosts Git repositories and builds a web interface and a set of collaboration tools around them. GitHub describes itself as "the complete developer platform to build, scale, and deliver secure software," and lists repository hosting, code review, and collaboration as its core functions, alongside products like GitHub Actions for CI/CD automation, Codespaces for cloud development environments, and GitHub Copilot for AI-assisted coding. GitHub's own figures put its scale at more than 225 million developers, over 4 million organizations, and 800 million-plus repositories, with 90% of the Fortune 100 using the platform.

In practice, GitHub adds the features most teams actually live in day to day: pull requests (a structured way to propose, review, and discuss code changes before merging them), issues (lightweight project and bug tracking tied directly to the code), and a social layer — profiles, stars, forks — that makes it easy to discover and contribute to other people's open-source projects. None of that is part of Git itself; it's GitHub's own software built on top of a Git repository that GitHub happens to be hosting for you.

A quick history of GitHub itself

Per Wikipedia's history of the company, GitHub was founded by Tom Preston-Werner, Chris Wanstrath, P.J. Hyett, and Scott Chacon, and launched publicly in April 2008 after a short private beta, incorporated initially as Logical Awesome LLC. It grew into the dominant place to host open-source code over the following decade, popularizing the pull request as the standard way open-source contributors propose changes for review. Microsoft announced its acquisition of GitHub on June 4, 2018, in a deal worth $7.5 billion, which closed that October. Since then, GitHub has operated as a largely independent subsidiary while Microsoft has leaned on it heavily for AI-assisted development, most visibly through GitHub Copilot, which now competes with AI-native editors like Cursor and agentic tools such as Claude Code.

Cloning, forking, and pushing: how Git and GitHub work together

A few more terms make more sense once you see Git and GitHub working side by side. Cloning is a Git operation — running git clone <url> downloads a full copy of a repository, including its entire commit history, from wherever it's hosted (GitHub or otherwise) onto your own machine. Forking, by contrast, is a GitHub-specific (and GitLab/Bitbucket-equivalent) feature: it creates your own independent copy of someone else's repository on GitHub's servers, which you can then clone, edit, and eventually propose merging back via a pull request. Pushing and pulling are Git commands that sync commits between your local repository and whichever remote copy — on GitHub or elsewhere — you've configured as a destination.

Put together, a typical open-source contribution looks like: fork the project on GitHub (a GitHub action), clone your fork to your computer (a Git action), create a branch and commit your changes (Git), push the branch back to your fork on GitHub (Git), then open a pull request asking the original project to review and merge it (GitHub). Every step that touches your own machine is Git; every step involving review, discussion, or the web interface is GitHub.

GitHub isn't the only place to put a Git repository

Because Git itself doesn't require any particular hosting service, several companies compete to host Git repositories and add their own tooling on top. GitLab offers a similar feature set to GitHub — pull requests (called "merge requests"), CI/CD pipelines, and issue tracking — and is popular with companies that want to self-host the entire platform on their own servers. Atlassian's Bitbucket integrates tightly with Jira and Trello for teams already using Atlassian's project-management tools. Self-hosted options like Gitea and GitLab Community Edition let an organization run the equivalent of "GitHub" entirely on its own infrastructure, with no third party involved at all. Whichever host a team picks, the underlying Git commands — clone, commit, push, pull — work identically, because they're talking to Git, not to any particular company's product.

Why the two get confused

Most developers' first real exposure to version control is also their first exposure to GitHub, so the two names get used interchangeably in casual conversation — "push it to Git" really means "push it to the GitHub repository using Git." It doesn't help that GitHub's own product name borrows "Git" directly, or that tools like VS Code and AI coding assistants surface both Git commands and GitHub-specific features (like pull requests) side by side in the same panel. The practical test: if you're talking about committing, branching, or merging on your own machine, you mean Git; if you're talking about a pull request, a GitHub Issue, a star count, or GitHub Actions, you mean GitHub. The same confusion shows up with other hosts, too — "push it to GitLab" or "open a Bitbucket pull request" both describe the exact same underlying Git operations, just through a different company's web interface and terminology (GitLab calls a pull request a "merge request," for instance, even though it does the same job).

Do you need GitHub to use Git?

No. Git works perfectly well with no hosting service at all — many developers use it purely locally, or push to a private server their own company runs. What GitHub (or GitLab, or Bitbucket) adds is a shared, always-available copy of the repository that teammates can push to and pull from, plus the web-based review and automation tools most modern teams rely on. For a solo project or a quick experiment, plain local Git is often all you need; for team collaboration, open-source contribution, or CI/CD pipelines, a hosting platform is where almost everyone ends up. Git itself also keeps evolving independently of any host — recent Git releases have continued adding features and security fixes with no dependency on GitHub, GitLab, or any other platform.

Bottom line

Git is the engine; GitHub is one of several dashboards built on top of it. Learning Git — commits, branches, staging, merging — is a skill that transfers to any hosting platform or none at all. Learning GitHub's specific features — pull requests, Issues, Actions — is learning one company's product built on that engine. If you're new to version control, start with Git itself before worrying about which host to use; the commands are the same no matter where the repository eventually lives.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage