GitFlow: A Branching Model for Versioned Releases
GitFlow organizes your repo around two main branches: master for production and develop for integration. It's designed for projects with distinct, numbered releases, like desktop apps, not for continuously delivered web apps where simpler models are…
Why it exists
Git's flexibility with branching is powerful but can lead to chaos without a shared process. GitFlow was created in 2010 to impose a structured workflow on development, providing a robust model for managing projects with scheduled, versioned releases.
The mental model
Think of GitFlow as a two-lane highway for your code. The master branch is the stable, slow lane where only finished, tagged releases are allowed. The develop branch is the faster-moving integration lane where all new work eventually merges. Temporary branches for features, releases, and hotfixes act as on-ramps and off-ramps, managing the flow of changes between the two main lanes.
How it works
The model centers on two infinite-lifetime branches: master and develop. The master branch's HEAD always points to a production-ready, tagged version. The develop branch contains the latest integrated changes for the next release. Supporting this are three temporary branch types: First, feature branches are for new work. They branch from develop and merge back into develop. Second, release branches prepare a new release. They branch from develop, allow for final bug fixes and metadata updates, then merge into both master (creating the release tag) and develop (to propagate fixes). Third, hotfix branches address urgent production bugs. They branch from master, are merged back into both master and develop, and are tagged with a patch version number.
When to use it
Use GitFlow when you build software that is explicitly versioned (e.g., v1.0, v1.1) and you need to support multiple versions in the wild. This is typical for libraries, desktop applications, or mobile apps distributed through app stores. The structure helps manage what goes into which release.
When not to use it
Avoid GitFlow for continuously delivered software, like most modern web applications. The model's creator explicitly advises against it for this use case. The overhead of managing release and develop branches is unnecessary when you deploy to production multiple times a day. Simpler models like GitHub Flow or Trunk-Based Development are a better fit.
One canonical example
A team building a library creates a feature/new-parser branch from develop. When done, it's merged back to develop. To prepare for a release, they create release/v2.1.0 from develop. After final testing, this branch is merged into master and tagged v2.1.0. It is also merged back into develop. Later, a critical bug is found in v2.1.0. A hotfix/v2.1.1 branch is created from master, fixed, and then merged back into both master and develop.
Interview question
For which project characteristic is GitFlow explicitly recommended?
- a.Rapid prototyping efforts where unversioned features are frequently merged
- b.Teams prioritizing a single, always-deployable main branch for all development
- c.Projects requiring continuous deployment to production multiple times daily
- d.Software products that are distributed as distinct, versioned releasesCorrect
Why? this is the answer
GitFlow is designed for projects that produce distinct, versioned releases, such as libraries or desktop applications, to manage the lifecycle of specific versions. It is explicitly advised against for continuously delivered software due to its inherent overhead.
Just read this? Test yourself on what you have been reading.
Read the original → nvie.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on git — each one lists the topics its interview covers.
See open roles