问题
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;
- DeveloperA has created task specific branch say
taskA
fromMaster
. - He has committed multiple times to
taskA
branch. - Mean while other developerB created his branch
taskB
from Master and committed multiple changes to the taskB and got taskB merged intoMaster
. - DeveloperA will merge Master into
taskA
branch and further carry on his task! - 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?
回答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.
来源:https://stackoverflow.com/questions/28742412/git-merging-only-branch-specific-commits