Skip to main content

Simple Git branching strategy for release cycles

Coming up with a branching strategy that works well can be challenging when working with multiple developers and managing release cycles.
A simple approach is presented here to manage release cycles, with a small to medium sized team of developers while still being able to react to production issues and fix bugs. The primary goal being to isolate work streams without impacting development progress.

Background

Git does not enforce any particular strategy when it comes to branching which is partly what makes it such a great and flexible repository.
The problems start to arise though as you move into different stages of your development process. As an example, you have a release almost complete but don’t want to impede progress on the upcoming release cycle which is where the majority of effort is required.

The Basic Approach

The focus is around producing a release while still being able to react to hotfixes or production issues without impacting on going development of features.
 
The branches we can create to produce this workflow are shown below:

 
 
 

Branching Workflow

As highlighted, the solution revolves around branch management, creating the right set of branches to make the process work.

Master

The master branch is used purely for releases and is only merged into from a release branch. The master branch stores the official release history. Version tags should be added to the commits into the master branch.

Development

The development branch serves as an integration branch for features. It is initially branched from master. 

Release

Once enough features have been accumulated or a release deadline is approaching, the release branch is forked from the development branch. The release is now feature-frozen. Any features still in development are postponed for the next release cycle. The release version number is established and release related commits can continue to be added along with bug fixes and documentation. The next release cycle can now continue without impacting the current release. A meaningful name should be used which includes 'release' and a short description.
Example: release-your-release-title

Feature

feature branch is branched from the development branch. A meaningful name should be used which may include an issue identifier used from your work item tracking system i.e. JIRA and a basic description. 
Example: <Jira Identifier>-your-feature-short-description
Features are only merged into the development branch after a pull request has been signed off or a code review has been performed and signed off. 
Feature branches should never interact directly with master.

HotFix

hotfix branch is used to patch a production release. As soon as the fix is complete, it should be merged into development and master. A meaningful name should be used and a basic description.
Example: hotfix-your-hotfix-short-description
 
 

Checklist

The following can be used as a checklist before committing or merging
  • Features should never interact directly with master
  • Developers work locally and push branches to the central repository
  • development branch is used as the source branch for feature branches
  • Feature branches are used for all individual features being developed
  • Commits are performed daily into feature branches and pushed to the central repo
  • Features are only merged into development after a code / review has been completed
 

Conclusion

 
Git is a really powerful tool and this approach is really a discipline that requires adoption by each member of the team. This approach is only a guide and hopefully you can take something away and adapt it to suit your particular workflow.
 
Checkout some other musings via my blazor.net and azure blog here carlrandall.net
 
References
 

Popular posts from this blog

Instrumentation with Semantic Logging Application Block from Microsoft Enterprise Library 6

Introduction Instrumentation, the process of auditing and logging in your applications, is a vital part of any enterprise solution. When you are developing applications with Service Level Agreements and specific Auditing requirements, logging is a big deal. Add in the complexity of the decoupled nature of the cloud with Service Orientated Architecture, piecing together a clear view of a business process from end to end can be a challenge. Microsoft has recently released the Semantic Logging Application Block ( SLAB ) to the enterprise library. This article will form the first part of a mini-series, detailing the benefits, pitfalls and examples of how to make use of it in your enterprise. Although new to the Enterprise Library, Semantic logging is not a new concept. It has been adopted for years under different names such as "structured logging", "strongly typed logging" and "schematised logging" to name a few. What is it? SLAB inherits event

Azure Devops - Pull Request Merge Conflicts

Before a Git pull request can complete, any conflicts with the target branch must be resolved. Out of the box, at the time of writing this article, Azure DevOps requires this to be resolved locally. Following best practices to not allow direct commits to our release/master branches further exasperates the problem as we need to effectively clone the branch or go with a rebase approach, both of which break the natural flow of resolving the conflicts as part of the pull request. With this extension, from the Microsoft DevLabs team via the Marketplace, you can resolve these conflicts online, as part of the pull request process, instead of being forced to break flow and resolve locally. Online Experience After adding the extension the new conflicts tab is visible which enables conflict resolution in the familiar side by side review page as shown below: Really nice extension, which should make resolving merge conflicts a much more straightforward part of the DevOps

Windows Azure Storage Emulator failed to install

CodeProject Windows Azure Storage Emulator failed to install When attempting to install a new version of the Azure Storage Emulator either as a separate installation package or automatically as part of an Azure SDK update, you may run into an error message which states the storage emulator has failed to install. This can occur using the Web Platform Installer (WebPI), NuGet Package Manager or when performing the install manually. Below is the message received using the WebPI.   Storage Emulator Background  (optional reading) The windows azure storage emulator executable lives under the Microsoft SDKs directory as shown below: Configuration If we take a quick look inside the WAStorageEmulator.exe.config file we can see each of the storage services pointing to local service endpoints. <StorageEmulatorConfig>     <services>       <service name=" Blob " url="http://127.0.0.1:10000/"/>       <service