Git vs. GitHub — Not the Same Thing

Git is a piece of software called a “version control system.” It runs entirely on your own computer and its job is simple: it keeps track of every change ever made to a set of files, so you can go back in time, compare versions, or combine changes made by different people. Git was created in 2005 by Linus Torvalds, the same person who created the Linux operating system, because the tools available at the time couldn’t handle the scale of contributions coming into the Linux kernel project.

GitHub, on the other hand, is a website and cloud service built on top of Git. If Git is the engine that tracks changes on your own machine, GitHub is the shared garage where everyone parks their project so the whole team — or the whole world — can see it, download it, and contribute to it. GitHub adds a web interface, user accounts, permissions, collaboration tools like Pull Requests and Issues, and automation features on top of plain Git.

What Is a Repository?

A “repository,” almost always shortened to “repo,” is simply a project’s folder together with its entire history of changes. A repository can be as small as a single configuration file or as large as the Windows operating system’s source code, which itself lives partly on internal Microsoft infrastructure built using Git technology. Every repository on GitHub has an owner (a person or an organization), a name, and a visibility setting — public, where anyone on the internet can see the code, or private, where only invited people can see it.

Commits, Branches, and the “Tree” of History

A commit is a saved snapshot of your project at a specific point in time, along with a short message explaining what changed and why. Over the life of a project, thousands or even millions of commits build up, forming a timeline.

A branch is a parallel, independent line of that timeline. The default branch — usually called main — represents the official, stable version of the project. When a developer wants to build a new feature or fix a bug without disturbing the stable version, they create a new branch, make their changes there, and only bring those changes back into main once the work is reviewed and approved.

The Pull Request — GitHub’s Signature Idea

If there is one feature that explains why GitHub became so popular, it is the Pull Request, often abbreviated PR. A Pull Request is exactly what it sounds like: a request asking the maintainers of a project to “pull” your proposed changes into their codebase. It creates a dedicated page where the proposed changes are shown line by line, where teammates can leave comments on specific lines of code, where automated tests can run against the proposed change, and where a final decision — approve, request changes, or reject — is recorded. This turns merging code from a risky, manual process into a transparent, reviewable conversation.

At the center of GitHub sits Git itself, which is a distributed version control system. That single word — distributed — explains a lot about how GitHub is built. In a distributed system, every developer’s local clone contains the complete project history, not just the latest version. GitHub’s servers hold what is called the “remote” — the shared, central copy that everyone synchronizes with — but they are not the only place the full history exists.

flowchart TB
    subgraph Client["Developer's Laptop"]
        LR["Local Repository (full history)"]
        WD["Working Directory (files you edit)"]
        SA["Staging Area (changes ready to commit)"]
        WD --> SA --> LR
    end
    LR -- "git push" --> RG["GitHub Remote Repository"]
    RG -- "git pull / fetch" --> LR
    RG --> PR["Pull Request Engine"]
    RG --> ISS["Issues and Projects"]
    RG --> ACT["GitHub Actions (CI/CD Runners)"]
    RG --> PAGES["GitHub Pages (static hosting)"]
    RG --> API["REST and GraphQL API"]
    PR --> WEBHOOK["Webhooks"]
    ACT --> WEBHOOK
    WEBHOOK --> EXT["External Tools (Slack, Jira, etc.)"]
    

The Core Building Blocks

How Git Tracks Changes Internally

Git does not store a fresh full copy of your project for every single commit the way older tools did. Instead, it stores content as a graph of objects, each identified by a unique fingerprint called a hash, calculated from the content itself. If two files anywhere in the project have identical content, Git stores that content only once and simply points to it from both locations. This is why Git repositories, despite tracking thousands of historical versions, stay far smaller than storing every full copy would require.

Every commit contains: a pointer to a “tree” object representing the full directory structure at that moment, a pointer to its parent commit (or commits, if it’s a merge), the author’s name and email, a timestamp, and a message. Because each commit points to its parent, the entire history forms a chain that Git can walk backward through at any time.

What Happens When You “Push” to GitHub

When you run the push command from your laptop, several things happen behind the scenes on GitHub’s side:

How Merging Actually Works

When a Pull Request is merged, GitHub combines the commit history of the source branch into the target branch. It does this in one of three ways: a merge commit, which creates a new commit joining the two histories together and preserves the full branch structure; a squash merge, which condenses every commit from the Pull Request into a single, clean commit on the target branch; or a rebase merge, which replays each commit from the source branch one at a time on top of the target branch, producing a straight, linear history with no merge commit at all.

sequenceDiagram
    participant Dev as Developer
    participant Local as Local Git Repo
    participant GH as GitHub Remote
    participant CI as GitHub Actions
    participant Rev as Reviewer
    Dev->>Local: Edit files and git commit
    Local->>GH: git push (feature branch)
    GH->>CI: Trigger workflow (tests, lint)
    CI-->>GH: Report pass/fail status
    Dev->>GH: Open Pull Request
    GH->>Rev: Notify for review
    Rev->>GH: Comment / Approve
    GH->>GH: Merge into main branch
    GH->>CI: Trigger deployment workflow
    CI->>CI: Build and deploy artifact
    

The journey typically follows a well-worn path used by teams at nearly every serious software company. First, a developer creates a new branch off the latest stable code, giving it a descriptive name such as fix-login-timeout. They make their changes locally, testing as they go, and commit their work in small, logical chunks rather than one giant change. Once ready, they push the branch to GitHub, which makes it visible to the rest of the team but does not yet affect the main codebase.

The developer then opens a Pull Request, describing what changed and why. GitHub Actions automatically kicks off a series of checks — running the automated test suite, checking code style, scanning for known security vulnerabilities in dependencies. If any check fails, the Pull Request is visibly blocked from merging until it’s fixed. At the same time, human reviewers are notified and begin reading through the diff, leaving comments on specific lines, suggesting improvements, or approving the change outright.

Once all required checks pass and the required number of approvals is collected — a rule many teams enforce through “branch protection” settings — the Pull Request can be merged. That merge event itself can trigger another workflow: automatically building the software, running a broader integration test suite, and deploying the new version to a staging or production environment. This entire pipeline, from a single line of code changing to that change running live for real users, can take anywhere from a few minutes to a couple of hours, and it happens with almost no manual intervention at companies that have invested in mature automation.

Authentication and Access Control

GitHub supports multiple layers of identity verification, including passwords combined with two-factor authentication (2FA), SSH keys for command-line access, and fine-grained personal access tokens that can be scoped to allow only specific actions, like reading a single repository, rather than full account access. Organizations can further enforce single sign-on (SSO) through an identity provider, ensuring that access to code is tied to a company’s central employee identity system and revoked automatically the moment someone leaves.

Repository-Level Protections

Beyond who can log in, GitHub lets administrators control what can happen once someone is inside. Branch protection rules can require that changes to the main branch only happen through a reviewed Pull Request, that a minimum number of approvals is collected, and that automated status checks pass — preventing a single person from pushing untested or unreviewed code directly into production.

Automated Vulnerability Detection

GitHub includes built-in security scanning tools. One tool automatically checks a project’s third-party libraries against known vulnerability databases and opens Pull Requests to upgrade them when a fix is available. Secret scanning inspects every pushed commit for patterns that look like leaked passwords, API keys, or certificates, and can automatically alert both the repository owner and, for many well-known services, the service provider itself, so the leaked credential can be revoked before it’s misused. Code scanning goes a step further, analyzing the actual source code for patterns known to cause security bugs, such as SQL injection or unsafe deserialization.

Every meaningful action on GitHub is recorded as an event: commits, comments, merges, permission changes, and administrative actions all leave a permanent trace. For organizations, the audit log provides a searchable record of who did what and when, which is essential for security investigations and for meeting compliance requirements in regulated industries like finance and healthcare.

On the automation side, every run of a GitHub Actions workflow produces detailed logs showing exactly which steps executed, how long each took, and precisely where a failure occurred if one did — turning a broken deployment from a mystery into a readable timeline. Teams commonly pipe this data into external observability platforms to track metrics such as average time from Pull Request creation to merge (a proxy for review efficiency), deployment frequency, and change failure rate — metrics widely used across the industry to measure engineering performance.

Common Branching Patterns

GitHub took a powerful but command-line-only tool — Git — and turned it into a social, visual, and automated platform that fundamentally changed how software teams collaborate. It didn’t just make version control easier to use; it made code review, automated testing, and deployment feel like natural parts of the same workflow rather than separate, disconnected tools bolted together.