在Github上,将PR合并到其他分支 [英] On Github, merging PR into different branch

查看:971
本文介绍了在Github上,将PR合并到其他分支的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

说有人向Github上的public/master提交了PR.

Say someone submits a PR to public/master on Github.

有没有办法将该PR合并到另一个分支中?否则,看起来我必须合并到public/master中,然后将其向后合并到development/staging分支中.就像让人们先进行修补程序然后将修补程序合并到开发分支中一样,我们通常应该避免这种情况,对吗?

Is there a way to merge that PR into a different branch? Otherwise, looks like I have to merge into public/master, then merge that backwards into a development/staging branch. It's like having people do a hotfix and then merging the hotfix into a development branch, which is something we normally should want to avoid right?

让人们跟踪PR并将其提交到暂存/开发分支而不是母版似乎更有意义.

Seems to make more sense to have people track and submit PRs to a staging/development branch instead of master.

做到这一点的最佳方法是什么?棘手的是,当前的暂存/开发分支是私有的.听起来我必须公开一个开发分支,然后引导人们从该分支分支并将PR提交给该分支?

What is the best way to do that? The tricky part is that currently the staging/development branches are private. Sounds like I have to make one development branch public, and then direct people to branch from and submit PRs to that branch?

推荐答案

根据定义,您无法将PR定位为您不知道存在的分支.

By definition, you can't target a PR for a branch that you don't know exists.

您的历史记录可能看起来像这样:

Your history might look something like this:

*--A--B--C [develop] (private)
    \
 ... D--*--*--E [master]
               \
                F--G--H--I [myfeature] (PR for this)

这里有两个问题. (1)myfeature的PR不能以develop为目标,因为develop是私有的,并且对myfeature的作者不可见. (2)develop分支具有一些提交(在本例中为BC),这些提交也是私有的.

There are two problems here. (1) The PR for myfeature can't target develop, because develop is private, and not visible to the author of myfeature. (2) The develop branch has some commits (in this case B and C) that are also private.

第二个问题是更重要的一个.如果提交B与提交G发生冲突,则无论您如何尝试将更改从myfeature更改为develop you 都必须是解决该冲突的人.这是不理想的.我发现,PR的作者而不是维护者更容易解决冲突.

The second problem is the more important one. If commit B conflicts with commit G, then no matter how you try to get the changes from myfeature into develop, you will have to be the one to resolve that conflict. This is not ideal; I have found that it is much easier for the author of the PR to have the responsibility of resolving conflicts, rather than the maintainer.

话虽这么说,但有两种解决方案:公开发行,或重新设定基础并合并.

With that said, there are two solutions: go public, or rebase and merge.

这是我推荐的解决方案,因为它将是最简单的长期解决方案.您可以将develop分支推送到GitHub并将其公开.这将允许其他用户从develop分支出来并向其发送PR.

This is the solution that I recommend, because it will be the easiest long-term solution. You can push your develop branch to GitHub and make it public. This would allow other users to branch off of develop and send PRs against it.

您提到develop分支中有某些专用文件.根据您需要这些文件的用途,您可以ignore将其保存,或从中提取敏感值以在运行时加载.最好永远不要在回购中的任何地方拥有私有文件,因为除其他原因外,您可能会意外地将develop公开.

You mentioned that you have certain private files in your develop branch. Depending on what you need those files for, you may be able to ignore them, or extract sensitive values out of them to be loaded at runtime. It is best to never have private files anywhere in your repo, because among other reasons, you may accidentally make develop public.

如果使用此解决方案,那么您已经非常接近使用 Git Flow 工作流程,我也建议.

If you use this solution, then you are already pretty close to using the Git Flow workflow, which I also recommend.

如果您绝对不能公开develop,则需要重新设置基础并合并.首先,做:

If you absolutely can't make develop public, then you need to rebase and merge. First, do:

git rebase --onto develop master myfeature

您的历史现在看起来像这样:

Your history will now look like this:

           F'--G'--H'--I' [myfeature]
          /
*--A--B--C [develop]
    \
 ... D--*--*--E [master]
               \
                F--G--H--I

然后您可以正常合并到develop中:

You can then merge into develop as normal:

git checkout develop
git merge --no-ff myfeature

给你

           F'--G'--H'--I' [myfeature]
          /             \
*--A--B--C---------------J [develop]
    \
 ... D--*--*--E [master]
               \
                F--G--H--I

该解决方案的另一个缺点是,就GitHub而言,PR还没有被合并,因此您必须手动关闭它.与此相关,提交PR的用户将无法看到它已被合并,除非您发布从developmaster的新更改.

The other downside of this solution is that as far as GitHub is concerned, the PR hasn't been merged yet, so you'll have to close it manually. Related to this, the user who submitted the PR won't be able to see that it has been merged until you release new changes from develop to master.

这篇关于在Github上,将PR合并到其他分支的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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