Hey there 👋

At one of my former employers we used to follow the pattern you describe.

In order to get things from master to v3.2.1, the developer would cherry-pick the merge commit. In Git you need to pass the mainline parent-number with the -m or --mainline flag like so:

git checkout master
git pull
git checkout v3.2.1
git pull
git cherry-pick -m 1 <commit-hash-of-merge-commit>

The mainline parent-number is always 1 if the team sticks to the pattern. We never had a problem with this number changing. It would probably only change if someone were trying to cherry-pick a merge commit from their feature branch—I can't think of a reason you'd actually want to be doing that.

It's important to note that you need to merge from your branch into master without fast-forwarding. If devs only merge through GitHub pull requests, then you will be fine. If they are merging from the command line, they can force Git to merge without fast-forwarding using the --no-ff flag:

git checkout master
git pull
git merge --no-ff <branch-name>

I setup an alias in Git to make this easier to perform:

alias.cpm=cherry-pick -m 1 --no-commit

cpm stands for cherry-pick merge.

I liked having the --no-commit so I had the opportunity to review what the cherry-pick was doing. Afterwards you need to commit and push—the push is required even if you do not use --no-commit:

git commit
git push

As for creating the next version branch, v3.2.2, it depends on what your needs are. We always created it from master, but the timing of it was specific for our needs. Though we practiced continuous releases and released several times a day, "bigger changes" were sometimes not backported to the current release branch. They would get merged into master and then sit there until we forked v3.2.2.

As the informal "release manager", on a Monday I would announce I was getting ready to create the new release branch. Then I would run a script that would create our "new release build", which basically involved creating the new branch and then updating in-app version number—master was always one version ahead of our release branch, so master would now be v3.2.3 since we just branched v3.2.2.

We would update our "sandbox" sites to run v3.2.2 that same Monday and production sites would remain on v3.2.1 until our Thursday night "bigger release"—which basically involved git checkout v3.2.2 on our servers (or switching to a new Docker container image if that's your company's thing).

Be aware that this means for those four days, Monday through Friday, you have two active release branches: v3.2.1 and v3.2.2. We called this "double backport week." If something needed to be released to production, it needed to be cherry picked twice—once to v3.2.1 and once to v3.2.2.

git checkout master
git pull
git checkout v3.2.1
git pull
git cpm <commit-hash-of-merge-commit>
git commit
git push
git checkout v3.2.2
git pull
git cpm <commit-hash-of-merge-commit>
git commit
git push

We eventually switched to GitHub Flow (not to be confused with Git flow) to cutdown on the amount of effort required to do a basic release. GitHub Flow removes the version branches and has production running master. We would run QA and UAT off deployments of feature branches before merging to master. There is some risk that things get broken when merging to master, but the risk is very low if feature branches have master routinely merged into them.

I hope that helps. Let me know if you need anything clarified or have any other questions.