Understanding Git Flow: A Structured Workflow for Software Development Teams

Cooking a meal involves several stages, such as planning, preparation, cooking, and plating. If you have to cook multiple dishes simultaneously, various people may be responsible for different parts of the meal. By dividing the cooking process into smaller, more manageable steps and delegating tasks among different people, you can ensure that the meal is prepared on time and to your satisfaction.

The principles of Git Flow are akin to the process of cooking a meal, as they both entail breaking down a complicated task into smaller, more manageable stages and delegating responsibilities to different individuals. Git Flow accomplishes this by dividing the software development process into distinct stages like feature development, testing, and release, with team members, allocated specific duties. This methodology guarantees that the software development process is streamlined and yields a top-notch product.

What is Git Flow?

Software developers frequently employ Git, a version control system, to manage their codebase. Additional information on Git can be found at https://vulehuan.com/en/blog/2023/03/understanding-git-and-other-version-control-systems-42.html.

Git Flow was created by Vincent Driessen in 2010 as a branching model for Git. Driessen wrote a blog post (https://nvie.com/posts/a-successful-git-branching-model/) explaining his branching strategy, which he called "A Successful Git Branching Model," and it gained popularity among developers. The Git Flow model has since been adopted by many software development teams and has become a widely used methodology for managing the software development process.

Git Flow is a model used for branching in Git, which is a widely-used version control system utilized in software development. Its primary goal is to assist teams in managing and coordinating their software development workflow by dividing the process into multiple distinct stages, with each phase having its own branch. This allows team members to work on different features and changes concurrently without disrupting each other's work.

The Git Flow model typically comprises two main branches, namely the "master" branch, representing the stable, production-ready code, and the "develop" branch, which serves as the foundation for ongoing development. Additional branches such as feature branches, release branches, and hotfix branches are established when required to aid specific tasks such as adding new features, testing and preparing for release, or resolving critical issues. By following the Git Flow branching model, teams can maintain a well-organized workflow, evade conflicts, and ensure a high level of code quality and stability.

[CIMG ID=d96b312a-a11c-4678-1422-fa71020e8000]

Git Flow is a valuable branching model for software development teams, providing a structured and organized workflow. By using Git Flow, teams can overcome common challenges in software development such as managing the codebase, avoiding conflicts, and maintaining code quality and stability. In this blog, we will dive deeper into the benefits of Git Flow and provide examples of how it can help teams tackle bugs and handle multiple developers working on the same project.

How Git Flow can be utilized for a feature branch?

• Feature branch creation: In Git Flow, a feature branch is established when a new feature is being developed. To initiate a feature branch, you would utilize the command git flow feature start feature-name in your terminal. This creates a new branch named “feature/feature-name” based on the "develop" branch.
• Feature development: Once the feature branch is set up, developers can work on their feature without affecting the "develop" branch. They can add and commit their changes to the feature/feature-name” branch as they work on it.
• Feature branch merging: When the feature is completed, it can be merged into the “develop” branch using the command git flow feature finish feature-name in your terminal. This will merge the changes in the “feature/feature-name” branch back into “develop”, delete the “feature/feature-name” branch, and switch you back to the “develop” branch.
• Changes review: Following the merging of the feature branch, the changes should be thoroughly reviewed and tested before merging the “develop” branch into the “master” branch for release. This ensures that the new feature is stable and does not cause any issues.

In summary, the Git Flow branching model enables teams to manage their feature development process in an organized and structured way. It also allows multiple developers to work on different features simultaneously without causing interference with each other's work.

[CIMG ID=c2a53986-d07c-4a98-3e81-b0d3eaf9a500]

It's a good practice to perform a "git pull" on the "develop" branch before finishing a feature branch, as this ensures that you have the most up-to-date changes from other team members. After finishing the feature branch with git flow feature finish feature-name, you will be automatically switched back to the "develop" branch. At this point, you should perform a "git push" to push your changes to the remote repository so that other team members can access the changes you've made.

To illustrate, suppose you want to add login functionality to your software using Git Flow:

• First, you would run the command git checkout develop && git pull && git flow feature start login in your terminal to create a new branch called "feature/login" based on the "develop" branch.
• Then, developers can work on the "feature/login" branch without affecting the "develop" branch by making their changes and committing them to the “feature/login” branch. For example, they can add a login form and logic to the branch.
• Once the feature is complete, it should be reviewed and tested to ensure it meets the desired functionality and quality standards. This can be done by creating a "Pull Request" to merge the "feature/login" branch into the "develop" branch for code review and testing.
• After successful review and testing, the changes can be merged back into the "develop" branch using the command git checkout develop && git pull && git flow feature finish login && git push origin develop. This will merge the changes in the "feature/login" branch into "develop", delete the "feature/login" branch, and switch you back to the "develop" branch.
• Finally, once all the features have been developed and merged into the "develop" branch, it can be merged into the "master" branch for release and deployment. You can learn more about how Git Flow can be used for a release branch in this blog.

Software development teams can also utilize Git Flow for a release branch. A release branch is created when the team is ready to prepare for a new version of the software to be released to production. Here are some examples of how Git Flow can be utilized for a release branch:

How Git Flow can be utilized for a release branch?

To create a release branch in Git Flow, you would run the command git flow release start release-name in your terminal. This creates a new branch called "release/release-name" that is based on the "develop" branch.

Once the release branch is created, developers can work on preparing the release without affecting the "develop" branch. They can make final bug fixes and changes to ensure the release is stable, and commit their changes to the release branch as they work on it.

After preparing the release, it should be tested thoroughly to ensure it meets the desired functionality and quality standards. This can be done by creating a "pull request" to merge the "release/release-name" branch into the "master" branch for testing.

Once the release is reviewed and tested, it can be merged back into both the "develop" and "master" branches by running the command git flow release finish release-name in your terminal. This will merge the changes in the "release/release-name" branch back into both "develop" and "master", delete the "release/release-name" branch, and switch you back to the "develop" branch.

By following the Git Flow branching model for release branches, teams can maintain a structured and organized workflow, ensure a high level of code quality and stability, and avoid conflicts during the release process.

[CIMG ID=398ea2c8-e0f5-44c5-132e-4ecf5aabc700]

The process of using Git Flow to finish a release branch involves pulling changes from the "develop" and "master" branches before finalizing the release branch with git flow release finish release-name. After finalizing the release branch, changes must be pushed to both the "develop" and "master" branches using git push, and a tag is automatically created for the release version. It's important to push the tag to the remote repository so that others can easily identify which code version is being used in production. To list all tags in the Git repository, use "git tag", and to switch to a specific tag, use git checkout tag-name. Use git push --tags or git push origin tag-name to push tags to the remote repository.

For example, if you're preparing to release version 1.0 of your software, you might:

• Creating a release branch: To create a release branch, you would run the command git checkout develop && git pull &&  git flow release start 1.0 in your terminal. This creates a new branch called "release/1.0" that is based on the "develop" branch.
• Preparing the release: Once the release branch is created, developers can work on preparing the release without affecting the "develop" branch. They can make final bug fixes and changes to ensure the release is stable. They can commit their changes to the release branch as they work on it. For example, they might update the version number in the software, fix any critical bugs, and ensure that all tests pass.
• Testing the release: After the release is prepared, it needs to be tested thoroughly to ensure it meets the desired functionality and quality standards. This can be done by creating a "pull request" to merge the "release/1.0" branch into the "master" branch for testing. For example, you might have a team of testers reviews the release to ensure that all features work as expected and that there are no major issues.
• Finalizing the release: Once the release is reviewed and tested, it can be merged back into both the "develop" and "master" branches by running the command git checkout develop && git pull && git checkout master && git pull && git flow release finish 1.0 in your terminal. This will merge the changes in the "release/1.0" branch back into both “develop” and “master”, delete the "release/1.0” branch, and switch you back to the "develop" branch.
• To push the "develop" and "master" branches along with a new tag "1.0", execute the following commands:  git push origin develop && git push origin master && git push origin 1.0

Popular release naming rules and conventions

• Semantic Versioning: This convention involves using three-part version numbers (e.g. 1.2.3) to indicate major, minor, and patch releases respectively. For more information, visit: https://semver.org/
• Calendar Versioning: This convention involves using the date of release as the version number (e.g. 2022.03.01). For more information, visit: https://calver.org/
• Animal Names: This convention involves using animal names for release versions, such as Ubuntu's use of animal names and Google's use of animal names for Android releases. For more information on Ubuntu's naming convention, visit https://wiki.ubuntu.com/DevelopmentCodeNames.
• Named Releases: This convention involves giving releases unique and memorable names, such as Apple's use of big cat names for their OS X releases (e.g. Mountain Lion, Lion, Leopard, etc.).
• Sequential Numbering: This convention involves using a sequential numbering system for releases, such as Microsoft's use of version numbers for Windows releases (e.g. Windows 10, Windows 11).

How Git Flow can be utilized for a hotfix branch?

If you have a software application with a critical bug that requires immediate fixing, the hotfix flow can be used to address the issue promptly without disrupting the regular development process. For instance, if there are security vulnerabilities in a web application, creating a hotfix branch from the "master" branch using the hotfix flow can fix the issue, and the changes can be merged back into both the "master" and "develop" branches. Similarly, if a mobile app has a critical bug that is affecting user experience, the hotfix flow can be utilized to fix the issue and deploy the changes to production without waiting for the regular release cycle.

In software development, Git Flow can also be utilized for a hotfix branch, which is used when an urgent fix is required for an issue in the production environment. To create a hotfix branch, the command git flow hotfix start hotfix-name is used in the terminal, which creates a new branch named hotfix/hotfix-name based on the "master" branch. Developers can work on making the necessary changes to fix the issue and commit their changes to the hotfix branch. The hotfix needs to be tested thoroughly to ensure it resolves the issue and doesn't cause any new issues, which can be done by creating a "pull request" to merge the hotfix/hotfix-name branch into the "master" branch for testing. After review and testing, the hotfix can be merged back into both the "master" and "develop" branches by running the command git flow hotfix finish hotfix-name in the terminal. This will merge the changes in the hotfix/hotfix-name branch back into both "master" and "develop", delete the hotfix/hotfix-name branch, and switch back to the "develop" branch. By following the Git Flow branching model for hotfix branches, teams can quickly address urgent issues in the production environment while maintaining a structured and organized workflow, ensuring a high level of code quality and stability, and avoiding conflicts during the hotfix process.

The process of using Git Flow to finish a hotfix branch involves pulling changes from the "develop" and "master" branches before finalizing the hotfix branch with git flow hotfix finish hotfix-name. After finalizing the hotfix branch, changes must be pushed to both the "develop" and "master" branches using git push, and a tag is automatically created for the hotfix version. It's important to push the tag to the remote repository so that others can easily identify which code version is being used in production. To list all tags in the Git repository, use "git tag", and to switch to a specific tag, use git checkout tag-name. Use git push --tags or git push origin tag-name to push tags to the remote repository.

[CIMG ID=b47c60c8-9dba-40e7-f603-b8ecc1c2b800]

When using Git Flow, versioning a hotfix branch generally requires creating a new version number by adding a suffix to indicate that it's a hotfix, based on the previous release version. For instance, if the prior release version was 1.0, the hotfix version could be 1.0.1, and the following hotfix version could be 1.0.2. The specific versioning scheme may vary depending on the project and team preferences. It is crucial to make sure that the version number is clear and consistent to avoid confusion and enable easy tracking of changes and releases. After the hotfix is merged back into the “master”  branch, the new version number should be updated in the appropriate files and committed to the “master” branch. This guarantees that the new version number is reflected in the subsequent release.

Suppose there's a critical issue in the production (with tag version 1.2.0) environment that needs to be fixed immediately, Git Flow can be used for a hotfix branch:

• Creating a hotfix branch: You would create a new hotfix branch named "1.2.1" by running the command git checkout master && git pull && git flow hotfix start 1.2.1. This creates a new branch called "hotfix/1.2.1" based on the "master" branch.
• Making the hotfix: Developers would then work on fixing the issue by making the necessary changes in the "hotfix/1.2.1" branch. They can commit their changes to the hotfix branch as they work on it. Eg: git commit -m "Fix critical bug XYZ"
• Testing the hotfix: Once the hotfix is made, it needs to be tested thoroughly to ensure it resolves the issue and doesn't cause any new issues. This can be done by creating a "pull request" to merge the hotfix/1.2.1 branch into the "master" branch for testing.
• Finalizing the hotfix: Once the hotfix is reviewed and tested, it can be merged back into both the "master" and "develop" branches by running the command: git checkout develop && git pull && git checkout master && git pull && git flow hotfix finish 1.2.1. This will merge the changes in the "hotfix/1.2.1" branch back into both "master" and "develop", delete the "hotfix/1.2.1" branch, and switch you back to the "develop" branch.
• To push the "develop" and "master" branches along with a new tag "1.2.1", execute the following commands:  git push origin develop && git push origin master && git push origin 1.2.1

The Bugfix and the Support Branches

GitFlow employs a bugfix branch, which is a type of branch that aims to resolve a specific issue or bug in the codebase. This branch is generated from the release branch and subsequently merged back into both the release (release/release-name) and development (develop) branches upon successful testing and validation.

To address a bug, the process in GitFlow typically follows the below steps:

• Identify the issue: This involves reviewing bug reports, analyzing user feedback, or performing tests to identify the specific bug or issue that needs to be fixed.
• Create a bugfix branch: After identifying the bug, a new bugfix branch should be created from the latest release branch (release/release-name), and it should bear a name that reflects the issue being resolved.
• Implement the necessary changes: The next step is to implement the changes that will fix the bug. This may require updating specific code lines, modifying configuration files, or making other adjustments to the codebase.
• Test and verify the fix: It is crucial to test and verify that the fix works as expected. This may involve running automated tests, performing manual testing, or both.
• Merge the fix into the release branch: Once the fix has been tested and validated, it should be merged back into the release branch (release/release-name). This ensures that the bug fix will be included in the next software release.
• Merge the fix into the development branch: Finally, the bug fix should be merged back into the development branch to ensure that the fix is incorporated into all future releases.

On the other hand, Support branches are created from the "master" branch in Git Flow to provide long-term support for a specific release version of the software. Support branches are useful for providing bug fixes and security updates for the particular release version, without affecting the development of newer versions. The naming convention for support branches includes the version number, such as "support/1.0.x". These branches are generally long-lived and require clear documentation and procedures to manage and update them over time, particularly for critical applications such as medical or financial software.

Install Git Flow

To install Git Flow on Ubuntu, you can start by checking if Git is already installed by running the command sudo apt-get update && sudo apt-get install git in your terminal. More information on Git can be found at https://vulehuan.com/en/blog/2023/03/understanding-git-and-other-version-control-systems-42.html. Once Git is installed, you can then proceed to install Git Flow by running sudo apt-get install git-flow. Other installation options for different operating systems can be found at https://github.com/nvie/gitflow/wiki/Installation.

After installing Git Flow, you need to initialize it in your Git repository. To do this, navigate to your project's directory in the terminal and run the command git flow init. This will prompt you to choose some configuration options for Git Flow, such as the names of your development and production branches. If you want to use the default configuration options, you can pass the "-d" flag when running the git flow init command to bypass the prompts.

[CIMG ID=bcc43b6f-ebd0-4663-7139-e4ca44687300]

Once Git Flow is initialized, you can start using its branching model in your workflow. Some common Git Flow commands include creating a new feature branch and switching to it using git flow feature start [name], finishing a feature branch and merging changes back into the develop branch using git flow feature finish [name], and publishing a feature branch to a remote repository using git flow feature publish [name]. To track a remote feature branch, you can use git flow feature track [name], and to pull changes from a remote feature branch, you can use git flow feature pull [remote] [name].

Similar commands are available for release, hotfix, and support branches. For example, git flow release start [version] creates a new release branch, git flow release finish [version] finishes a release branch and merges changes back into the develop and master branches, and git flow release publish [version] publishes a release branch to a remote repository. To track or pull changes from remote branches of these types, you can use the relevant "track" or "pull" commands.

Additionally, git flow version displays the current version of Git Flow, git flow config displays Git Flow configuration options, and git flow help displays help information for Git Flow commands.

Note that git flow XYZ publish [name] and git push XYZ/[name] are both used to push an XYZ branch to a remote repository, but they have different functions. git flow XYZ publish [name] publishes a feature/ release/ hotfix/ support branch to a remote repository, while git push XYZ/[name] pushes the local changes on a feature/ release/ hotfix/ support branch to the remote branch.

Other widely used Git workflows

[CIMG ID=cb65ad1d-92b6-4669-64fa-10310b0f0100]

• GitLab flow: The GitLab flow is a workflow that is optimized for collaboration and continuous integration (CI) and is used by GitLab, a popular Git repository management tool. This workflow emphasizes feature branches and merge requests, and is suitable for teams of all sizes. For more information, see: https://docs.gitlab.com/ee/topics/gitlab_flow.html
• GitHub flow: The GitHub flow is a lightweight, branch-based workflow that is designed to support continuous delivery and deployment, and is used by GitHub, a web-based Git repository hosting service. This workflow emphasizes feature branches and pull requests, and is ideal for small, fast-moving teams. For more information, see: https://guides.github.com/introduction/flow/
• OneFlow: OneFlow is a branching model and workflow that is designed to simplify the Git workflow by using a single branch, and is used by companies such as Spotify and Walmart Labs. This workflow emphasizes continuous delivery and deployment and is suitable for teams of all sizes. For more information, see: https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow
• Trunk-Based Development (TBD): Trunk-Based Development is a workflow that emphasizes short-lived feature branches and continuous integration, and is used by companies such as Google and Amazon. This workflow is suitable for large, distributed teams, and is designed to minimize merge conflicts and reduce the risk of regressions. For more information, see: https://trunkbaseddevelopment.com/
• Forking Workflow: This workflow is often used in open-source projects, where contributors may not have write access to the main repository. Instead, contributors fork the main repository, make changes in their own fork, and then submit a pull request to the main repository when their changes are ready. This allows for easy collaboration and reviews while maintaining strict control over the main repository.

Conclusion

To sum up, Git Flow offers a well-structured branching strategy that streamlines the software development process for teams. With Git Flow, teams can effortlessly manage multiple versions of their codebase while maintaining top-notch code quality and stability. The hotfix branch stands out as a valuable tool that enables teams to quickly address critical issues in the production environment without disrupting their regular development flow. However, it's crucial to adhere to the proper hotfix branch procedures, including versioning and updating subsequent releases. By adopting Git Flow, teams can ensure efficient and effective software development, minimizing errors and conflicts and delivering high-quality software to their end-users.