Git is a version control system — a program that runs on your computer and keeps track of every change ever made to a set of files. Imagine you’re writing a novel in a word processor. Every time you save, the old draft is gone forever, overwritten by the new one. If you wanted to go back to the version from three days ago, you’d be out of luck unless you’d manually saved a copy called “novel_draft_v3_final_FINAL.docx.” Git solves exactly this problem for code (and really, for any text-based files), except it does it automatically, precisely, and for entire teams of people working on the same files at once.

Git was created in 2005 by Linus Torvalds — the same person who created the Linux operating system kernel — because the tool the Linux project was using at the time stopped being freely available. Torvalds needed something that could handle thousands of contributors submitting changes to the same enormous codebase, and he needed it to be fast, distributed, and reliable. What he built became the most widely used version control system in the world, and it runs entirely on your own computer. You do not need the internet to use Git. You do not need an account with anyone. You do not need permission from a company. It is simply software installed on your machine, the same way a text editor or a web browser is.

GitHub is a company and a website, launched in 2008 by Tom Preston-Werner, Chris Wanstrath, PJ Hyett, and Scott Chacon. Its purpose is to host Git repositories in the cloud — meaning it stores a copy of your project’s Git history on remote servers, accessible over the internet — and to wrap that hosting in a rich set of collaboration tools: a web interface for browsing code, a system for reviewing proposed changes (Pull Requests), issue trackers, project boards, automated testing pipelines (Actions), wikis, and social features like following other developers and starring projects you like.

GitHub is not the only company doing this. GitLab, Bitbucket, and Azure DevOps offer very similar services — they all take the same underlying Git software and build a hosted platform around it. GitHub simply became the most popular one, especially after Microsoft acquired it in 2018, and today it hosts hundreds of millions of repositories, including massive open-source projects like the Linux kernel itself, React, TensorFlow, and Visual Studio Code.

To really see the difference, it helps to look at where each piece physically “lives” and how data moves between them. Your computer holds what’s called a local repository — a hidden folder named .git that Git creates inside your project directory the moment you run git init. That hidden folder contains the complete history of every commit you’ve ever made, compressed and stored as a kind of internal database. None of this requires GitHub at all.

GitHub, meanwhile, hosts what’s called a remote repository — a copy of that same Git history sitting on a server in a data center somewhere. Your local Git installation and GitHub’s remote server talk to each other over the internet using the Git protocol (or HTTPS), synchronizing history back and forth through two core commands: git push (send your local commits up to GitHub) and git pull (bring GitHub’s commits down to your machine).

flowchart LR
    subgraph Local["Your Computer"]
        WD["Working Directory
(files you edit)"]
        STG["Staging Area
(git add)"]
        REPO["Local Git Repository
(.git folder, git commit)"]
        WD -->|git add| STG
        STG -->|git commit| REPO
    end
    subgraph Remote["GitHub Servers"]
        RREPO["Remote Repository"]
        PR["Pull Request Review"]
        CI["GitHub Actions (CI/CD)"]
        RREPO --> PR
        RREPO --> CI
    end
    REPO -->|git push| RREPO
    RREPO -->|git pull / git fetch| REPO
    

What an interviewer may ask: “If GitHub goes down, can you still commit code?” The answer is yes — because commits happen locally, entirely within Git, with no dependency on GitHub’s servers. You’d only be blocked from pushing or pulling, not from working.

Every file in a Git-tracked project passes through three conceptual areas: the working directory, the staging area (also called the “index”), and the repository (the committed history). When you edit a file, that change exists only in the working directory — Git notices it’s different but hasn’t recorded it yet. Running git add moves that change into the staging area, essentially saying “I intend to include this in my next save point.” Running git commit takes everything in the staging area and permanently writes it into the repository’s history as a new snapshot, along with a message describing what changed.

Internally, each commit is not stored as a full copy of every file (that would be wasteful) — instead, Git stores content as compressed objects identified by a unique 40-character hash (a SHA-1 checksum) generated from the content itself. If two files anywhere in history have identical content, Git stores that content only once. Each commit object points to a “tree” (a snapshot of the folder structure) and to its parent commit, forming a chain — this chain of pointers is what gives Git its history and makes operations like comparing two points in time extremely fast, since Git is just walking a graph of pointers rather than scanning entire files.

GitHub does not change any of this internal mechanism. When you push, GitHub simply receives a copy of these same commit objects and stores them on its servers. The commit hashes stay identical between your machine and GitHub — that’s precisely how Git can verify the two histories are in sync.

Notice how the first three steps involve Git alone, with no network activity whatsoever, while the collaboration-heavy steps — review, automated testing, merging with a team’s approval — belong entirely to GitHub. That split is the cleanest possible way to see the boundary between the two.

Git

GitHub

Because Git and GitHub sit at different layers, they carry different security responsibilities. Git itself secures the integrity of history through its hashing scheme — every commit’s hash depends on its content and its parent’s hash, so tampering with any past commit changes every hash after it, making silent history rewriting extremely difficult to hide. Git also supports cryptographically signing commits (GPG or SSH signing) so others can verify a commit truly came from you.

GitHub adds a separate layer of security around access rather than content integrity: who is allowed to push to a repository, who can approve Pull Requests, two-factor authentication for accounts, secret scanning to catch accidentally committed API keys and passwords, and dependency vulnerability alerts for the open-source packages your project relies on. A common real-world incident is a developer accidentally committing a database password to a public GitHub repository — Git itself has no opinion on this, but GitHub’s secret-scanning feature can detect and flag it automatically.

Because Git and GitHub are typically used together, most real “patterns” in this space are workflow patterns for combining branching (a Git feature) with review and automation (GitHub features).