Since I have found myself in discussions where I am making an argument against GitFlow but wrongly using the name GitOps and others have talked about Git Flow when they mean GitHub Flow — I have written this guide for me to remember which is what.

GitOps is version control for cloud infra

GitOps ensures that a system’s cloud infrastructure is immediately reproducible based on the state of a Git repository. (…) It’s an evolution of Infrastructure as Code (IaC) and a DevOps best practice that leverages Git as the single source of truth, and control mechanism for creating, updating, and deleting system architecture.

From atlassian.com/git/tutorials/gitops which is a nice read! I like the descriptions of the difference between imperative and declarative devops statements, also the example story at the end.

GitFlow is an outdated branching model

  • feature branches, develop, release branches, hotfixes, main

The original post was written in 2010 and the author, Vincent Driessen, doesn’t recommend GitFlow today. He mentions the exeption “if you are building software that is explicitly versioned” — but for me and the web applications I envision myself working on — it feels warranted to describe GitFlow as outdated. He has added these comments:

The branching model laid out in this article has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild. This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

GitHub Flow for regular deployments

  • Lightweight, branch-based workflow for teams and projects with regular deployments.
  • There's only one rule: anything in the main branch is always deployable.

Quotes from guides.github.com (which has a fun clickable diagram made with CSS!)

Trunk-Based Development 🌴

Is the GitHub branded description of a workflow the same as trunk based? They are similar, but noe technical difference is apparently where the release is made — the feature branch or the trunk.

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. — trunkbaseddevelopment.com

I will aim for the living happily ever after, thanks!