Git:仅合并分支特定的提交 [英] Git: Merging only branch specific commits

查看:202
本文介绍了Git:仅合并分支特定的提交的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为了给您一个我监视 Git 存储库和分支机构的背景知识;



我一直在监视两个从每个冲刺开始的分支-版本和母版。 Master 分支是开发人员在其中创建新分支(特定于任务),实施更改并创建合并到 Master Release 分支是特定于Sprint的,始终始终可提交给生产。我们仅将提交给Master并由质量检查机构验证的分支合并到Release分支中。说得通?当您要定期提交修订版本并实施并验证特定功能时,这种方法最有效,因此您完全知道下一版本的情况。



很好,直到遇到以下问题;


  1. DeveloperA已创建任务特定的分支,说 taskA 来自 Master

  2. 他已多次提交 taskA 分支。

  3. 意味着,其他开发者B从Master创建了他的分支 taskB ,并对taskB进行了多次更改,并将taskB合并为 Master

  4. DeveloperA将Master合并到 taskA 分支中,并进一步执行任务! / li>
  5. 最终他将把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;

  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?

解决方案

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆