【问题标题】:What do I do when a pull request is cherry picked?当拉取请求被挑选时我该怎么办?
【发布时间】:2011-07-06 02:13:48
【问题描述】:

我在 GitHub 上创建了一个项目,推送了一些更改,并打开了一个拉取请求。维护者签署并在新提交中应用更改(而不是合并我的提交),因此提交图如下所示:

* 03a0687 (origin/master) frotz: Corrected MAN_PREFIX
| * 11d3e98 (HEAD, master, jleedev/master) frotz: Corrected MAN_PREFIX
|/  
* 9c3dd1a yajl: use direct patch from Github.

显然,我必须对我的本地分支进行变基或强制更新。然后我是否必须强制推送到我在 GitHub 上的分叉?我主要是因为强制更新不应该是自动的。当您的更改被维护者精心挑选时,这是标准的做法吗?

【问题讨论】:

  • 另外:我刚刚在StGIT tutorial 中读到:“作为惯例,您应该避免在远程项目的“主”分支中工作,并且仅将其用作参考,因为它反映了别人的工作。”有道理。

标签: git workflow github pull-request


【解决方案1】:

最简单的做法就是始终在主题分支上工作。这样,您的 forks 主分支总是看起来像上游,因此一旦上游包含您的更改,您总是做同样的事情,只需删除您的主题分支。

如果上游合并了您的更改,您的主分支和主题分支都包含相同的提交,您可以安全地删除主题分支。如果上游樱桃选择了您的提交,那么在验证对上游所做的更改之后,您可以删除主题分支。

这样做的另一个主要好处是您可以轻松地将主题分支重新定位到主分支。有时,如果没有手动解决冲突就无法在上游应用补丁,他们会要求您重新设置基准或合并并自己解决冲突,因为它是您的代码并且您对此了解更多。我还怀疑他们选择了您的提交,因为他们在您进行分叉之后已经提交并且不想只为少量提交引入合并提交。通过挑选樱桃,他们使他们的历史更加线性和清晰。如果你经常变基,对他们来说可能只是一个快进合并,他们不需要挑选。

至于你现在要做什么的问题,强制更新你的本地分支然后强制推回你的分支是你唯一真正的选择。

【讨论】:

  • 好吧,这个项目的策略似乎是总是挑选提交,可能是因为有多个维护者,并且还添加了 Signed-off-by 行。然而,主题分支功能在任何一种情况下都有意义。
猜你喜欢
  • 1970-01-01
  • 2014-04-24
  • 2012-09-28
  • 1970-01-01
  • 2019-12-27
  • 1970-01-01
  • 1970-01-01
  • 2023-03-23
  • 2015-04-15
相关资源
最近更新 更多