Finally! The GitFlow
As we’ve seen in this blog, Git has its own inner works as to how it tracks our files, however, this is transparent to the user most of the time, and thus enables us to use Git more as a toolbox, rather than a framework.
This means that we are free to follow our own workflow while using Git and here is where the GitFlow comes into play.
The GitFlow really is a combination of multiple branch models, each with its own characteristics that allow us to track, not only the files of our project but also versioning and bug fixing. It was first introduced by Vincent Driessen in 2010 and has become very popular since then. You are certainly welcome to view the original post yourself following this link: https://nvie.com/posts/a-successful-git-branching-model/.
The GitFlow model consists of two types of branches: Unstable Branches and Stable Branches.
The Unstable Branches are used mainly for development and consist of two subgroups: Integration and Feature branches. An example of the Integration kind would be one called “develop” where everyone who is involved in the project can push their commits as they develop new features in separate Feature Branches, which are usually direct clones from “develop”, except for any changes the developer might add to the Feature branches he is working on.
The Stable ones consist of a special Integration branch called “master” and Release Branches, which are used to track all Releases before they are integrated into “master”. Additionally, there is another branch called “hotfixes” which, as the name implies, is used to make fixes.
The process is as follows: once you have a new remote repository, by convention “master”, it will be used for the versioning of the project, which means that only when a new version of the final product is ready to be deployed a new commit will be made on “master” and will not change until there is a new deploy.
The next important branch is “develop”, which, as we said, is an Integration Branch. What this means is that this branch will integrate all of the Features Branches made by other developers into a single development branch. A great advantage of using Feature Branches is that it allows other contributors to focus on specific features and avoid conflicts when new commits are pulled from the Repository. It’s also common to have designated “maintainers” to keep track of what branches are merged to the Integration Branches, thus facilitating the management of collaborative contributions.
Then, we have the “release branches”, which are used as sort of staging area before committing new changes to “master”. These branches are generated once the development team determines that the completed work is potentially releasable and branches off a new release branch from “develop”. Once the branch is created, it is assigned a version number according to the project’s versioning rules with the following naming convention: “release-[number]”.
An important advantage of “release branches” is that the GitFlow allows them to incur further small changes and fixes after being created, thus, for example, providing enough room for a QA team to run tests in a separate environment based on the current “release branch”. Once it's considered ready to deploy, it is merged into “master” and back to “develop” so as to include any fixes made for future releases.
Even with all the testing in the world, it can happen that we need to make a quick fix in one of our released versions, and by that time our “release branches” are already far ahead from our last commit in “master”. A good way to tackle this situation is with the use of a “hotfixes” branch whose sole purpose is to allow you to make quick updates/fixes to “master”, by creating a new branch from “master”, making the fixes and - very important to remember this - merge the hotfix branch to “master” and “develop” so that when continuing with our next release, our new “release branches” contain the fix.
Merge, Never Rebase.
One important aspect to remember about the GitFlow is that it’s meant to be a collaborative workflow, which means that multiple people will be working on the same project and making commits at the same time.
For this reason, it is important to always merge and never rebase. This is important since rebases change the history of the project. They allow us to visualize it more cleanly whenever we use a ‘git log’ command, but it can be misleading since the rebase essentially merges all the commits into a new branch of a singular line (as in sequential order), so there is no way of telling when and in what order a commit was merged into the branch. You can use this as a rule of thumb when working collaboratively.
In conclusion, Git is a very powerful set of tools, not a framework. It allows us to create our own workflow and decide how we want to work collaboratively. There are many workflows out there from which you can draw inspiration, like the GitFlow, but at the end of the day it all comes down to what works for you and your team. The GitFlow is a good starting point for any team that wishes to establish their workflow and there is even a collection of Git extensions (which you can find here: https://github.com/nvie/gitflow) available to make using the GitFlow even easier. However, always remember this: it’s always better to grow your own workflow than restrain yourself with rules and in the words of Dee Hock: "Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior."
Original Posting: https://nvie.com/posts/a-successful-git-branching-model/
Get GitFlow Extension: https://github.com/nvie/gitflow/
Another GitFlow Tutorial: https://jeffkreeftmeijer.com/git-flow/