Branch-based publishing

Posted on
September 26, 2022
Posted by
Markus Weiland

What is branch-based publishing? And in which ways is it better than entry-based publishing?

Let's first take a look at what each of these terms means. Also, by "publishing" I mean making content entries (i.e. individual pieces of content) visible to production systems, typically so that end-users can then consume or see this content.

For now, let's also focus on text content only and discuss non-text content (e.g. images) another time.

Entry-based publishing

In an entry-based publishing system, a single space exists in a project where all content entries live. The information whether or not a content entry is published is tracked individually for each entry. In consequence, for an editor to publish the results of a work task that affected multiple content entries, each single entry added or changed must be (re-)published.

In reality there typically exist even more states a content entry may be in: "Draft" for newly created but not yet published content, "changed" for published content entries whose modifications have not been published yet, as well as "archived" for content entries that must no longer be visible but also not be deleted.

In an example of four content entries, we are already looking at the following content states:

Content entry publication states in previous content management systems
Tracking content publication states quickly becomes difficult in a non-Git-based CMS

Having per-entry states means that editors who finish a work task must pay close attention which state each content entry is in and to (re-)publish all content entries that were affected by their work. Even a single oversight at this point means that the published result will be incomplete or broken.

Branch-based publishing

Let's now look at branch-based content publishing.

A branch is comparable to a space, just that there may be more than one. Whether or not content is published simply depends on the presence of this content in a designated "published" branch.

It doesn't matter which branch specifically holds this responsibility, just that all stakeholders agree on the same one. Typically, this published branch is called "main" branch.

What makes life really easy now in a branch-based publishing approach is that it is no longer necessary to track publication state per individual content entry. We can simply look at the published branch and know that everything in it is published.

In the end, to publish content in a branch-based model, we no longer need to think of individual entries as much as of publishing the result of some editing work in its entirety. (Similarly, when publishing a book, we also do not publish individual paragraphs but the entire book.) In other words, when merging into the published branch, the result of every single addition, change, and deletion made in our source branch is integrated into the target branchin a single step. This way it becomes impossible for editors to forget publishing some of their content changes.

Our example of four content entries looks as follows when several changes are ready for merging from a work task branch into our main branch:

Content states before merging in a branch-based CMS
In a Git-based CMS, tracking the changes in a branch is much less complex

Once merging is complete, we are have the following result in our published main branch:

Content states after merging in a branch-based CMS
In our published branch, all content is published by definition


With branch-based publishing we no longer have to worry about publishing individual content entries and forgetting to publish some entries. Instead, we can simply publish all work results in a branch in one single go, no matter how many content entries were added, changed or deleted.

Want updates about our next steps?

Sign up for our newsletter.

To learn how we process your data, visit our Privacy page.