Senior disclaimer: the flow below may seem pretty obvious for experienced developers. However, usually it’s hard to explain something without putting it down to any sign form. So, please either skip the following or share the link with your juniors. You’ve been warned.
Couple of general notes:
You don’t need the dev branch if you can easily deploy a test instance for any (feature-)branch.
You need release branches if you aren’t confident in your monitoring and cannot easily revert a bad prod deploy.
Please, note that the flow of code review (CR) in general is covered elsewhere.
As an author start a feature branch from the current
masterbranch. In our example for a task CV-000 let it be
000-some-featureforked from the
master. We can’t start from
devconsidering it can include some out-of-release scope.
Develop the feature and test it locally.
When creating a merge request (MR) from a feature branch (
remove the checkbox “Delete source branch when merge request is accepted.”,
set the milestone.
If you created the MR during development, mark it as draft. Remove the mark at this point of the process.
If there’re any conflicts in the MR to dev:
First, from the feature branch (
000-some-feature) create a conflict resolving branch, e.g.
000-dev-conflicts. The name doesn’t really matter, but must contain the task number.
Merge the freshest dev branch (after pull) to the conflict resolving branch (
000-dev-conflicts). Resolve conflicts. Push.
Create another MR to
devwith the source branch set to the conflict resolving branch (
Set the checkbox “Delete source branch when merge request is accepted.” for this conflict MR.
After successful CR merge into
dev. When pipelines succeeded:
Move the respective task to a QA assignee.
Create another MR from the feature branch (
000-some-feature) to the
masterbranch or edit original MR to
devin case of dev conflicts by changing its target branch. In the MR:
set the checkbox “Delete source branch when merge request is accepted.”,
assign to the team lead,
start the name from sprint’s ID and task number, e.g 21.10.a CV-000 …,
set the milestone.
If the task doesn’t pass the QA fix it in the feature branch and create another MR to
dev, as usual (see pp.3-4). No action required for the master MR. It’ll be automatically updated since the feature branch is the same.
When the task successfully passes the QA the team lead merges it to the
masterbranch. If the QA process isn’t finished in the current sprint the author changes the milestone and title in the master MR to the next sprint.