What Is GitHub?

GitHub is a cloud-based platform for hosting Git repositories and collaborating on code with other people. It is not the same thing as Git: Git is the version control tool that runs on your computer, while GitHub is a website (and a set of APIs) built around Git that adds a browser-friendly interface, remote storage for your repositories, and a whole layer of collaboration features on top — pull requests, issues, code review, and automation. Understanding the line between the two is the first step to using either one well.

Overview / How it works

Every Git repository you create locally with git init is a complete, self-contained database of commits, trees, and blobs living inside a .git folder. Nothing about Git requires a server — two developers could, in theory, sync commits with a USB stick. GitHub’s role is to be a well-known, always-on server that hosts a copy of that same object database and gives it a URL, a login system, and a UI. When you push, you are literally copying commit, tree, and blob objects from your local .git/objects store into GitHub’s copy of the repository, and updating a branch reference (a pointer to a commit) on their server to match yours.

This matters because it means GitHub does not change how Git itself works. Branches are still just movable pointers to commits; a commit still points to a tree that records a snapshot of your files, and that tree points to blobs holding file contents, plus any subdirectory trees. GitHub simply stores that graph of objects remotely, under a repository you and your collaborators can all point your local Git at as a shared "source of truth." The remote address is usually named origin by convention, and your local branches can be configured to track a corresponding branch on that remote (for example, local main tracking origin/main), so that git push and git pull know where to send and fetch commits without you specifying it every time.

On top of this plain Git hosting, GitHub layers a product with several core pieces you will use constantly:

Feature What it is
Repository A hosted copy of a Git project, with a web UI for browsing files, commit history, and branches.
Issues A per-repository tracker for bugs, tasks, and discussion, with labels, assignees, and comments.
Pull Requests A proposal to merge one branch into another, with a diff view, inline comments, and required checks before merging.
Actions GitHub’s built-in CI/CD system: YAML workflows that run tests, builds, or deployments automatically on events like a push.
Fork Your own server-side copy of someone else’s repository, letting you propose changes without write access to the original.
GitHub Pages Free static website hosting served directly from a repository branch.

Authentication is another place GitHub differs from plain Git. Because GitHub is a shared, internet-facing service, it needs to know who you are before it lets you push. GitHub no longer accepts your account password over HTTPS; instead you authenticate with either a Personal Access Token (a long random string you generate in your account settings and use in place of a password) or an SSH key pair (a private key kept on your machine and a public key uploaded to GitHub). Most developers set up SSH once per machine and never think about authentication again; tokens are common for HTTPS remotes, scripts, and the gh command-line tool.

Syntax

"GitHub" itself is not a command — you interact with it through ordinary Git commands pointed at a remote URL, through the github.com website, or through GitHub’s official command-line tool, gh. The commands you will use most to connect a local repository to GitHub are:

git remote add <name> <url>
git remote -v
git push -u <remote> <branch>
git clone <url>
gh repo create <name> [flags]
  • git remote add <name> <url> — registers a remote repository under a short name (conventionally origin) so you don’t have to type the full URL every time.
  • git remote -v — lists the remotes configured for the current repository and their fetch/push URLs.
  • git push -u <remote> <branch> — pushes a branch to the given remote and, with -u (short for --set-upstream), records that this local branch should track the remote branch from now on.
  • git clone <url> — downloads an entire repository (all commits, branches, and tags reachable from the default branch) from a remote and creates a local working copy with origin already configured.
  • gh repo create — the GitHub CLI’s command to create a new repository on GitHub, optionally wiring it up as a remote for the current directory in one step.

Examples

Example 1: Pushing a brand-new local repository to GitHub

Say you already have a project on your machine and want to back it up to a new, empty repository you created on github.com.

git init
git add README.md
git commit -m "chore: initial commit"
git branch -M main
git remote add origin git@github.com:octocat/my-project.git
git push -u origin main

Output:

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 226 bytes | 226.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:octocat/my-project.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

The git remote add line tells this local repository where "origin" points. The final git push -u origin main uploads every object reachable from your local main branch that GitHub doesn’t already have, then creates (or updates) the main ref on GitHub’s copy and links your local main to track it, so future plain git push / git pull commands know exactly where to go.

Example 2: Cloning an existing GitHub repository

git clone https://github.com/octocat/Hello-World.git
cd Hello-World
git remote -v

Output:

Cloning into 'Hello-World'...
remote: Enumerating objects: 45, done.
remote: Total 45 (delta 0), reused 0 (delta 0), pack-reused 45
Receiving objects: 100% (45/45), 9.63 KiB | 9.63 MiB/s, done.
Resolving deltas: 100% (13/13), done.
origin  https://github.com/octocat/Hello-World.git (fetch)
origin  https://github.com/octocat/Hello-World.git (push)

git clone does three things in one step: it creates a new directory, copies every object needed to reconstruct the full commit history into a fresh .git folder, and checks out the default branch into your working tree. Notice git remote -v already shows origin configured — clone sets that up for you automatically.

Example 3: Creating a GitHub repository from the terminal with gh

Instead of clicking "New repository" on github.com first, you can create the remote repository and push your existing local project in a single command using the official GitHub CLI.

gh repo create my-project --public --source=. --remote=origin --push

Output:

✓ Created repository octocat/my-project on GitHub
  https://github.com/octocat/my-project
✓ Added remote origin
✓ Pushed commits to origin/main

Here --source=. tells gh to use the current directory as the repository contents, --remote=origin registers the new GitHub repository as your origin remote, and --push immediately pushes your existing commits. This is the fastest path from "I have a local project" to "it’s on GitHub."

How it works step by step

When you run git push origin main, Git does not simply upload your files — it negotiates with the server:

  1. Git asks the remote (GitHub) what commit its refs/heads/main currently points to.
  2. Git compares that commit to your local main and figures out exactly which commits, trees, and blobs the remote is missing (this is why the second push to the same repo is almost always faster than the first — most objects already exist on both sides).
  3. Git packs the missing objects into a single compressed "packfile" and transfers it over the network (SSH or HTTPS).
  4. GitHub unpacks the objects into its copy of the repository’s object database.
  5. If the push is allowed (no conflicting commits, no branch protection rule blocking it), GitHub moves its refs/heads/main pointer to your new commit. This is the entire "merge" that happens on a simple push — nothing more than updating a pointer, because your branch already contained the remote’s prior commit as an ancestor.
  6. If GitHub’s main has commits your local repository doesn’t know about, the push is rejected as "non-fast-forward," and you need to git pull (fetch + merge or rebase) before you can push again.

Common Mistakes

Mistake 1: Pushing a new branch without setting an upstream

git push

Output:

fatal: The current branch feature/login-page has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature/login-page

This happens the first time you push a newly created local branch: Git has no record of which remote branch it should update. The fix is exactly what the error message suggests — run the push with -u once, and every future plain git push on that branch will know where to go.

git push --set-upstream origin feature/login-page

Mistake 2: Trying to authenticate over HTTPS with your account password

remote: Support for password authentication was removed on August 13, 2021.
remote: Please use a personal access token instead.
fatal: Authentication failed for 'https://github.com/octocat/my-project.git/'

GitHub disabled plain password authentication over HTTPS years ago for security reasons. Trying to type your normal login password when Git prompts for one will always fail now. The fix is to switch to a Personal Access Token (used in place of the password when prompted) or, more conveniently, switch the remote to SSH once an SSH key is added to your account:

git remote set-url origin git@github.com:octocat/my-project.git
git push

Mistake 3: Thinking you need GitHub to use Git at all

A very common beginner misconception is that git commit or branching requires an internet connection or a GitHub account. It does not — Git is fully functional offline, entirely on your own machine. GitHub only becomes relevant the moment you want a remote backup, a place to collaborate, or features like pull requests and Actions.

Best Practices

  • Use SSH keys for authentication on your personal machine so you never have to manage tokens for everyday pushes and pulls.
  • Never commit secrets (API keys, passwords, .env files) — once pushed to GitHub, they exist in your history even if you delete them in a later commit, and public repositories are scraped for leaked credentials within minutes.
  • Give repositories clear, descriptive names and a README.md that explains what the project does and how to run it — this is the first thing anyone sees on the repository page.
  • Keep the default branch (main) protected on shared or public repositories, requiring pull requests and passing checks before anything merges into it.
  • Prefer git push --force-with-lease over a bare git push --force if you ever need to force-push, so the push fails safely if someone else has pushed commits you haven’t seen yet.
  • Use a .gitignore file from the start so build artifacts, dependency folders, and local configuration never get pushed to GitHub in the first place.

Practice Exercises

  • Create a free GitHub account if you don’t have one, create a new empty repository named practice-repo on github.com, then initialize a local project and push it there using git remote add and git push -u.
  • Clone any public repository of your choice (for example https://github.com/octocat/Hello-World.git) and run git remote -v and git log --oneline -5 to see how much history and remote configuration git clone set up for you automatically.
  • In your practice-repo, create a new branch, make a commit, and push it without -u first to see the "no upstream branch" error on purpose — then fix it with git push --set-upstream origin <branch>.

Summary

  • Git is the version control tool; GitHub is a cloud hosting service and collaboration platform built around Git.
  • A GitHub repository stores the same kind of object graph — commits, trees, and blobs — as your local .git folder; pushing transfers the objects you have that the remote doesn’t and moves a branch pointer.
  • GitHub adds features Git itself doesn’t have: issues, pull requests, Actions (CI/CD), forks, and GitHub Pages.
  • Authenticate with SSH keys or a Personal Access Token — plain passwords over HTTPS no longer work.
  • git remote add, git push -u, and git clone are the core commands that connect a local repository to GitHub.