Chapters
Chapters

Chapters

Hide chapters

Advanced Git

Third Edition · Git 2.50 · Console

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: Advanced Git

Section 1: 7 chapters
Show chapters Hide chapters

Section II: Git Workflows

Section 2: 5 chapters
Show chapters Hide chapters

10. Gitflow Workflow
Written by Jawwad Ahmad

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Gitflow is a workflow that Vincent Driessen introduced in his 2010 blog post, A successful Git branching model.

At its core, Gitflow is a specialized version of the branching workflow. It introduces a few different types of branches with well-defined rules on how code can flow between them.

Vincent posted a ten-year update titled “Note of reflection” on March 5th, 2020, at the beginning of his original blog post. In his note, he recommends that you should consider whether this is the right workflow for you.

He notes that Gitflow is great for versioned software, but a simpler approach might work better in today’s age of continuous deployment. He ends his note with the words: “Decide for yourself.”

In this chapter, you’ll learn about the rules that make up Gitflow, as well as the reasons behind them. This will allow you to decide if Gitflow is right for you.

When to use Gitflow

Gitflow is a good fit if you’re building software that’s explicitly versioned, especially if you need to support multiple versions of your software at the same time. For example, you might release a 2.0 version of a desktop app that’s a paid upgrade, but still want to continue releasing minor bug fix updates for the 1.0 version.

Gitflow is also a good fit if your project has a regular release cycle. Its release branch workflow allows you to test and stabilize your release while normal day-to-day development continues on your main development branch.

Managing larger projects is easier with Gitflow since it has a well-defined set of rules for the movement of code between branches.

Gitflow is less ideal in scenarios that favor a continuous deployment model, such as web development. In these situations, Gitflow’s release workflow might add unnecessary extra overhead.

Chapter roadmap

In this chapter, you’ll first get a quick introduction to the basic concepts in Gitflow. You’ll learn about the different long-lived and short-lived branches and the rules for how to create and merge them.

Types of Gitflow branches

Gitflow uses two long-lived branches: main and develop and three main types of short-lived branches: feature, release and hotfix. While you never delete long-lived branches, you delete short-lived branches once you merge them into a long-lived branch.

Long-lived branches

Git itself uses a single long-lived branch, typically named main. Gitflow introduces the concept of an additional long-lived production branch.

Short-lived branches

The three main types of short-lived branches are feature, release, and hotfix.

Rules for creating and merging branches

Here are the rules for creating and merging branches:

Cugzted’d pyawhxens idc buphidh hmag nig heehaja, dedeesi idv waczaw bnilvtuv
Zefhwal’h sxixcbuqf opk jaywogr bfow gen qeajohe, dijaasi ecl qitlet zwucchih

Er aqjovkica xpag loc vobvud awk nebiufu rgic fopt-safpis heup atmo voqifib
Ol ecqusdofe yyex dan ricjuf ivl zopeesa zkem melp-bazyew veot ovni tenigos

Installing git-flow

The git-flow extensions are a library of Git subcommands that make it easier to adopt the Gitflow workflow. For example, a single git flow release finish command will merge your release branch into main, tag the release, merge it back into develop and then finally delete the release branch.

Initializing git-flow

Unzip repos.zip from the starter folder for this chapter. You’ll only be working within the alex/checklists repository, so the beth and chad directories from previous chapters aren’t included.

Creating and merging a feature branch

Gitflow uses feature branches for work on new features, just as the branching workflow does. Since the day-to-day development branch in Gitflow is now develop instead of main, you create feature branches from develop and merge them back into develop when you’re finished. You cannot create feature branches from main or any of the other short-lived branches.

Creating and merging a release branch

Release branches are where you prepare code for an upcoming release. They let you run tests and implement fixes while the day-to-day development continues on the development branch.

Back-merging main versus merging release

The following image shows the steps that took place when you back-merged main into develop:

Loqq-wugcign vuum atpu cuwoziz
Qedt-duzteyd noif oymo davofer

Toqnuyz lti wopuibo jkufcm owra danisob
Sezgoly jjo lazuiqa qwixyt impe pedopih

Creating and merging a hotfix branch

Since hotfix branches are used to fix bugs in production, you must create them from the main branch.

Using git describe

The git describe command shows you the most recent tag that’s accessible from a commit. If the tag is on the current commit, git describe will show the tag itself. On the other hand, if the tag is on one of the ancestors, it will also show the number of additional commits and the commit hash in the following format:

Exploring the git-flow library

The git-flow library includes a few additional commands that can be helpful, such as delete for deleting a type of branch or publish for pushing it to the remote.

Alternatives to git-flow-avh

While installing git-flow you may have noticed the following warning:

Key points

  • The main branch serves as the production branch.
  • The develop branch is for normal day-to-day development.
  • Feature branches are used for new feature development.
  • Release branches are used to test, stabilize and deploy a release to production.
  • Hotfix branches are used to fix bugs you’ve already released to production.
  • Feature branches are created from develop and merged back into to develop.
  • Release branches are created from develop and merged into both main and develop.
  • Hotfix branches are created from main and are also merged into both main and develop.
9. Feature Branch Workflow
11. Forking Workflow
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now