【问题标题】:Github - need help on giving pull requestGithub - 在提供拉取请求时需要帮助
【发布时间】:2013-07-01 00:37:08
【问题描述】:

我分叉了一个项目,进行了更改(C1)并提出了仍处于待处理状态的拉取请求。一周后,我想提出另一个带有更改的拉取请求(C2)。

同时,上游(我从中分叉的地方)发生了很多变化。所以我想将我的 master 与上游同步,并且需要单独提供带有更改 C2 的拉取请求(无需添加更改 c1,因为我已经为此提供了单独的拉取请求)。

注意:我没有任何分支机构。我在我的主人中提交了 C1 并给了 拉取请求。是否更改了 C2。但这一次,我不知道在哪里提交 C2 以及如何给拉 请求而不添加 C1。

【问题讨论】:

  • 我在my answer below 中添加的详细步骤是否帮助您在不包括C1 的情况下对C2 提出拉取请求?
  • 我还没试过。但是你解释的方式是有道理的。我认为你在这方面有丰富的经验。 :)

标签: github


【解决方案1】:

如果你在自己的分支里做过C2,你需要做的就是:

  • 用 upstream/master 更新你的 master
  • 将 C2 分支重新定位到上游/主控之上
  • 从 C2 分支发出拉取请求。

请注意,如果您在 upstream/master 之上 rebase C1 分支,您现有的拉取请求将自动更新!

另见“How to do a Github pull request?”。


OP user10 加上in the comments

我在我的主人中提交了C1 并提出了拉取请求。
我做了更改 C2,但不知道在哪里提交以及如何在不添加 C1 的情况下发出拉取请求。
这是我的问题。

所以你有:

y--y--y--y  (origin/master)
\
 x--C1--C2  (master)

首先,不要在origin/master 之上进行任何变基,这会触发对现有拉取请求的更新(但这次,使用来自变基masterC1C2,因为我在我的pull request tips中提到,在第二点)

确保C2 is in own branch:

git checkout master
git branch bC2
git reset --hard master C2~
git tag C2base master

如果C2 由多个连续提交组成,请将C2~ 替换为C2 系列的第一个提交,然后是“~”。
这假设 C2 提交遵循 C1 提交。

确保您没有任何正在进行的工作(未提交):“reset --hard”会删除这些。

请注意,标签C2base 引用了C2 之前的提交。我们将在下面需要它。

y--y--y--y   (origin/master)
\
 x--C1       (master)
    ^ \
    |  --C2  (bC2)
 (C2base)

然后git pull --rebase origin 将在origin/master 上重播您的主人。

y--y--y--y          (origin/master)
\         \
 |         x'--C1'  (master)
 |
 x--C1    
    ^ \
    |  --C2  (bC2)
 (C2base)

注意C1 是如何在此处重复的,并且仍然通过bC2 分支进行引用。

最后,确保您的bC2 分支在origin/master 之上完成:

git rebase --onto origin/master C2~ bC2
git tag -d baseC2

这给了你:

           C2'      (bC2)
          /
y--y--y--y          (origin/master)
          \
           x'--C1'  (master)

(旧的C1commit 不再被任何东西引用,所以在reflog 中消失了,可用于revert improper rebase, for instance

您现在可以从 bC2 分支发出拉取请求,该分支仅包含 C2 提交!

【讨论】:

  • 我没有分支机构。我在我的主人中提交了 C1 并提出了拉取请求。我确实更改了 C2,但不知道在哪里提交以及如何在不添加 C1 的情况下发出拉取请求。这是我的问题。
  • @user10 当然可以。我已经编辑了答案以包含您的案例所需的详细命令序列。
  • 您使用什么工具来生成这些图表?
  • @ChrisHeald err... 简单的手动 ascii 艺术 (en.wikipedia.org/wiki/ASCII_art) ;)
  • 抱歉,不,图表在顶部。或者这只是你已经很方便的东西?
【解决方案2】:

在每次 PR 之前,您都应该了解 master 分支的最新情况。这意味着 PR 的顺序对您来说并不重要。最后 master 分支(和可能的新分支)将包含所有更改。

【讨论】:

    猜你喜欢
    • 2011-09-12
    • 2020-04-16
    • 1970-01-01
    • 2020-11-16
    • 2011-05-05
    • 2019-09-20
    • 2023-03-27
    • 1970-01-01
    • 2012-08-06
    相关资源
    最近更新 更多