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:
At Assemblysoft we specialise in Custom Software Development tailored to your requirements. We have experience creating Booking solutions, as we did for HappyCamperVan Hire. You can read more here.
We can onboard and add value to your business rapidly. We are an experienced Full-stack development team able to provide specific technical expertise or manage your project requirements end to end. We specialise in the Microsoft cloud and .NET Solutions and Services. Our developers are Microsoft Certified. We have real-world experience developing .NET applications and Azure Services for a large array of business domains. If you would like some assistance with Azure | Azure DevOps Services | Blazor Development or in need of custom software development, from an experienced development team in the United Kingdom, then please get in touch, we would love to add immediate value to your business.
Assemblysoft - Your Safe Pair of Hands
https://assemblysoft.com/
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
A 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
A 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
A 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
