# Gitflow for Release Management with Traditional Customers Source: https://normanholz.de/en/articles/harnessing-gitflow-for-effective-release-management/ Language: en Last updated: 2023-11-14 Reading time: 5 min read Traditional customers want flexibility, fixed dates, and firm prices. Those things fight each other. Gitflow is one way to keep the fight under control. Traditional customers want three things at the same time. They want flexibility to change their mind mid-project. They want fixed release dates. They want firm prices. That sounds reasonable in a steering committee. In delivery, it is a conflict. If every new idea can enter the next release, the date is not fixed. If the date is fixed, not every new idea can enter the next release. You can pretend this tension does not exist, but the codebase will not care. Gitflow is not fashionable. It is not the fastest way to ship software. But with traditional customers, it solves a real problem: it makes release scope visible. Visible scope keeps fixed-date projects from turning into weekly negotiation theater. ## What Gitflow actually gives you Gitflow is a branching model with clear jobs for clear branches. - **main** is production - **develop** is the next version in progress - **feature branches** are isolated pieces of work - **release branches** are the version being stabilized - **hotfix branches** are urgent production fixes If you want a quick visual map, [Daniel Kummer's Gitflow cheatsheet](https://danielkummer.github.io/git-flow-cheatsheet/) is still the one I reach for. The useful part is not the branch naming. The useful part is the separation of intent. Code on `develop` means: this is being prepared. Code on a `release` branch means: this is being hardened. Code on `main` means: this is live. Nobody has to ask whether a feature is going out on Friday. The branch already answers the question. ## Why traditional customers need that clarity Customers from banking, insurance, manufacturing, public sector, or any fixed-price environment usually do not think in continuous deployment. They think in releases. They need to know what they are paying for, when it ships, and what happens when the business changes its mind two weeks before go-live. Gitflow gives you a structure for that conversation. The release branch becomes the thing everyone can point at. This is the release. This is what is still allowed to change. This is what moves to the next release. Traditional customers do not only buy software. They buy predictability: approvals, training plans, rollout windows, support preparation, sometimes even regulatory sign-off. If your release process is fuzzy, their internal process breaks. ## The workflow I use in practice The rhythm is simple. A new feature starts on a feature branch from `develop`. When it passes review, it merges back into `develop`. At that point, the feature is done from a development perspective, but not shipped. Roughly two weeks before the contractual release date, `develop` is forked into a versioned release branch. From that moment on, the rule changes. No new scope enters the release branch. Only bug fixes, stabilization work, documentation fixes, and release-critical adjustments. The release branch is tested, approved, merged into `main`, tagged, and shipped. Everything else goes to `develop`. That is the sentence that saves the project: "This goes into the next release, not this one." Not because the team is difficult. Because the current release has entered stabilization, and changing it now changes the risk profile. Traditional customers can accept that. What they cannot accept is finding out one day before go-live that the release is unstable because five "small changes" slipped in unnoticed. Small changes are rarely small at the end of a release. ## Gitflow as a customer communication tool Most teams talk about Gitflow as a developer workflow. That misses half the value. Gitflow is also a communication tool. It gives project managers, customers, QA, and developers a shared language for release state. You can say: - "This is already in the release branch." - "This is merged to develop, but not part of the current release." - "This is a hotfix and does not touch the next planned release." - "This is new scope and needs to wait for the next release window." Those are not technical details. Those are commercial boundaries. They protect the team from hidden scope creep, the customer from surprise delays, and the relationship from the usual end-of-project drama. ## Where Gitflow is the wrong tool Gitflow is heavy. If your team ships ten times a day, do not use it. If your product runs on continuous delivery, feature flags, automated tests, fast rollback, and tight observability, trunk-based development is usually better. The industry moved toward trunk-based development for good reasons: faster feedback, smaller changes, less branch drift, fewer painful merges. But not every customer lives in that world. Use Gitflow when: - You ship on a calendar, not whenever the pipeline is green - The customer needs a stable release candidate for testing - QA or compliance needs days, not minutes - Release scope is contractually relevant - The customer expects formal acceptance before go-live - Your team is small enough that long-running branches do not become a merge conflict factory For most teams, that limit is somewhere below 30 active engineers. After that, Gitflow can become expensive fast. ## The mistake to avoid Do not hide behind Gitflow. A process does not fix bad planning, unclear ownership, or a customer who keeps changing scope but refuses to move dates or budget. Gitflow only works if you use it to make decisions explicit. When a release branch is cut, the team and the customer need to understand what that means. New scope is not "almost included." It is out. Unless there is a conscious decision to change the release. That decision has a cost. Maybe the date moves. Maybe other scope gets removed. Maybe the budget changes. Maybe the risk is accepted in writing. But it is a decision now, not a surprise later. ## The real lesson The workflow is not the point. The point is release scope. Traditional customers need a clear answer to one question: "What is in the next release, and what is not?" If you can answer that without hesitation, you are already ahead of most delivery teams. Gitflow is one way to make the answer obvious. Not because it is modern. Not because it is elegant. Because it maps well to customers who still buy software in release packages, sign acceptance documents, and plan rollouts around calendar dates. A lot of those customers still pay very well. So yes, trunk-based development is often better for modern product teams. But when you work with traditional customers, the best workflow is not always the fastest one. It is the one that makes promises visible before they become problems.