Photo by Yancy Min on Unsplash
Howdy DEV clan?
We've all heard of the recommendation and best practice: "Use a version control for your project." While this is true, it might save you from F*CK-ups, not many blogs proclaiming the use of version control mention how to use it or the best way to use it.
Here comes Git-flow. Git-flow is a git workflow you can use to streamline your use of version control for your whole application. In today's post, I'll go over the basics of Git-flow and how it can improve your git-flow.
What is git-flow?
Git-flow is a git workflow proposed in 2010 by this post. This workflow is supposed to help you with your software development and DevOps practices. Git-flow defines a branching strategy and releases management for your software.
Git-flow uses git as its base (it's in the name!). Git was proposed for its distributed nature and "ease of use". Git allows for a simpler branching and merging mechanism compared to some other version control systems. More on git here.
Git-flow branches
When you create a project and initiate git in it, you have by default your main branch (go on, try it don't be shy). In git-flow, this main branch HEAD (latest changes committed) should always contain the production-ready software.
You might be asking: If the main branch is for production-ready code, in which branch should I develop the application then? You guessed it! Your main development branch is called develop. The develop branch should always contain the latest changes that are ready for release (ready to be sent to production).
To make sure that your develop branch only has the code that is ready to be sent to production, you need to separate your development into phases that work towards release. And guess what, git-flow has a solution for that.
Git-flow consist of three types of branches:
- Feature branches
- Release branches
- Hotfix branches
On a technical level, each branch is the same as the other. But for usage distinction, each type of branch has its specific use and is bound to strict rules for their originated branch (which branch they can be branched off) and their merging targets (which branch they are allowed to branch into).
Feature branches
Feature branches are used to develop well, features. Do you want to develop the login feature of your software? You do that in the feature branch. You use feature branches to develop the features you want to add to your software, for a new release or a distant one (maybe you just want to set the base to develop and publish later).
The feature branch should always branch off from the develop branch. Why? So that you have the latest version of your to work with. Likewise, the feature branch should always be merged into the develop branch, this will make the feature ready to be released.
Release branches
Release branches, well they are there to do final tinkering on a release before it goes to production. In these branches, you make minor fixes and final tinkering. Why do you use a release branch if your develop branch has the latest code?
Glad you asked (even if you didn't), this is to separate the release from the concurrent development. Let's say you finished three features at the same time (thus merged them into the develop branch), but you want to release only one. You create a release branch for that specific feature, do the final tinkering, and merge that to the main branch. Easy peasy lemon squeezy, you separated the release of the feature while keeping your develop branch available to changes from new features.
Since you are working with code that is ready for release, you can only make a release branch by branching from develop. When you are done with the branch, you must merge it into the main branch and release the code and into the develop branch (so that your develop branch has the latest changes).
Hotfix branches
Finally, we have hotfix branches. They have the same functionality as release branches, prepare your code for production, but they are used specifically for unplanned changes/ improvements.
Imagine you tested your software against the major ways your software can break, and it passes them all and you released the new feature. Just a day or two after the release, your users start complaining that they get X instead of Y when they click on a button.
To fix that bug, you don't need to create a feature branch, then merge it into develop and create a release branch. No! you create a hotfix branch from your main branch and fix that bug, hence hotfix. After fixing the bug in your code, you must merge the changes into the develop branch and the main branch for production.
So, there you have it. Git-flow is a very strict workflow for version controlling your project, and to some, it might look over-engineered and daunting. I recommend to not follow it to the letter, pick bits and pieces, and Frankenstein your way to a development structure that you and your team can easily work with and integrate into your projects.
I hope that you learned something from this post. Go on and structure your side projects!🤟
Latest comments (9)
Gitflow is great for when you need centralized control of mainline branch, which is "gatekeeped" (either by specific individuals or by a particular process - eg, 2 approvals required). This is great for open source projects.
In fast-moving autonomous teams, you want to remove as many bottlenecks and barriers to getting code into staging and production (assuming your team has skilled, competent and high-ownership individuals). Hence a better alternative in these situations is trunk-based development.
Thanks for your contribution to this post!
What does trunk-based development do differently from git-flow that makes it a better alternative?
There's only one branch that you commit to. There's no notion of a
develop,stagingandmasterbranch.I've had experiences using gitflow with teams of 10+ engineers where there are enormous merge conflicts due to inconsistencies between those
develop,stagingandmasterbranches - the most obvious being when a patch lands inmasterbut the developer forgets to add that patch back intostaginganddevelop. Gitflow is too complicated to do correctly with so many people.With trunk-based development you also let your developers merge to mainline when they're ready. There's no code review required (pair programming is a better alternative IMO) but a dev can certainly request a review if they need it. This leads to low friction to getting code into production. And leads to a design that allows for multiple production deployments per day with little effort on any particular person.
Thanks for the elaboration!
I've seen these conflicts before too. As a junior I thought it was just human error and it's not something that would hinder the development in the long run. Guess I was wrong.
Trunk-based sound great for big teams, I'll have to look into it and see if and how I can propose it to the team when I'm more familiar with it.
we have been using gitflow in my small team for the past 5 years and our experience has been incredibly positive. Gitlab flow is also great
Good to read that!✌ Do you have any advice on how other teams can also make it work out?
I heard about Gitlab flow, will need to check it out sometime.
The first step is to understand what problem gitflow is trying to solve and if gitflow can actually help.
In our case it happens very often that two or three people work on the same project.
Creating a branch for each feature allows us to create a situation where conflicts are rare and when they arise they are manageable.
Using github gitlab is very convenient because it allows you to "automate" the creation of branches and their closing (merging).
I personally also prefer to squashing branches in order to get a commit per feature.
Great! Thank you for this comment!
I'll have to look into that too.
Thank you for reading!✌