As we’ve seen in this blog, Git has its own inner workings regarding 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 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 by 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 with the Integration Branches, thus facilitating the management of collaborative contributions.
Then, we have the “release branches,” which are used as a sort of staging area before committing new changes to the “master.” These branches are generated once the development team determines that the completed work is potentially releasable and branches of 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 GitFlow allows them to incur further small changes and fixes after being created, thus, 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 of 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 GitFlow is that it’s meant to be a collaborative workflow, meaning that multiple people will work on the same project and make commits simultaneously.
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. Still, 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.
Conclusion
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 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 its workflow. There is even a collection of Git extensions (which you can find here: https://github.com/nvie/gitflow) available to make using GitFlow even easier. However, remember this: it’s always better to grow your workflow than restrain yourself with rules; 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.”
Sources:
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/
