Git: Merging only branch specific commits

Question

To give you a background the way I monitor Git repository and branches;

I have been monitoring two branches starting from each sprint - release and master. Master branch is from where developers create new branch(task specific), implement their changes, and creates pull request which gets merged into the Master . Release branch is sprint specific which remains always submittable to the production. We only merge branches committed to the Master and verified by the QA into Release branch. Makes sense? This approach works best when you want to submit release at fix regular interval with specific functionality implemented and verified, and hence you exactly know what's going in the next release.

It's going great until I run into following issue;

1. DeveloperA has created task specific branch say taskA from Master .
2. He has committed multiple times to taskA branch.
3. Mean while other developerB created his branch taskB from Master and committed multiple changes to the taskB and got taskB merged into Master .
4. DeveloperA will merge Master into taskA branch and further carry on his task!
5. Eventually he will get taskA branch merged into Master.

Now I just want to merge taskA branch to Release branch but as taskB was also merged into taskA branch, I get taskB branch changes automatically into Release branch! I don't want that. I know I can cherrypick all commits from taskA which becomes annoying.

Can someone please help me what's the best way to get only taskA branch changes to Release no matter if developer merged Master intermittently. Am I following wrong Git practice?

Answer 1

It seems to me that the developer of the taskA branch (let's call him developer A) should rebase his branch on the latest Release before creating a pull request (or merging it). Developer A should run this command prior to merging or creating a pull request:

git rebase -i origin/Release

This will give him an editor in which he can set what commits he wants to "pick"/use to be applied to his branch. If any commits from the taskB branch ended up in his branch, he can drop the commits of taskB if they are not ready for Release yet (just remove the lines containing those commits).

That way, all changes that have occurred in the Release branch in the meantime will be fetched and applied to his taskA branch. And then all commits that Developer A selected in the editor will be applied on top of that again. That way, the timeline is still correct and there should be no conflict whatsoever.