Another Git Flow

Since the title of this article starts with the word ‘git’ my team’s source control solution is git.

I wanted to make a post about what we do on my team for a while. It’s been in response to this relatively recent post. With my team, we do not use “GitFlow”, however we do follow a flow and pattern.

Branch Arrangement

We have a CI/CD (Continuous Integration/Continous Deployment) arrangement. I can go more into that detail at another time. However, that pretty much sets the stage that we have a main line branch, in our case, master. All Feature and past Release branches are created off of master.

master contains all known history on the application’s life and branches. When we make a Sprint-End Release we will tag the release number on the commit.

Feature branches are traditionally short running branches that contain the new set of features to complete a work requirement or “story.”

Release branches are long running branches that are theoretically not temporary.

Feature Branches

While developing the developer can commit as many times as they would like and push up their changes to their remote (in our case origin). When the work is complete, a PR (Pull Request) is created and is up for review to be merged into master. After the review is complete the branch is Squash Merged. We do not need all of that developer commit history and it will clutter up the branch history. It makes traversing history very easy to find the culprit of an issue in the event there is one (such as using bisect). If necessary, create multiple Pull Requests to keep your commits small.

• rebase frequently off your target branch.
• refrain from using a merge as we prefer fast-forward merges, with the exception of the PR.

Release Branches

We have a GA (General Availability) release about 3-4 times a year. Before we increment the version number off the master branch we will create a Release branch. Any future “hotfixes” will run off this branch. In the event of a hotfix, the Release branch acts as a “master” branch. The Feature branch will be created off of Release and a PR will be made to the Release as a squash merge. When testing has vetted the changes and we are ready for a release we will merge back to master.

• merge Release into master and tag the HEAD commit on the Release branch.
  • Since the Release branch is a long-running branch this is ideally the only time a merge is necessary.
• DO NOT rebase the Release branch off of master if the latter branch has already been incremented.
• Ideally, DO NOT make a change in master first and then cherry-pick it to the Release branch. You will have conflicts in the event you ever need to merge back to master because you will then have a copy of a commit already in master which will be hard to track.

Long Running Feature Branches

There comes a time when you might want to have a longer running Feature Branch that you will want to have periodic review and custom builds on without the worry of it heading into master. In this case, you will treat this Feature Branch as a “master” and create sub-feature branches off this branch.

• PR the sub-feature branch into this branch.
• Periodically, you will rebase this branch off of master, but ideally only when there are no sub-feature branches present.
  • If there are sub-feature branches still uncommitted to this, extra care will need to reset said sub-feature branch and cherry-pick range the commits from which have been a WIP (work-in-progress). Essentially performing one’s own rebase since the typical way will not be possible (the source branch history changes).
• When the Long Running Feature Branch has run its course or is ready for an incremental inclusion to master perform a rebase of the Long Running Feature Branch and fast-forward merge back into master.
  • At this point you can either remove the Long Runnning Branch or continue more work.
• Long running Feature Branches requires very good communication with the team working on this branch.

Closing

That is really it. The process is relatively easy to handle and easy to read and follow through an entire application’s lifecycle. If your team does not have need for a Long Running Feature branch, do not feel to use that flow, but it can be handy for a sub-team to work on a feature that may cause many breaking changes throughout the application. Naturally, it will require your team to have some discipline on making some good choices when problems arise, but otherwise a tried and true method. We have been following this flow for about 3 years with very little hitch.