Adopting GitFlow As My Branching Model
The Short Notes On Branches
A Simplified Work Flow
Your existing codebase has a master branch in production. Your develop branch is aligned and ready for new work.
You start a new feature or patch. You create a feature branch usually named feature/super-cool-new-thing. When you’ve completed the code and it looks stable you finish the feature. GitFlow will merge this with your local develop. No conflicts or other issues? Push it. The rest of your dev team has a new reference point for your upcoming release.
Start a release when you are done coming up with super cool new features. When you start a release GitFlow will create a new branch named release/<version>. If you’ve had prior release branches and tags GitFlow will see this and bump the next minor or point release. If not you’ll need to name your first release. Convention is to use the major.minor.point-release version format.
Put the release into production after testing. When you finish a release, GitFlow will merge this with master, tag the commit with the version of that release, and make sure the develop branch is updated with any code changes that may have happened during testing/production.
Seems simple, but I quickly found a corner case that did not seem to be addressed. What do you do when your release branch testing uncovers a bug?
My patch Branch
One of the complaints about GitFlow is what do you do when your code is ready for testing and find a bug. The branch model does not clearly define the methodology and in this vacuum a lot of people have shared their opinions and many have tried to fill that void. There were no methodologies that I came across that I really liked, so I created my own (which I’m sure someone else has done already).
After I start a new release branch I run through a series of tests. Sometimes the tests fail and I need to update the code. What do you do now? Start a new feature branch? It is not really a feature. It also makes it very hard to see what “feature” is needed to get the release into production versus a feature you (or some other developer) has started for a different future release. The bigger the team the more problematic this becomes.
In order to increase visibility for the team lead that is managing the repository I introduced the “patch” branch. Patch branches in my branch model are specifically for code changes to be rolled directly to the release (and back to develop) branches. It is the equivalent of a hotfix that goes on release instead of master.
While this is not a standard GitFlow model and thus I don’t have a one-button-click way to start and finish a patch release in SmartGit, the nomenclature “standard” keeps us all on the same page.
You must log in to post a comment.