Chapters
Chapters

Chapters

Hide chapters

Advanced Git

Before You Begin

Section 0: 4 chapters
Show chapters Hide chapters

Section I: Advanced Git

Section 1: 7 chapters
Show chapters Hide chapters

Section II: Git Workflows

Section 3: 5 chapters
Show chapters Hide chapters

10. Gitflow Workflow
Written by Jawwad Ahmad

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

You can unlock the rest of this book, and our entire catalogue of books and videos, with a Kodeco Personal subscription.

Unlock now

Gitflow is a workflow that Vincent Driessen introduced in his 2010 blog post, A successful Git branching model, https://nvie.com/posts/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: master 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, which is the master branch. 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:

Gitflow’s branching and merging flow for feature, release and hotfix branches
Womtsux’r crimxjoqr agj rofwekg hkef fep toazira, vakoidi otw dinxin kwefptuk

An alternate flow for hotfix and release that back-merges master into develop
Uf ubgosbopu gqev fik zafmus eng daxoozi vyay motv-haqxis gezcic aybe sunakuj

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 master, tag the release, merge it back into develop and then finally delete the release branch.

brew install git-flow-avh

git flow version

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.

starter
└── repos
    ├── alex
    │   └── checklists
    └── checklists.git

cd path/to/starter/repos/alex/checklists

git flow init

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] v
Hooks and filters directory? [...]

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 master, you create feature branches from develop and merge them back into develop when you’re finished. You cannot create feature branches from master or any of the other short-lived branches.

git flow feature start update-h1-color

git checkout -b feature/update-h1-color  # equivalent to above

Summary of actions:
- A new branch 'feature/update-h1-color' was created, based on 'develop'
- You are now on branch 'feature/update-h1-color'

 h1 {
-    color: navy;
+    color: blue;
 }

git commit -am "Updated h1 color from navy to blue"

1. Checkout the develop branch            # git checkout develop
2. Merge the feature branch  # git merge feature/update-h1-color
3. Delete the branch     # git branch -d feature/update-h1-color

git flow feature finish

Summary of actions:
- The feature branch 'feature/update-h1-color' was merged into 'develop'
- Feature branch 'feature/update-h1-color' has been locally deleted
- You are now on branch 'develop'

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.

git flow release start 1.0.0 --showcommands

git checkout -b release/1.0.0 develop

echo '1.0.0' > VERSION
git add VERSION
git commit -m "Adding VERSION file for initial release"

# Merge release into master
git checkout master
git merge --no-ff release/1.0.0

# Tag the release
git tag -a v1.0.0

# Merge master back to develop
git checkout develop
git merge --no-ff master

# Delete the branch
git branch -d release 1.0.0

git flow release finish --showcommands

Summary of actions:
- Release branch 'release/1.0.0' has been merged into 'master'
- The release was tagged 'v1.0.0'
- Release tag 'v1.0.0' has been back-merged into 'develop'
- Release branch 'release/1.0.0' has been locally deleted
- You are now on branch 'develop'

git checkout master
...
git merge --no-ff release/1.0.0
...
git tag -a v1.0.0
git checkout develop
...
git merge --no-ff v1.0.0  # instead of: git merge --no-ff master
...
git branch -d release/1.0.0

git -P log --oneline -1 v1.0.0
git -P log --oneline -1 master

85c2e4e (tag: v1.0.0, master) Merge branch 'release/1.0.0'

Back-merging master versus merging release

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

Back-merging master into develop
Tapj-liylavw voymet oska ziquwey

Merging the release branch into develop
Vigpoxy nzo lokaepe nwawwd asse zeciqar

Creating and merging a hotfix branch

You use hotfix branches to fix bugs in production, so you must create them from the master branch.

git flow hotfix start 1.0.1 --showcommands

git checkout -b hotfix/1.0.1 master

 h1 {
-    color: blue;
+    color: midnightblue;
 }

git commit -am "Updated h1 color from blue to midnightblue"

echo '1.0.1' > VERSION

git commit -am "Updated VERSION to 1.0.1"

git flow finish --nobackmerge --showcommands

Summary of actions:
- Hotfix branch 'hotfix/1.0.1' has been merged into 'master'
- The hotfix was tagged 'v1.0.1'
- Hotfix branch 'hotfix/1.0.1' has been merged into 'develop'
- Hotfix branch 'hotfix/1.0.1' has been locally deleted
- You are now on branch 'develop'

- Hotfix tag 'v1.0.1' has been back-merged into 'develop'

git checkout master
...
git merge --no-ff hotfix/1.0.1
...
git tag -a v1.0.1
git checkout develop
...
git merge --no-ff hotfix/v1.0.1  # not: git merge --no-ff v1.0.1
...
git branch -d hotfix/1.0.1

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:

{tag}-{number-of-additional-commits-from-tag}-g{commit hash}

v1.0.0-4-g827ddd8

827ddd8 (HEAD -> develop) Merge branch 'hotfix/1.0.1' into de...
b4990c4 Updated VERSION to 1.0.1
20df16b Updated h1 color from blue to midnightblue
404639f Merge tag 'v1.0.0' into develop
2249859 (tag: v1.0.0) Merge branch 'release/1.0.0'

fatal: No tags can describe 'c0623652f3f7979f664918689fca42e9...

v1.0.1

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.

Available subcommands are:
   init      Initialize a new git repo with support for the b...
   feature   Manage your feature branches.
   bugfix    Manage your bugfix branches.
   release   Manage your release branches.
   hotfix    Manage your hotfix branches.
   support   Manage your support branches.
   version   Shows version information.
   config    Manage your git-flow configuration.
   log       Show log deviating from base branch.

Try 'git flow <subcommand> help' for details.

$ git flow release help
usage: git flow release [list]
   or: git flow release start
   or: git flow release finish
   or: git flow release publish
   or: git flow release track
   or: git flow release delete

    Manage your release branches.

    For more specific help type the command followed by --help

$ git flow release publish --help
usage: git flow release publish [-h] <name>

    Publish the release branch <name> on origin

    -h, --help            Show this help
    --showcommands        Show git commands while executing them

Key points

  • The master 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.
  • Use hotfix branches to fix bugs you’ve already released to production.
  • You create feature branches from develop and merge them to develop.
  • You create release branches from develop and merge them to master and develop.
  • You create hotfix branches from master and merge them to master and develop.
  • Install the newer AVH version of git-flow with brew install git-flow-avh.
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.
© 2023 Kodeco Inc.

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a kodeco.com Professional subscription.

Unlock now

Access this book

To highlight or take notes, you'll need to own this book in a subscription or purchased by itself.

Read for Free with a Subscription

Buy this book for $59.99