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.
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:
As highlighted, the solution revolves around branch management, creating the right set of branches to make the process work.
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.
The development branch serves as an integration branch for features. It is initially branched from master.
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
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-descriptionFeatures 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.
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
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
Git is a really powerful tool and this approach is really a discipline that requires adoption by each member of the team, rather than hard and fast rules.
More recently, on some pretty large code bases i have seen the master branch being employed solely with pull requests being created directly where rapid turnaround on bug fixes is employed with unit tests being constantly added to cater for any issues encountered along the way.
At the end of the day it is important to find the flow that works for you and keeps you and your team comfortable and productive. By considering different possibilities i hope you can better determine the best approach to suit your particular workflow.