The main branch (historically called master) is the default branch of a Git repository — the branch that’s automatically checked out when someone clones the repository, and the one GitHub displays by default when you open a project’s page. In most workflows, it represents the current stable, production-ready state of the code: the version that’s meant to actually work, as opposed to feature branches where experimental or in-progress changes live.

The moment a project has more than one contributor, chaos becomes possible without an agreed reference point — if everyone works on their own separate branch with no shared destination, there’s no single version anyone can point to and say “this is what’s actually running in production right now.” The main branch solves this by acting as a rallying point: a known, stable destination that every feature branch eventually merges back into, and the branch that deployment pipelines are typically configured to build and release from.

This matters enormously at scale. Large projects — think of a company like Netflix or a huge open-source project like React — might have hundreds of branches open simultaneously, each representing separate work in progress. Without a designated main branch, there would be no unambiguous answer to the question “what does our software currently do?”

Internally, a Git branch is nothing more than a lightweight, movable pointer to a specific commit. When you create a new repository, Git creates one such pointer and gives it a name — by default, that name is main (or historically, master). Every time a new commit is made while that branch is checked out, the pointer simply moves forward to the new commit. Other branches are created the exact same way, just with different names and possibly starting from a different point in history.

On GitHub specifically, the platform layers an additional setting on top of this: the repository’s default branch, configurable in the repository settings, which determines which branch loads first when someone visits the repo, which branch new Pull Requests target by default, and which branch many automated tools and deployment integrations assume is the primary one.

gitGraph
    commit id: "Initial commit"
    commit id: "Add README"
    branch feature-login
    checkout feature-login
    commit id: "Build login form"
    commit id: "Add validation"
    checkout main
    merge feature-login id: "Merge login feature"
    commit id: "Update docs"
    

What an interviewer may ask: “Is main a special type of branch in Git?” No — Git treats every branch identically at the mechanical level. “Main” only becomes special through repository configuration, team convention, and branch protection rules layered on top by the hosting platform.

When you clone a repository, your local Git installation asks the remote server (GitHub) which branch is currently set as the default, then automatically checks that branch out for you — this is why running git clone on any repository drops you directly onto main without needing to specify it. Internally, Git stores a reference called HEAD, which points to whichever branch (and therefore whichever commit) you currently have checked out. When HEAD points to main, any new commit you make moves the main pointer forward to include that commit.

Because main typically represents production-ready code, GitHub provides branch protection rules specifically to guard it: requiring at least one approving review before a Pull Request can be merged, requiring status checks (like automated tests) to pass first, disallowing force-pushes that could rewrite history, and even preventing direct pushes entirely so that all changes must flow through a reviewed Pull Request. Without these protections, any contributor with write access could push directly to main and bypass review entirely, which is a common cause of accidental production outages at organizations that haven’t configured them.