Git vs GitHub: What's the Difference?

Git is version control software that runs on your computer. GitHub is a commercial web platform that hosts Git repositories and adds collaboration tooling around them.

They are not competitors, alternatives, or two names for the same thing. Git is the engine; GitHub is one of several services built on top of that engine. You can run Git without GitHub. You cannot run GitHub without Git.

Before you start

• Lesson 1 — What Is Git? gives you the vocabulary this lesson builds on: repository, commit, branch, remote.

The one-line distinction

Git manages your project’s history. GitHub stores a copy of that history on the internet and adds a layer of collaboration, automation and access control around it.

If you remember nothing else: Git is a program, GitHub is a website.

Where the confusion comes from

The conflation is not a sign of carelessness. Four things make it genuinely easy to blur the two.

Most people meet them simultaneously. A typical first encounter is following a tutorial that says “install Git, create a GitHub account, run these commands.” Both tools appear at once and it is not obvious which command talks to which.

The names overlap. “Git” is literally inside “GitHub”. Add GitLab, Gitea and Bitbucket to the picture and the naming stops carrying any signal at all.

GitHub’s interface presents Git concepts. Branches, commits and diffs all appear in GitHub’s web UI. It is reasonable to conclude that those concepts belong to GitHub, when in fact GitHub is displaying data structures Git created.

Some workflows really do span both. git push is a Git command, but pushing to GitHub involves GitHub’s authentication. The boundary is real, but you cross it constantly.

What Git does

Git is a command-line program — roughly 100 MB installed — that manages a repository on your local filesystem. Everything in this list happens on your machine, with no network involved:

• Initialising a repository (git init)
• Recording snapshots (git commit)
• Inspecting state (git status, git diff)
• Reading history (git log, git blame)
• Creating and switching branches (git branch, git switch)
• Merging and rebasing branches
• Reverting or restoring earlier versions
• Tagging releases

That list covers most of what version control is. All of it works on a laptop with the network turned off.

Git also knows how to talk to other repositories over SSH or HTTPS — that is what git clone, git fetch, git pull and git push do. But Git does not care whether the other end is GitHub, a GitLab instance, a server your company runs, or a directory on an external drive. To Git, a remote is just another repository at some address.

What GitHub does

GitHub is a hosted service. Its core function is to store Git repositories on servers you can reach over the internet — which gives you an off-machine backup and a shared point of synchronisation for a team.

Everything else GitHub offers is built around that hosted repository, and none of it is part of Git:

Pull requests. A proposal to merge one branch into another, with inline code review, discussion threads, approval requirements and status checks. Git can merge branches; it has no concept of a review workflow. Pull requests are GitHub’s invention. (GitLab calls the equivalent feature a merge request.)

Issues and project boards. Bug tracking, feature requests, labels, milestones and kanban boards. Purely GitHub features; Git has no issue tracker.

GitHub Actions. A CI/CD system that runs workflows in response to repository events — a push, a pull request, a schedule, a release. Actions is a substantial platform in its own right, covered as a future pillar of this Academy.

Access control and organisations. Teams, roles, repository permissions, required reviews and branch protection rules. Git has no user model at all; it records author names as free text and leaves authorisation to whatever transport you use.

Security features. Secret scanning, Dependabot dependency alerts, code scanning and a private vulnerability reporting process.

Discovery and social features. Stars, forks, followers, topic pages, README rendering, and the search across public repositories that makes GitHub the de facto public index of open source.

APIs. REST and GraphQL APIs covering essentially every GitHub object — repositories, pull requests, issues, workflow runs — plus webhooks that notify external systems of events.

GitHub CLI. A separate command-line tool, gh, for driving GitHub itself from a terminal. Note that this is a different program from git:

git status          # Git: local repository state
gh pr list          # GitHub CLI: pull requests on the hosted repository

That pair of commands is the clearest demonstration of the boundary. git never contacts GitHub’s API. gh does nothing to your local history.

GitHub Copilot is a third thing

Copilot is an AI coding assistant sold by GitHub. It runs in your editor and suggests code. It is neither part of Git nor required by GitHub, and works with repositories hosted anywhere.

The boundary, drawn

Where Git ends and GitHub begins

Two panels. The left panel, labelled Your machine, contains Git and a local repository with commits, branches and the object database, and lists local operations: init, add, commit, log, diff, branch, merge. The right panel, labelled GitHub servers, contains a hosted copy of the repository plus pull requests, issues, Actions, permissions and APIs. A double-headed arrow between them is labelled push, fetch, pull and clone, and marked as the only network boundary.

Comparison table

	Git	GitHub
What it is	Version control software	A hosted platform and web service
Where it runs	Your computer	GitHub’s servers
Created	2005, by Linus Torvalds for the Linux kernel	2008; acquired by Microsoft in 2018
Licence / cost	Free and open source (GPLv2)	Commercial service with a free tier
Needs an account	No	Yes
Works offline	Yes, for everything except syncing	No
Installed how	A package on your machine	Nothing to install; used via browser, API or gh
Stores history	Yes, in .git	Yes, as a copy of the same repository
Commits and branches	Creates and manages them	Displays and stores them
Pull requests	Not a Git concept	Core feature
Issue tracking	No	Yes
CI/CD	No	GitHub Actions
Access control	No user model	Teams, roles, branch protection
Alternatives	Mercurial, Subversion, Perforce, Fossil	GitLab, Bitbucket, Gitea, Azure Repos, SourceHut

Which commands touch the network?

This is the practical version of the distinction, and worth internalising early.

Command	Contacts a remote?	Notes
git init	No	Creates a repository locally
git add	No	Updates the index
git commit	No	Writes a commit into your local repository
git status	No	Reads local state
git log	No	Reads local history
git diff	No	Compares local states
git branch	No	Manages local pointers
git switch / git checkout	No	Updates your working tree
git merge	No	Combines local branches
git clone	Yes	Copies a repository from a remote
git fetch	Yes	Downloads new commits without changing your branch
git pull	Yes	fetch followed by an integration step
git push	Yes	Uploads your commits to the remote

Four commands out of that list touch the network. Everything else is local — which is why Git remains fully usable on a plane, and why a slow connection never slows down your commit.

Using Git without GitHub

Git is completely functional with no hosting service at all. These are all legitimate setups:

Purely local. Run git init in a project directory. You get history, branching, diffs and recovery with no remote, no account, and no network. For a solo project this is often enough.

A remote on a drive or network share. A remote is just a path. You can push to a repository sitting on an external disk or NAS:

git clone --bare ~/projects/my-app /mnt/backup/my-app.git
git remote add backup /mnt/backup/my-app.git
git push backup main

Your own server over SSH. If you have SSH access to any machine, you have a Git host:

git remote add origin ssh://user@example.com/srv/git/my-app.git

A different hosting provider. GitLab, Bitbucket, Gitea, Codeberg, SourceHut and Azure Repos all host Git repositories. Switching between them changes your remote URL and your web workflow; it does not change a single Git command.

A useful test

If a task can be done on a machine with no network connection, it is a Git task. If it requires a browser, an API token or another person’s account, it is a platform task.

What actually happens when you push

Tracing one git push makes the division of labour concrete.

1. Git works out what is missing. It compares the commits you have locally against what the remote reports having, and computes the set of objects the remote lacks.
2. Git packages those objects. Commits, trees and file contents are bundled into a single compressed stream. Objects the remote already has are not sent again.
3. The transport authenticates. Over HTTPS this is a credential helper supplying a token; over SSH it is your key pair. This is the step where GitHub — not Git — decides whether you are allowed in.
4. The remote applies the update. It stores the new objects and moves its branch pointer, provided the update is a fast-forward or you have explicitly forced it.
5. GitHub reacts. Only now does the platform layer engage: webhooks fire, GitHub Actions workflows matching the event are queued, open pull requests that include the branch update their diffs, and branch protection rules are evaluated.

Steps 1, 2 and 4 are Git doing version control. Step 3 is the boundary. Step 5 is entirely GitHub, and would simply not happen if you pushed to a bare repository on a drive instead.

Common mistake: force-pushing shared branches

git push --force tells the remote to move its branch pointer even when that discards commits. On a branch other people have pulled, this rewrites shared history and creates real work for everyone else. If you must rewrite, prefer --force-with-lease, which refuses the push if the remote has moved since you last fetched. Treat force-pushing to a shared branch as something to agree on first, not something to reach for when a push is rejected.

Alternative Git hosting services

Understanding that GitHub is one option among many reinforces the boundary. A brief, non-exhaustive survey:

• GitLab — Git hosting with built-in CI/CD, offered both as a hosted service and as software you can run yourself. Uses “merge request” for the pull request concept.
• Bitbucket — Atlassian’s Git hosting, commonly chosen by teams already using Jira.
• Gitea and Forgejo — lightweight, self-hosted Git services. Useful when you want a web UI on your own hardware without much operational overhead.
• Codeberg — a non-profit hosting service running Forgejo.
• Azure Repos — Git hosting within Azure DevOps.
• SourceHut — a minimal, email-workflow-oriented suite.

Each adds its own layer above Git. The repositories themselves stay interchangeable: you can clone from one and push to another, because the underlying format is the same.

Common mistakes

Saying “I’ll push it to Git.” You push to a remote, using Git. Small point, but the habit of saying “Git” when you mean “the hosted repository” is exactly what keeps the confusion alive.

Assuming a commit is shared. Committing is local. Work only becomes visible to others after git push. A surprising number of “my teammate can’t see my changes” reports resolve to this.

Thinking you must have a GitHub account to learn Git. You do not, and starting locally is a better way to learn — it isolates Git’s behaviour from the platform’s.

Believing deleting a GitHub repository deletes the history. Every clone is complete. If anyone has a clone, the history survives.

Expecting pull requests to work locally. There is no git pull-request. Pull requests exist on the platform. Locally you have branches and merges.

Confusing git with gh. They are separate programs, installed separately. gh needs authentication to GitHub; git does not.

Mental Model

Think of it as a document and a document-sharing service.

Git is the program on your machine that tracks every version of the document, lets you branch it, compare revisions and roll back. It is entirely yours, and it works whether or not anyone else exists.

GitHub is the service where you keep a synchronised copy so other people can read it, propose edits through a structured review process, discuss it, and run automation against it.

The document format is the same in both places. The service adds process and audience — not version control.

What You Learned

• Git is version control software that runs locally; GitHub is a hosted platform built around it.
• Every core version control operation — commit, branch, merge, log, diff — is local and offline.
• Only clone, fetch, pull and push contact a remote.
• Pull requests, issues, Actions, permissions and APIs are GitHub features, not Git features.
• git and gh are separate programs with separate jobs.
• Git works with no host at all, with a filesystem remote, with your own server, or with any of several competing hosting providers.

Try It Yourself

No account needed.

1. Create an empty directory and run git init inside it.
2. Add a file, then run git add and git commit.
3. Run git log to confirm the commit exists.
4. Disconnect from the network, then repeat steps 2 and 3 with a second file.

Everything still works, because none of it ever needed a server. If you have not installed Git yet, the next three lessons cover that for each major platform.

Next Lesson

You now know what Git is and what it is not. Before installing anything, it is worth understanding what Git is doing internally — the working tree, the index, and the object database. That model makes every later command predictable rather than memorised.

Lesson 3 — How Git Actually WorksThe three states, the object database, and what git add and git commit really do.

Lesson 7 — Your First Git RepositorySkip ahead to the hands-on tutorial if you already have Git installed.