liveBook · Manning

Git Flow

As explained in Think Like a CTO

A Git branching model with separate master and develop branches and feature branches merged into develop before release.

Git Flow separates deployable code from ongoing development through master and develop branches. Feature branches start from develop, undergo review, and merge back into develop; releases merge develop into master. Direct commits to either main branch are avoided. section 9.3

Adapt the model to the team’s operating environment by deciding:

  • How feature branches connect to the ticket system. section 9.3
  • Branch naming, granularity, and expected lifetime. section 9.3
  • Release cadence and the tooling or reporting needed to support it. section 9.3

A release path

A team creates a feature branch from develop, reviews and tests it, merges it into develop, and later merges develop into master when preparing a deployable release. section 9.3

How Think Like a CTO covers it

How deep it goes
Explains branch roles and merge paths, while deferring naming, lifetime, ticket integration, and release cadence to each environment.
Examples
Uses master, develop, and feature branches to illustrate reviewed development and release merges.
What it assumes
Assumes familiarity with version-control rules and tools, while leaving team-specific workflow conventions open for design.
What you can do after
Apply it via Git by structuring feature work, reviews, integration, and releases across defined branches.
How it connects
Connects version control with feature branches, code review, releases, ticket systems, and GitHub Flow.

Also explained in

Compare how 3 books explain Git Flow →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a CTO. The section links point to the parts of the book it draws on.