Orphaned Branches in Git

by Christoph Schiessl on DevOps and Git

You have to be aware of Git's internal data structure, before you can understand what orphaned branches are and how to use them. So, let's start by examining this data structure. Surprisingly, this is easier than it sounds. In fact, there are only two "rules" you have to know.

  1. All commits in a Git repository have a list of references to their parent commits. Ordinary commits have precisely one, whereas commits created with git merge have multiple parents. The number of parent commits is theoretically unlimited.
  2. Cycles in child-parent relationships between commits are forbidden. In other words, a commit's ancestors must never include the commit itself.

If you take a minute to reflect on these two rules, you'll realize that there has to be at least one commit with zero parents. It's logically impossible to simultaneously observe both rules without having at least one of these so-called root commits.

What we have so far is a full description of Git's internal data structure, which is well-known as a directed acyclic graph in computer science. All of Git's features can be explained with the graph because they are all built on top of it. Git's command-line interface, as well as third-party GUIs, are just tools to make working with the underlying graph easier.

Branches and History

Branches are nothing more than named references pointing to specific commits in your repository's graph. The most important feature of branches is that they provide an entry point into your repository's history.

Fine, so how exactly does repository history relate to the graph? Well, it all comes down to the child-parent relationships between commits. For example, if you execute the command git log master, it gives you a list of commits in reverse chronological order. The most recent commit (i.e., HEAD of the master branch) is followed by its parents, which in turn is followed by its parents and so on. The directed acyclic graph guarantees that any given commit has a finite number of ancestors: If you traverse through a commit's chain of ancestors, you have to hit a root commit eventually. Therefore, git log's output is guaranteed finite.

Orphaned Branches

The crucial point of this article is the following: There's nothing in the definition of the directed acyclic graph forbidding the existence of multiple root commits. As a matter of fact, that's precisely what makes orphaned branches possible.

Most repositories have a history resembling the following:

          i---j---k     <== branch 'your-wip-feature'
a---b---c---d---h---l   <== branch 'master'
     \         /
      e---f---g         <== branch 'your-completed-feature'

As you can see, most commits have precisely one parent commit. The only exceptions are a (root commit with zero parents) and h (merge commit with two parents).

With orphaned branches, you can completely separate your branches, because they are starting from different root commits. Therefore, you can build repositories like this:

a---b---c---d         <== branch 'master'

      1---2---3---4   <== branch 'independent-history'

Creating additional root commits or orphaned branches can be accomplished with git checkout, together with its --orphan option. Quoting Git's documentation:

The first commit made on this new branch will have no parents, and it will be the root of a new history, totally disconnected from all the other branches and commits.

In other words, it creates a new root commit and uses it as a starting point for your new branch.


The usefulness of orphaned branches is limited to rare occasions. For instance, if you are using GitHub Pages, it creates a new branch named gh-pages for you. This branch is "orphaned" and, therefore, completely separate from your repository's prior history.

Thank you for reading, and have a nice day!

Ready to Learn More Web Development?

Join my Mailing List to receive two articles per week.

I send two weekly emails on building performant and resilient Web Applications with Python, JavaScript and PostgreSQL. No spam. Unscubscribe at any time.

Continue Reading?

Here are a few more Articles for you ...

Why JavaScript’s undefined Isn’t What You Think It Is

In this informative article, you learn that undefined is not a keyword in JavaScript, and it's up to you to ensure it refers to the value its name suggests.

By Christoph Schiessl on JavaScript

Caching Expensive Queries with MATERIALIZED VIEWs

Learn how to use PostgreSQL's MATERIALIZED VIEWs to improve performance of complex queries. Persist query results and refresh them manually or automatically.

By Christoph Schiessl on PostgreSQL

Telling Docker Who You Are

Learn how to avoid permission issues when creating files on a Docker bind-mount volume from within a container and manage user IDs and group IDs on Linux.

By Christoph Schiessl on DevOps and Docker

Christoph Schiessl

Christoph Schiessl

Independent Consultant + Full Stack Developer

If you hire me, you can rely on more than a decade of experience, which I have collected working on web applications for many clients across multiple industries. My involvement usually focuses on hands-on development work using various technologies like Python, JavaScript, PostgreSQL, or whichever technology we determine to be the best tool for the job. Furthermore, you can also depend on me in an advisory capacity to make educated technological choices for your backend and frontend teams. Lastly, I can help you transition to or improve your agile development processes.