Cooking a meal has stages: planning, preparation, cooking, plating. Cooking several dishes at once may need several people. Split the work into small steps and delegate. The meal finishes on time.

Git Flow follows the same principle. It breaks a complex task into small stages and assigns duties. This streamlines software development and gives a top-notch product.

What is Git Flow?

Developers use Git, a version control system, to manage their codebase. More on Git: https://vulehuan.com/en/r/LGK9yaMmhZd.

Vincent Driessen created Git Flow in 2010 as a branching model for Git. Driessen wrote a blog post (https://nvie.com/posts/a-successful-git-branching-model/) explaining his strategy, "A Successful Git Branching Model." It gained popularity among developers. Many teams adopted Git Flow, now a widely used methodology.

Git Flow is a branching model for Git. It helps teams manage and coordinate development by splitting work into distinct stages, each with its own branch. Members work on different features concurrently without disrupting each other.

Git Flow has two main branches: "master" for stable, production-ready code, and "develop" for ongoing development. Feature, release, and hotfix branches are created as needed for new features, release preparation, or critical fixes. This keeps the workflow organized, avoids conflicts, and ensures high code quality and stability.

Git Flow gives teams a structured workflow. It helps manage the codebase, avoid conflicts, and keep quality and stability. This blog covers its benefits, bug handling, and multiple developers on one project.

How Git Flow can be utilized for a feature branch?

  • Feature branch creation: Create a feature branch for a new feature. Run git flow feature start feature-name. This creates "feature/feature-name" from "develop".
  • Feature development: Work without affecting "develop". Add and commit changes to the feature branch.
  • Feature branch merging: When complete, run git flow feature finish feature-name. This merges changes into "develop", deletes the feature branch, and switches you back to "develop".
  • Changes review: Review and test changes thoroughly before merging "develop" into "master" for release. This keeps the feature stable.

Git Flow manages feature development in an organized way. Multiple developers work on different features without interference.

Run "git pull" on "develop" before finishing a feature branch to get the latest changes. After git flow feature finish feature-name, you return to "develop". Run "git push" so others can access your changes.

Example: add login functionality with Git Flow:

  • Run git checkout develop && git pull && git flow feature start login to create "feature/login" from "develop".
  • Work on "feature/login" without affecting "develop". Add a login form and logic, then commit.
  • Review and test the feature. Create a "Pull Request" to merge "feature/login" into "develop" for code review and testing.
  • After review, run git checkout develop && git pull && git flow feature finish login && git push origin develop. This merges changes into "develop", deletes "feature/login", and switches you back to "develop".
  • When all features are merged into "develop", merge it into "master" for release and deployment. Learn more about release branches in this blog.

Teams can also use Git Flow for a release branch, created to prepare a new version for production. Examples:

How Git Flow can be utilized for a release branch?

Run git flow release start release-name to create "release/release-name" from "develop".

Developers prepare the release without affecting "develop". They make final bug fixes and commit changes to the release branch.

Test the release thoroughly. Create a "pull request" to merge "release/release-name" into "master" for testing.

After review and testing, run git flow release finish release-name. This merges changes into both "develop" and "master", deletes the release branch, and switches you back to "develop".

This workflow keeps releases structured and organized, ensures high code quality and stability, and avoids conflicts.

To finish a release, pull changes from "develop" and "master" before git flow release finish release-name. Then push to both branches with git push. A tag is created automatically for the release. Push the tag so others know which code runs in production. List tags with "git tag"; switch tags with git checkout tag-name. Push tags with git push --tags or git push origin tag-name.

Example: release version 1.0:

  • Creating a release branch: run git checkout develop && git pull &&  git flow release start 1.0. This creates "release/1.0" from "develop".
  • Preparing the release: make final bug fixes and commit changes. Update the version number, fix critical bugs, and ensure all tests pass.
  • Testing the release: create a "pull request" to merge "release/1.0" into "master" for testing. Testers review all features and check for major issues.
  • Finalizing the release: run git checkout develop && git pull && git checkout master && git pull && git flow release finish 1.0. This merges changes into both "develop" and "master", deletes "release/1.0", and switches you back to "develop".
  • Push both branches and tag "1.0": git push origin develop && git push origin master && git push origin 1.0

Popular release naming rules and conventions

  • Semantic Versioning: three-part version numbers (e.g. 1.2.3) for major, minor, and patch releases. More: https://semver.org/
  • Calendar Versioning: release date as the version number (e.g. 2022.03.01). More: https://calver.org/
  • Animal Names: animal names for releases, like Ubuntu and Google Android releases. More on Ubuntu: https://wiki.ubuntu.com/DevelopmentCodeNames.
  • Named Releases: unique, memorable names, like Apple's big cat names for OS X (Mountain Lion, Lion, Leopard, etc.).
  • Sequential Numbering: sequential numbers, like Microsoft Windows versions (Windows 10, Windows 11).

How Git Flow can be utilized for a hotfix branch?

A critical bug needs immediate fixing. The hotfix flow addresses it without disrupting regular development. For example, security vulnerabilities in a web application can be fixed with a hotfix branch from "master", then merged into both "master" and "develop". A critical mobile app bug can be fixed and deployed to production without waiting for the regular release cycle.

Git Flow uses a hotfix branch for urgent production issues. Run git flow hotfix start hotfix-name to create "hotfix/hotfix-name" from "master". Developers fix the issue and commit changes. Test thoroughly with a "pull request" to merge the hotfix into "master" for testing. After review, run git flow hotfix finish hotfix-name. This merges changes into both "master" and "develop", deletes the hotfix branch, and switches back to "develop". This workflow addresses urgent production issues quickly while keeping quality and stability and avoiding conflicts.

To finish a hotfix, pull changes from "develop" and "master" before git flow hotfix finish hotfix-name. Then push to both branches with git push. A tag is created automatically for the hotfix. Push the tag so others know which code runs in production. List tags with "git tag"; switch tags with git checkout tag-name. Push tags with git push --tags or git push origin tag-name.

Version a hotfix branch by adding a suffix to the previous release version. If the prior release was 1.0, the hotfix could be 1.0.1, then 1.0.2. Schemes vary by project and team. Keep the version number clear and consistent for tracking. After merging into "master", update the new version number in the appropriate files and commit to "master" so the next release reflects it.

Example: critical issue in production with tag 1.2.0:

  • Creating a hotfix branch: run git checkout master && git pull && git flow hotfix start 1.2.1. This creates "hotfix/1.2.1" from "master".
  • Making the hotfix: fix the issue in "hotfix/1.2.1" and commit. Eg: git commit -m "Fix critical bug XYZ"
  • Testing the hotfix: create a "pull request" to merge "hotfix/1.2.1" into "master" for testing. Ensure it resolves the issue without new issues.
  • Finalizing the hotfix: run git checkout develop && git pull && git checkout master && git pull && git flow hotfix finish 1.2.1. This merges changes into both "master" and "develop", deletes "hotfix/1.2.1", and switches you back to "develop".
  • Push both branches and tag "1.2.1": git push origin develop && git push origin master && git push origin 1.2.1

The Bugfix and the Support Branches

Git Flow uses a bugfix branch to resolve a specific issue in the codebase. It is created from the release branch and merged back into both the release (release/release-name) and development (develop) branches after testing and validation.

Bugfix process:

  • Identify the issue: review bug reports, user feedback, or tests to find the specific bug.
  • Create a bugfix branch: create it from the latest release branch (release/release-name) with a name that reflects the issue.
  • Implement the necessary changes: update code lines, configuration files, or other parts of the codebase.
  • Test and verify the fix: run automated tests, manual tests, or both.
  • Merge the fix into the release branch: merge it into the release branch (release/release-name) so the next release includes it.
  • Merge the fix into the development branch: merge it into development so all future releases include it.

Support branches are created from "master" to provide long-term support for a specific release version. They provide bug fixes and security updates for that version without affecting newer versions. Naming includes the version number, such as "support/1.0.x". They are long-lived and need clear documentation and procedures, especially for critical applications such as medical or financial software.

Install Git Flow

On Ubuntu, check Git with sudo apt-get update && sudo apt-get install git. More on Git: https://vulehuan.com/en/r/LGK9yaMmhZd. Then install Git Flow with sudo apt-get install git-flow. Other installation options: https://github.com/nvie/gitflow/wiki/Installation.

Initialize Git Flow in your repository. Navigate to the project directory and run git flow init. Choose configuration options such as the development and production branch names. Add the "-d" flag to git flow init to use defaults and skip prompts.

Then use Git Flow in your workflow. Create a feature branch with git flow feature start [name]; finish it with git flow feature finish [name]; publish it with git flow feature publish [name]. Track a remote feature branch with git flow feature track [name]; pull changes with git flow feature pull [remote] [name].

Similar commands exist for release, hotfix, and support branches. For example, git flow release start [version], git flow release finish [version], and git flow release publish [version]. Use the relevant "track" or "pull" commands for remote branches.

git flow version shows the Git Flow version; git flow config shows configuration options; git flow help shows help.

Note: git flow XYZ publish [name] and git push XYZ/[name] both push an XYZ branch to a remote, but differ. git flow XYZ publish [name] publishes a feature/release/hotfix/support branch to a remote. git push XYZ/[name] pushes local changes on that branch to the remote branch.

Other widely used Git workflows

  • GitLab flow: optimized for collaboration and continuous integration (CI), used by GitLab. It emphasizes feature branches and merge requests, and suits teams of all sizes. More: https://docs.gitlab.com/ee/topics/gitlab_flow.html
  • GitHub flow: a lightweight, branch-based workflow for continuous delivery and deployment, used by GitHub. It emphasizes feature branches and pull requests, and suits small, fast-moving teams. More: https://guides.github.com/introduction/flow/
  • OneFlow: a branching model and workflow that simplifies Git with a single branch, used by Spotify and Walmart Labs. It emphasizes continuous delivery and deployment, and suits teams of all sizes. More: https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow
  • Trunk-Based Development (TBD): emphasizes short-lived feature branches and continuous integration, used by Google and Amazon. It suits large, distributed teams and minimizes merge conflicts and regressions. More: https://trunkbaseddevelopment.com/
  • Forking Workflow: common in open-source projects where contributors lack write access. Contributors fork the main repository, make changes in their fork, then submit a pull request. This allows collaboration and review while keeping strict control over the main repository.

Conclusion

Git Flow offers a well-structured branching strategy that streamlines software development. Teams manage multiple codebase versions while keeping top-notch quality and stability. The hotfix branch quickly addresses critical production issues without disrupting regular development. Follow proper hotfix procedures, including versioning and updating later releases. Git Flow ensures efficient development, fewer errors and conflicts, and high-quality software.