Git:仅合并分支特定的提交 [英] Git: Merging only branch specific commits
问题描述
为了给您一个我监视 Git
存储库和分支机构的背景知识;
我一直在监视两个从每个冲刺开始的分支-版本和母版。 Master
分支是开发人员在其中创建新分支(特定于任务),实施更改并创建合并到 Master $的提取请求的地方。 c $ c>。
Release
分支是特定于Sprint的,始终始终可提交给生产。我们仅将提交给Master并由质量检查机构验证的分支合并到Release分支中。说得通?当您要定期提交修订版本并实施并验证特定功能时,这种方法最有效,因此您完全知道下一版本的情况。
很好,直到遇到以下问题;
- DeveloperA已创建任务特定的分支,说
taskA
来自Master
。 - 他已多次提交
taskA
分支。 - 意味着,其他开发者B从Master创建了他的分支
taskB
,并对taskB进行了多次更改,并将taskB合并为Master
。 - DeveloperA将Master合并到
taskA
分支中,并进一步执行任务! / li>
- 最终他将把taskA分支合并到Master中。
现在我只想合并 taskA
分支到Release分支,但是作为 taskB
也被合并到 taskA
分支,我得到taskB分支自动更改为Release分支!我不要我知道我可以从 taskA
中挑选所有提交,这很烦人。
有人可以帮我什么是最好的方法仅获得taskA分支会更改为Release,无论开发人员是否间歇性地合并了Master。我遵循错误的 Git
做法吗?
在我看来 taskA
分支的开发人员(我们称其为开发人员A)应该根据最新版本发布他的分支。开发人员A在合并或创建请求请求之前应运行以下命令:
git rebase -i origin / Release
这将给他一个编辑器,他可以在其中设置要拾取 /使用的提交内容。他的分支。如果 taskB
分支中的任何提交最终在其分支中,则他可以删除 taskB
的提交,如果没有
这样,在此期间,所有在Release分支中发生的更改都将被提取并应用于他的 taskA
分支。然后,将再次在编辑器上应用在编辑器中选择的开发人员A的所有提交。这样,时间轴仍然是正确的,并且不应存在任何冲突。
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?
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.
这篇关于Git:仅合并分支特定的提交的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!