A Git Strategy

Posted on | by Jason Snelders

Background

Over the years, I’ve worked on a number of different projects with different Git branching strategies. I’ve also wasted many hours sitting in meeting arguing over what should be a relative non-issue.

The beauty of being the bloke in charge is sometimes you get to skip all the bullshit and just dictate the approach.
Or to be correct in this case, sometimes the approach is dictated for you.

Working remotely with developers who were essentially new to Git and were already facing a lot of learning and change, I found their actions have driven my Git process decisions.
Which is good:

You want to make business and development processes as easy as possible for everyone.

After all, complexity is the enemy of productivity.

I started with GitFlow, which has worked well in the past, but ended up simplifying if further.

 

The Strategy

The Git “Pilot”

One person is designated responsible for reviewing and managing a repository.
All developers should be capable of doing this role – and the role may rotate between developers – but at any point in time one person is the designated “pilot” in control and responsible for the repository.

Workflow

Normal feature development

  • A working branch is created from develop.
  • When work is complete it is merged back into develop via a Pull Request.
  • A release is created.
    • A version number is generated an applied at the start of this process.
    • A new release branch named “release/release_{version}” is created from master.
    • develop is merged into the release branch.
  • The release goes through test environments.
    • Note: Only 1 feature release branch is tested at a time. This reduced management complexity.
    • If a fix is required:
      • A working branch is created from the release branch.
      • The working branch is PR merged back into the release branch.
    • If a production hotfix occurs during this process, develop is merged back into the release branch.
  • A release completes testing and is published to production.
    • Assuming any production hotfixes have already been merged into develop and the release branch.
    • The release branch is merged into master.
    • The release branch is merged into develop (to ensure any fixes are available for continued development).

Hotfixing production issues

  • A working branch is created from master.
  • When work is complete, a release branch is created from master (same versioning and naming process at normal feature development) and the feature branch is merged into the release branch.
  • The release goes through testing.
  • When testing is complete:
    • The release branch is merged back into master.
    • The release branch is merged into develop.
      develop then needs to be merged back into any working branches, and feature release branch currently in test.

Version Numbers

  • Use the format {yyyy}.{mm}.{dd}.{HHmm}
    • {yyyy}: The current 4-digit year at UTC.
    • {mm}: The current 2-digit month at UTC.
    • {dd}: The current 2-digit day at UTC.
    • {HHmm}: The current 24-hour hour and minute at UTC.
    • Example: 2018.02.22.2158
  • Version number is applied as soon as a release is generated.
  • I don’t care about identifying alpha’s, betas, fixes, or otherwise. A release is a release. Use release notes to document details of what is going into a release.

Core Branches

Required:

  • master: The current production code.
  • develop: The current code being developed and tested.
  • release: Each release starts in its own branch.

Optional:

  • feature: Optional node for developer to create working branches under.

Working Branches

Developers can optionally create working branches (known as “feature” branches in GitFlow) under a feature node (e.g. feature/jason_my_work), or directly off the root – at the same level as master, develop, and release.

This “either or” approach came about because my developers were forgetting to create working branches under feature.
In reality this is not a problem in any way and, if anything, made them easier to find and access, so I’m happy for them to stay there.
Good repository maintenance will handle any clutter issues.

Branch Maintenance

After merging working branches back into develop, keep the branch for a “period of time” – generally through testing – we’re happy all code is included and complete.
Periodically delete old working branches.

Release Notes

Each release should contain notes identifying:

  • The type of release – e.g. scheduled feature release, production hotfix, security patching, etc.
  • A summary of changes included in the release.
  • Identify any breaking changes.