Using Git as a Content Repository

Most CMS vendors opt to build upon databases in the content management space, but a database-centric approach has a fair share of deficiencies that impact not only developers but content authors as well. 

Developers are quite familiar with the ins and outs of Git and how it can be used to improve collaboration and efficiency. However, by using Git as a repository for both static and dynamic content, the benefits can be extended to content management via a Git-based headless CMS.

Issues With Database-Centric CMSs

The primary issues that enterprises suffer from when trying to manage content using a database-centric CMS include limited versioning capabilities, lack of feature development branches, poor auditing and compliance features, and the challenges of managing content in multiple environments. 

Limited Versioning

Databases are built for structured data, and lack natural versioning capabilities, so CMS vendors have to build basic versioning features into the CMS. What this means is that CMS end users end up with versioning of individual content items, but not entire change sets or collections of content items. However, for major enterprises that are managing strategic content, teams can benefit from being able to version all of their work together. 

In addition, content teams and developers also want to be able to see the state of a website or other digital experience today and then go back and see how it has changed from a week ago, last month, or over the previous few years. 

Managing Multiple Environments 

With the latest approved and published content stored in production environments, there must be a way to get content down to lower environments for development and QA purposes. Usually, developers working with database systems write complicated scripts to detect changes in the database and then move assets down accordingly. However, this can be complicated and often leads to conflict issues. As a result, developers opt to export data from production and import it into a lower environment, which requires content freezes. 

During content freezes, CMS users need to be locked out of different environments when exporting and then again when importing that data, which can lead to a lot of unnecessary friction between developers, content authors, and IT operations staff trying to work together. 

DevContentOps With Git

Git is naturally a distributed repository, allowing developers to create a relationship between two or more repositories or two or more different environments. With Git, getting content from higher environments down to lower environments becomes much easier, streamlining both the DevOps process for developers, and the ContentOps process for content teams. This seamless integration is what we call DevContentOps.

Git helps to support the entire DevContentOps process via continuous integration and continuous deployment of software features, and continuous publishing for content - CI/CD/CP. DevContentOps integrates the content teams into the development and operations mix, eliminating traditional bottlenecks. 

Git for Static Content

Jamstack and SSG

Most systems that use Git tend to be static sites with simple content, such as blogs and simple websites that rely on static site generation (SSG). This could include editing simple Markdown, making a pull request, generating a static site, putting generated pages into an S3 bucket, and then deploying them. Many of the sites leveraging Jamstack leverage this approach to using Git. 

Static HTML

Another approach often used is to manage traditional HTML assets, CSS, and JavaScript files in a Git repository and then deploy them to the edge without a build process.

CrafterCMS Uses Git for Managing Static and Dynamic Content

With CrafterCMS, Git is integrated into the authoring experience via Crafter Studio, which allows Git to be used for a number of use cases, and for managing dynamic content and not just content for static sites. 

CrafterCMS uses its own Git repository under the hood, whereas other CMS platforms rely on GitHub, GitLab, BitBucket, or another Git repo in the cloud. CrafterCMS also integrates with these systems, and the combination offers so much more flexibility and higher levels of productivity. 

With CrafterCMS, content is stored as XML files in a presentation-less fashion. The Crafter Studio authoring system and Crafter Engine delivery platform are separate components in Crafter’s decoupled architecture. Once authored/reviewed/approved, content is published to the delivery system as XML files. Crafter Engine consumes these files, merges and caches them, and provides dynamic content access and targeting through its comprehensive set of APIs.

CrafterCMS also provides a best-in-class authoring experience using Crafter Studio. Content authors using other Git-based CMSs might need to know how to use Markdown or have some technical chops to publish content correctly. With CrafterCMS, they get in-context editing, drag-and-drop experience building, multi-channel previews, and more, all while benefiting from the advanced versioning and workflow benefits of Git under the hood. All technical details are shielded from content authors, allowing them to operate independently, just as they would in a traditional CMS. 

Versioning with Git provides a time-machine-like experience. Content teams can see every change made in the context of everything else. This enables them to run audits quickly, facilitate redesigns or make significant site changes in separate branches, avoid double publishing during migrations, and improve both development speed and content publishing throughput. 

More information about using Git as a content repository with CrafterCMS is available on this CrafterCast episode. 

Ready to see a dynamic Git-based CMS in action? You can start a free trial of CrafterCMS today.