World is now on Opti ID! Learn more

Darren Stahlhut
Apr 1, 2019
  32
(0 votes)

GitFlow is a natural fit for Episerver DXC

In this blog, I'll explain a little about GitFlow and why it aligns so well with Episerver DXC development.

What is GitFlow?

If you're not familiar with GitFlow, it's just another branching and merging strategy. It was made popular by Vincent Driessen at nvie and has since been widely adopted by the development community.

It's also built into the most popular Git Clients including SourceTree and GitKraken and is available via commands in Git console.

What I like most about GitFlow, is not the merging strategy itself, but its things that having a standard strategy offers;

  • We can more easily collaborate with external developers and Agencies. We can simply by say "we use GitFlow" and they'll know what we mean.
  • Onboarding Developers is faster, there are a lot of good learning resources around.

GitFlow merging strategy (in a nutshell)

There are two main branches in GitFlow;

  • master - the code you have or are going to release.
  • develop branch - the latest development, changes for the next release.

Besides the main branches, we also have;

  • feature branches - this is where you actually do your development and commits.
  • release branches - a branch to get code ready to release to master.
  • hotfixes - for emergency fixes for master branch to be immediately released.

GitFlow merging diagram

Why does this work well with Episerver DXC?

Because of Episerver DXC's linear deployment path, code must be deployed from Integration > Preproduction > Production.

This means we can think of our Master branch as the code ready to be deployed to Integration.

Deployments above Integration are managed via the Paas Portal or via Episerver Support.

If you also want to have an internal CI/CR (build and release) environment for internal QA, you can run it off the Develop branch

This all means we can use the standard implementation of GitFlow.

Wrapping it up

I'm not saying GitFlow is perfect, but it is a decent merging strategy. It can become complicated when you aren't certain about the order that Features will be released and I have some very large scale projects that GitFlow struggles to handle so we have a customized strategy.

But generally speaking, for Episerver DXC projects where the deployment chain is linear, I've found it's a great fit.

This might change in the future if we are allowed to use our own DevOps tools to deploy directly to Preproduction (or even Production) which is something I've heard is on the technical roadmap. 

Resources

Apr 01, 2019

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |