Branching Strategy on Scrum Software Development
Scrum is an agile framework that is used to develop products through iterations called sprints. For each sprint, there is a sprint backlog, which is a portion of the product backlog that can be done in one sprint. The result of the sprint is a feature that has the potential to be released.
In this article, I want to share the branching strategy that I use in the project I am working on.
The branching strategy that I propose consists of:
- master
Used to store code for features released to production. - test
Used to store code for the test environment. - dev
Used to store code for the development environment. - sprint
Used to store code for a specific sprint.
The following is an overview of how to work using the branches that I have mentioned above.
When the sprint begins, create a new branch, sprint branch, that is taken from the last sprint. During the sprint, all code changes are pushed to that branch. And whenever the code wants to be tested in the development environment, we just need to create Pull Request to the dev branch.
At the end of the sprint, we do a sprint review and test the features that have been developed. Then we can push code to the test branch.
And when the feature is ready to be released to the public, then we can create a pull request to the master branch.
And then, what can we do if, by mistake, the code that has been released to the public has a bug?
We can replace the master branch with the latest stable sprint. Or we can also create a new branch from the most recent sprint that has already been pushed to the master branch, called hotfix, fix bugs there, and push code to the latest sprint, the dev branch if we want to test it in the development environment, then the test branch, and finally, the master branch.
