GitHub
Git
version control
empty branch
coding tips

Create empty branch on GitHub

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

An "empty branch" on GitHub usually means a branch that does not contain the files and history from your main development branch. In Git terms, that is not literally a branch with no commit. A branch must point to a commit, so the practical solution is an orphan branch with its own root commit.

What "Empty" Means in Git

Git branches are lightweight pointers to commits. That detail matters because it explains why GitHub cannot host a branch that has never had a commit. If a branch exists, it already references some commit object in the repository.

So there are two different goals people often confuse:

  • create a new branch that starts from existing history
  • create a new branch that does not share the existing branch history

The first case is just a normal branch:

bash
git switch -c feature-x

That branch is not empty. It starts from the current commit.

If you want a branch for documentation, generated site output, or a clean experiment that should not inherit current files, you want an orphan branch instead.

Create an Orphan Branch Locally

The modern command is git switch --orphan. Older tutorials often use git checkout --orphan, which is still valid.

bash
git switch --orphan gh-pages

At this point, Git has created a branch name, but your working tree still contains files from the previous branch. That surprises many people. The branch history is new, but your checkout directory has not been wiped automatically.

Remove the tracked files so you can start clean:

bash
git rm -rf .

If you also want to remove untracked files that are left in the working tree, inspect them first with git status, then clean them deliberately.

Now add the files you actually want on the branch. For example, a minimal README:

bash
printf "# Publish Branch\n" > README.md
git add README.md
git commit -m "Initialize orphan branch"

That first commit becomes the root commit for the new branch. It has no parent, which is why the branch feels empty relative to the rest of the repository.

Push the Branch to GitHub

Once the orphan branch has its first commit, push it like any other branch:

bash
git push -u origin gh-pages

GitHub will now show gh-pages as a branch in the repository. It still is not truly commit-free, but it is isolated from the original line of history.

This pattern is common for:

  • 'gh-pages publishing branches'
  • documentation-only branches
  • migration branches
  • one-off import or export snapshots

Example End-to-End Workflow

Here is the full sequence in one place:

bash
1git switch --orphan docs-clean
2git rm -rf .
3printf "# Docs Branch\n" > README.md
4git add README.md
5git commit -m "Create isolated docs branch"
6git push -u origin docs-clean

After that, git log --oneline --graph --all will show a separate root commit for docs-clean.

GitHub UI Versus Git Commands

People often look for a GitHub web interface button that says "create empty branch." The web UI creates normal branches from an existing branch tip. That means the new branch inherits history by default.

If your requirement is truly "start fresh," the GitHub UI alone is usually not enough. You do the branch creation locally with Git, make the first commit, and then push to GitHub.

In other words:

  • GitHub UI is fine for normal branch creation
  • local Git is the right tool for orphan branches

When an Orphan Branch Is the Wrong Tool

Sometimes the request for an empty branch is really a request for a separate repository. That distinction matters.

Use an orphan branch when:

  • you still want the branch inside the same GitHub repository
  • branch-level settings or Pages deployment belong with the current repo
  • collaborators should access everything in one place

Use a separate repository when:

  • the content has a different lifecycle
  • permissions should differ
  • the history should be fully independent
  • the branch is acting like a second project

If you find yourself treating the orphan branch as a separate application forever, that is often a sign that a new repository would be cleaner.

Alternative Commands and Compatibility

If your Git version does not support switch, use:

bash
git checkout --orphan docs-clean

The rest of the workflow stays the same.

You may also see advice to create a new branch and delete every file. That removes the files from the branch tip, but it does not remove the inherited commit history. If history separation matters, use an orphan branch, not a regular branch.

Common Pitfalls

The biggest mistake is expecting GitHub to host a branch with zero commits. Git does not work that way. A branch must reference a commit, so the closest valid result is an orphan branch with a fresh root commit.

Another common issue is forgetting that after git switch --orphan, the working tree still contains files from the old branch. If you commit immediately without cleaning the tree, your "empty" branch will accidentally include the old project files.

Some developers also create a normal branch, delete all files, and assume they have isolated history. They have only created a new tip commit on top of the existing history.

Finally, pushing before making the first commit usually fails because the orphan branch does not yet point to a commit Git can publish.

Summary

  • A Git branch cannot exist without a commit.
  • The practical way to create an "empty" branch is an orphan branch.
  • Use git switch --orphan branch-name, then remove inherited working-tree files, add what you need, commit, and push.
  • A normal branch with deleted files still shares the original history.
  • If the content is truly independent long term, a separate repository may be a better design.

Course illustration
Course illustration

All Rights Reserved.