What Is a Commit, Again?

A commit is a saved snapshot of a project at one moment in time — every file, exactly as it looked, plus a short message describing what changed. Every commit (except the very first) also remembers which commit came right before it, its “parent.” String enough commits together, each pointing back to its parent, and you get a chain: the project’s entire history, from the very first line of code to the most recent change.

So What Is a Branch?

A branch is nothing more than a movable, named label pointing at one specific commit in that chain. That’s the whole definition. It sounds almost too simple to matter, but the consequences of this simple idea are enormous: because a branch is just a pointer, and not a copy of every file, creating a new one is instant and nearly free, no matter how large the project is.

The Default Branch: main

Every new repository starts with one branch, conventionally named main (older projects sometimes still use master). This is treated as the project’s official, stable timeline — the version that’s meant to build correctly, pass its tests, and represent what’s actually shipped or shippable at any given moment. Almost everything else in a team’s workflow exists to protect this one branch from half-finished, untested, or broken work.

Why Not Just Edit main Directly?

In theory, nothing stops you from making every change directly on main. In practice, this quickly becomes unworkable the moment more than one person touches the project. If two developers are both editing main at the same time, their half-finished, possibly broken code is visible to everyone else immediately. A branch solves this by giving each unit of work — a new feature, a bug fix, an experiment — its own isolated pointer, so nothing is exposed to the rest of the team, or to production, until it’s actually ready.

A Git repository is really a graph of connected objects: commits (snapshots with metadata), trees (the directory structure at that snapshot), and blobs (the actual file contents). A branch is a fourth, much smaller kind of object: a simple reference — literally just a file containing the identifier of one commit — stored under a references folder inside the repository. Moving a branch forward as you commit simply means updating the identifier that one small reference file points to.

flowchart LR
    subgraph History["Commit Graph (shared by all branches)"]
        C1["Commit 1"] --> C2["Commit 2"] --> C3["Commit 3"]
        C3 --> C4["Commit 4 (main)"]
        C3 --> C5["Commit 5 (feature)"]
        C5 --> C6["Commit 6 (feature)"]
    end
    MAIN["main branch pointer"] -.-> C4
    FEAT["feature/login branch pointer"] -.-> C6
    HEAD["HEAD (your current branch)"] -.-> FEAT
    

The Building Blocks

Creating a Branch

When you create a new branch, Git does exactly one thing: it writes a new reference file that points at whatever commit your current branch is sitting on right now. No files are copied, no history is duplicated — the new branch starts out identical to the branch it was created from, simply because it’s pointing at the very same commit.

Switching Branches (Checkout)

When you switch to a different branch, Git updates the files in your working directory to match whatever that branch’s commit contains, and moves HEAD to point at the new branch. If a file exists in one branch but not another, it appears or disappears accordingly. This is why switching branches feels instantaneous even in huge projects — Git isn’t downloading or rebuilding anything, it’s just changing which snapshot’s files are currently visible on disk.

Making Commits on a Branch

Every new commit you make while on a branch becomes that branch’s new tip: Git creates the commit object (pointing back to the previous tip as its parent), and then updates the branch’s reference file to point at this new commit instead. The branch pointer effectively “walks forward” one step with every commit.

How Merging Reconciles Two Branches

To merge one branch into another, Git looks for the most recent commit the two branches have in common — their “merge base” — and then compares what changed on each side since that point. If the changes touch different parts of the code, Git combines them automatically into a new merge commit with two parents: the tip of each branch. If the same lines were changed differently on both sides, Git can’t guess which version is correct, and flags a merge conflict for a human to resolve by hand.

sequenceDiagram
    participant Dev as Developer
    participant Local as Local Repo
    participant GH as GitHub
    participant CI as Automated Checks
    participant Team as Reviewers
    Dev->>Local: git checkout -b feature/checkout-page
    Dev->>Local: Make commits on the new branch
    Dev->>GH: git push -u origin feature/checkout-page
    GH->>CI: Run tests on the branch
    CI-->>GH: Report status
    Dev->>GH: Open Pull Request (feature/checkout-page into main)
    GH->>Team: Notify for review
    Team->>GH: Approve
    GH->>GH: Merge branch into main
    GH->>GH: Delete feature/checkout-page branch
    

A branch’s life usually begins the moment a developer picks up a new piece of work — a new feature, a bug report, an experiment. They create a branch off the latest version of main, often naming it something descriptive like feature/checkout-page or fix/broken-image-upload, so its purpose is obvious to anyone browsing the repository later.

While working on the branch, the developer commits early and often, pushing the branch to GitHub so it’s backed up and visible, but without any effect on main or on anyone else’s work. As the branch is pushed, automated checks can run against it immediately — long before it’s ready to merge — giving the developer fast feedback on whether their changes broke anything.

When the work is ready, the developer opens a Pull Request asking for this branch to be merged into main. This is where the branch briefly becomes a shared object of attention: reviewers read the changes, automated tests run one more time against the exact code that would land in main, and once everything passes, the branch is merged. At that point, its job is done — most teams delete the branch immediately after merging, since the commits it introduced now live permanently on main regardless.

Branch Protection Rules

GitHub lets repository administrators apply protection rules to specific branches, most commonly main. These rules can require that changes only ever arrive through a reviewed Pull Request — never a direct push — that a minimum number of people approve the change, and that all required automated status checks pass first. Administrators can even be included in these restrictions, so that no single person, regardless of seniority, can bypass review.

Who Can Create, Delete, or Push to a Branch

Repository permissions determine who can create new branches, push commits to them, or delete them outright. In an open-source project, external contributors typically can’t push branches directly to the main repository at all — they instead fork the repository (creating their own separate copy) and open a Pull Request from a branch on their fork, letting maintainers review before anything touches the original project.

Signed Commits and Protected Tags

For extra assurance about who really authored a change, some organizations require that commits merged into protected branches be cryptographically signed, proving they genuinely came from the claimed author and haven’t been tampered with in transit.

Every branch creation, push, and deletion is recorded, giving teams visibility into who is working on what, and for how long. GitHub’s insights and audit logs can show how many branches currently exist, how old the oldest unmerged ones are, and how often protected-branch rules block a would-be direct push — a useful early signal that someone doesn’t understand, or is trying to bypass, the team’s review process.

Branch-level data also feeds directly into broader engineering metrics. The time between a branch’s creation and its eventual merge is a common proxy for how efficiently a team reviews and ships work. A rising number of long-lived, unmerged branches is often an early warning sign of unclear priorities, overloaded reviewers, or features that grew too large to review comfortably.

Common Branching Strategies

A branch is one of the smallest ideas in Git, and one of the most transformative: a simple, movable pointer to a single commit, cheap enough to create dozens of times a day, and powerful enough to let entire industries of developers collaborate on the same codebase without stepping on each other’s work. Understanding that a branch is a pointer — not a copy — is the key that unlocks nearly everything else about how Git and GitHub actually behave.