GitHub Main and Branches — What Is the Difference?

When developing a website, you may hear that a change "has been pushed to a branch, but has not been merged into main yet." Sometimes a file is clearly visible on GitHub but not on the public website. Did something go missing? What needs to happen next?

The key is to distinguish recording changes, incorporating them into the official version, and deploying them to a website. These steps are connected, but they are not the same operation.

Start by distinguishing Git from GitHub

Git is a version-control tool that tracks changes to files. It lets you inspect earlier states, create independent lines of work, and combine changes made by multiple contributors.

GitHub is a service for hosting and sharing Git repositories remotely, reviewing code, and collaborating. You can use Git locally without GitHub or an internet connection. Publishing your local history to GitHub comes later.

Main and branches: the official baseline and independent work

main is a common name for the default branch used as a project's official baseline. Not every repository uses that name, however, and its deployment branch may be different.

A branch is a named line of development. For example, you could create feature/new-article from main and draft a new article there.

Creating a branch does not mean physically duplicating an entire repository. Git shares existing commits and tracks which commit each branch points to. New changes create commits along that branch.

The important point is that a file on a working branch may not exist on main yet.

Why are commit and push separate?

A commit saves a snapshot of selected changes in Git's history. You can attach a message such as "Correct article title" or "Add responsive diagram." When created locally, that commit initially lives in your local repository.

A push sends local commits to a remote repository such as GitHub. Think of commit as recording changes and push as transmitting those records.

To retrieve changes made elsewhere, you use fetch or pull. fetch downloads remote history so you can inspect it. pull generally goes a step further by integrating remote changes into the current branch.

What are merge and Pull Request?

Once a branch is ready, you can bring its changes into main through a merge.

A Pull Request (PR) on GitHub is a way to propose and review that integration. Reviewers can see changed files, examine test results, and leave feedback. After approval, the PR can be merged into the target branch.

A merge is the Git operation that integrates histories. A PR is the GitHub review workflow around that operation. You can also merge with Git commands without opening a PR.

If both lines of work modify the same part differently, Git may report a merge conflict. Someone must decide how to reconcile it. Depending on the merge method, Git may create a new merge commit or simply advance a branch pointer.

Deployment is separate from merging

Deployment means making the resulting code run in a real service environment. Suppose you connect a GitHub repository to Cloudflare and designate main as the production branch. You can configure Cloudflare to build and deploy when commits reach that branch.

A typical workflow looks like this:

1. Create a working branch from main.
2. Edit files and commit the changes on the working branch.
3. Push the commits to GitHub.
4. Review and test the changes through a PR.
5. Merge the verified changes into main.
6. Let Cloudflare detect the change and perform the build and deployment.
7. Open the public website and verify the result.

Not every project follows these exact steps. The production branch, automatic builds, and Preview configuration all affect the outcome. Merging into main does not guarantee successful deployment. A build can fail, so the deployed state must be checked separately.

Example: publishing a new blog article from a working branch

Imagine preparing a smart-home article series on a branch called editorial/smart-home-responsive-20261013. You commit Markdown articles and separate desktop/mobile SVG diagrams, then push that branch to GitHub.

Even if the article frontmatter sets draft: false, that change still exists only on the working branch. Until the branch is merged and production is deployed, the live site can continue showing the previous version.

That does not mean work has been lost or failed. It means the new content is being reviewed separately while the existing site stays intact.

When should I modify main, and when should I use a branch?

For a small typo or a simple wording correction, a team's rules may permit direct changes to main. For multi-file features, redesigns, security-sensitive changes, or publishing an entire series, a branch and PR usually make review and recovery easier.

If production deploys from main, it is particularly helpful to avoid pushing unverified changes straight to it. A branch is not a magical safety barrier, but it does help separate risky experiments from the running baseline.

A quick reference when the terms become confusing

Pushing a branch means its commits are on GitHub. Merging into main means those changes have joined the official baseline. Only checking the deployment tells you whether visitors can see them.