In this post, you will learn about some of the best practices in relation to managing your development and production releases using GitFlow Workflow.
- There will be a master branch which is called as an official repository.
- Forking a develop branch of the master: To start with, we will fork off another branch of the master which we may call as “develop”. This branch will act as an integration branch for features branches. NOTE: feature in features branches does not represent the features in machine learning. “Develop” branch will act as a parent to the feature branches. This means that developers would fork from “develop” branch and their changes are merged back into “develop” branch. In real-world scenarios, there will be multiple branches such as develop, QA, UAT etc.
- Fork one or more feature branches (user remote branches) off develop branch: For developing on a new feature, developers will fork off their feature branches of the “develop” branch. The following represents the workflow steps for working with feature branch code in the local workspace (developers’ desktop or laptop).
- Pull the remote feature branch into the local workspace.
- On a daily basis or regular intervals, fetch and merge changes from develop branch to the local feature branch.
- Push the changes to the remote feature branch at regular intervals.
- Merge feature branches into develop branch: Once the developers are done with the development work on the feature, the next step will be to merge the feature branch into “develop” branch. Features should never interact directly with the master.
Fig 1. Representing master, develop, feature branches (Image Courtesy: Atlassian.com Gitflow Workflow)
The following represents the workflow steps for merging the code changes from the feature branch to the develop branch.
- Once the changes are ready to be pushed to develop branch, create a merge request.
- Maintainer reviews the code and merges the changes into the develop branch.
- Fork off a release branch of develop branch: Once “develop” branch has acquired enough features for a release (or a predetermined release date is approaching), a “release” branch is forked off of the “develop” branch. The release branch could be used by QA team for testing purpose. On the release branch, only bug fixes, documentation etc could go. Forking off release branch makes it possible for one team to polish the current release while another team continues working on features for the next release.
- Merge release branch into master and develop: Once release branch is ready to ship, it gets merged into master and tagged with a version number. In addition, it should be merged back into the develop branch, which may have progressed since the release was initiated. in the following diagram, note the aspects related to forking the release branch from the develop branch and merging it back to the develop (as appropriate) and master branch.
Fig 2. Representing master, release, develop, feature branches (Image Courtesy: Atlassian.com Gitflow Workflow)
- Fork off hotfix branch of the master: If an issue in the master is detected, a hotfix branch is created from the master.
- Merge hotfix branch into master and develop: Once the hotfix is complete it is merged to both develop and master. The following diagram represents the aspects related to forking hotfix branch from the develop branch and merging it with develop and master branches respectively.
Fig 3. Representing master, develop, hotfix, release, feature branches (Image Courtesy: Atlassian.com Gitflow Workflow)
The diagram below represents the holy grail of Gitflow Workflow.
Fig 4. Gitflow Workflow Putting it all together (Image Courtesy: Atlassian.com Gitflow Workflow)
GitFlow Quiz – Test Your Understanding
The following questions could be used for testing your learning on GitFlow workflows. These could also be used as interview questions and answers.
[wp_quiz id=”7455″]
References
Summary
In this post, you learned about different Gitflow workflows which could be used for development, testing/QA, Hotfix, and production releases. Briefly speaking, one or more developers working on a functionality should fork a develop branch (integration branch) from which they could fork their user branch and work independently on their branches. At regular intervals, they should commit to their user/personal branches. The commits from user branches should be merged regularly to the develop branch. At the time of release, a release branch should be forked off of the develop branch. This could also be called as QA branch. At the time of release, this release branch should be merged with master and also develop branch (in case of bug fixes on release branch). Please feel free to suggest/comment.
Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking.
- Agentic Reasoning Design Patterns in AI: Examples - October 18, 2024
- LLMs for Adaptive Learning & Personalized Education - October 8, 2024
- Sparse Mixture of Experts (MoE) Models: Examples - October 6, 2024
I found it very helpful. However the differences are not too understandable for me