将叉中的更改作为多个拉请求推送

san*_*one 3 git github pull-request

我们已经分叉了一个Github项目,并且正在对其进行更改。对于每个任务,我创建一个单独的分支,然后将其合并到masterin分支中。

所以现在我要master进行的工作比master原始回购协议提前20次。

该项目的规则是create pull request for each task

虽然,我知道该如何做,但是git我不确定该过程。

我不确定是如何为第二次提交中的任务1创建拉请求,然后为第五次提交中的任务2创建拉请求,等等。

我是否犯了一个错误,现在只能同时为多个修复程序创建提取请求?

我应该这样做吗?

  • 完成任务

  • 与师傅合并

  • 创建从fork母版到原始母版的拉取请求?

编辑

@OliverCharlesworth您所建议的是我过去的工作方式,但这带来了许多问题。由于我先修复了一些任务,然后为每个任务创建了PR,所以与主服务器产生了许多冲突(徒劳)。因此,每次创建PR时,都会收到一条消息,提示它无法自动合并,但是我必须先解决冲突。然后对于90%的PR,我不得不处理合并,仅在合并时就浪费了几个小时。

这就是我认为自己做错了的原因。

因此,当我切换到规则“修复1任务然后合并到主服务器”时,我避免了所有这些愚蠢的冲突,并将我们的任务保存下来。

既然您说“从分支机构进行PR”是正确的做法,那么如何避免愚蠢的冲突并避免在愚蠢的合并过程中浪费几个小时呢?

注意:当我说“傻”时,这意味着所有冲突都将解决为必须修复的同一段代码。当我遵循新规则时,这将永远不会发生。愚蠢的意思是“没有充分理由就浪费了很多时间”。

Vam*_*ire 5

只需将每个任务的分支推送到分支的存储库,然后打开这些分支的拉取请求。您可以创建任何分支引入请求X到任何一间分行Y,你不必创建一个pull请求mastermaster

  • 任务分支机构的PR是必经之路。如果将分支合并到`master`并从那里打开拉取请求,则将遇到与合并冲突相同的情况。在推送分支并打开PR之前,您应该从上游获取并在'upstream / master'之上重新建立功能分支,这样PR不会有冲突。 (3认同)