Git in the flow with GitFlow
Brian Gorman 
2020-10-26 10:51 pm
Worst title ever? Probably. Reasonable to get your attention? Probably.
If you're reading this, it's likely that you are interested, at least a little bit, in GitFlow. As someone who has been training on Git for the past few years, and has been trying to find best practices to teach around Git, I thought this would be an opportune time to write up a quick spiel on GitFlow. It is especially good because I just did some training this morning where I got to pitch GitFlow. It's also something that was requested by a few students in some of my Git courses.
So, you've worked with Git but you aren't sure if you are using GitFlow, or why you should. To begin, maybe we should get on the same page as to some standards.
I'm going to operate from a mindset similar to what you would learn as you are studying for the AZ-400 exam:
- Ensure that your main branch is your production code
- Make sure your main branch can be deployed at any point and time
- Only allow code that has been reviewed and approved into main, via pull requests
- Use tags to track your versions
- Use a common branch off of main, like develop, as the trunk for your development team work.
- All developers use a feature branch approach, and changes for developers into the develop branch also require a pull request.
When it's all said and done, you protect your main branch, and you ensure that your development team has collaborated on their code to get it into the develop branch. You build your staging pipelines off of the develop branch, and your production pipelines off of the main branch.
With GitFlow in place, you now have the ability to track your versions, keep your developers from directly affecting your production code, and ensuring that your team is building a solid solution.
When issues arise, such as a bug in production, that's no problem. Just create a hotfix branch off of main, then patch the code. When it's working as expected, push the code to main, and then propagate those changes into develop, so your team gets the hotfix as quickly as possible, as does your production environment.
To illustrate, consider a system where the develop branch has moved ahead a couple of commits from main, and there are two developers working off of develop that have each started feature work.
Now assume that feature-1 is ready, so we use a pull request to merge feature-1 into develop, and after the merge, delete feature-1 since it's fully merged:
Now that we have this in place, it's time to deploy (sorry dev-2, you didn't make it this sprint!).
To do this, we perform a pull request to merge develop into main.
Now dev-2 needs to get into develop, but first they need to get based on the develop branch, so first they rebase to develop:
In the meantime, it was discovered that a bug happened in the last release, so we need to fix it asap. Open a "hotfix" branch off of master and make the changes!
The hotfix has solved the problem! Now let's get it into production via an approved pull request:
Awesome! Everyone is happy, but we need to get our develop branch up to speed as well, so let's get the latest master into develop using a merge to avoid any potential history issues.
Now feature-2 has waited long enough, but it must also get updated with the hotfix by rebasing off of the develop branch once again:
And with all the changes ready and approved a pull request merges feature-2 into development:
Awesome, now all it takes is the final pull request for develop into master to get the new features in place:
And now your team can continue developing and all of your CI/CD processes can play nice with the structure of this version of GitFlow!
Happy Coding to you!