为github上的项目做贡献,如何"在主人之上重新调整我的拉取请求"

fon*_*tno 92 git github

好的,我在github上为一个项目做贡献.在GitHub上项目upstream,在github我的分叉回购是origin的,我local在我的电脑上回购.

git checkout -b feature
# Working on feature
git commit -a -m 'only commit on feature'
Run Code Online (Sandbox Code Playgroud)

然后我提交拉取请求

git push origin master
Run Code Online (Sandbox Code Playgroud)

审查拉取请求并且需要进行不相关的更改.其他人进行提交并合并upstream/master

现在我被upstream维护者要求"在主人之上重新提出我的拉动请求"

这是我的故事(插入法律和秩序音效).....

我没有对pull请求进行任何更改,它仍然在分支功能上进行相同的提交.

git checkout master
git fetch upstream
git checkout feature
git rebase master
=> "Current branch feature is up to date."
git push origin feature
=> "Everything up-to-date"
Run Code Online (Sandbox Code Playgroud)

我不明白.当upstream/master我推送拉动请求后,当我知道有人提交并合并时,这怎么可能origin/feature?

谁能告诉我在这种情况下应该采取什么样的正确程序?

Rya*_*art 102

您只显示上游仓库的提取.这实际上并没有更新任何本地分支机构.它只会更新你的知识upstream.您需要确保upstream/master完全合并到您的内容中master,例如git pull,在重新定位之前master,或者更简单地只是重新绑定到upstream/master.

即:

git checkout master
git pull upstream master
git checkout feature
git rebase master
Run Code Online (Sandbox Code Playgroud)

要么

git checkout feature
git rebase upstream/master
Run Code Online (Sandbox Code Playgroud)

更新:

修复本地feature分支后,您需要将其推回origin以完成更新请求.既然你已经推了feature一次,你就不push能再简单了,因为一个篮板改变了历史,而且不久就是一个快进.通常情况下,如果推动失败并且"非快进",你可以通过拉动来解决它,但拉动只会结合两个不同的历史,这绝对不是你想要的.这意味着你的旧(pre rebase)feature分支将与新的(post rebase)分支组合.您希望使用新分支的状态覆盖 ,转储旧分支的任何记录.这意味着你要强迫推动发生,即使它不是快进,使用.注意:origin/featurefeaturegit push -f origin feature危险,你可以失去它的承诺.只有在你完全确定自己知道自己在做什么的时候才使用它,就像在这里一样,你故意想要在pre-rebase feature分支中删除旧的,无用的提交.


Von*_*onC 7

现在我被上游维护者要求"在主人之上修改我的拉取请求"

请注意,自2016年9月起,维护者可以自己触发rebase.

请参阅"重新启动和合并拉取请求 "

当您选择新的"Rebase and merge"选项时,来自pull请求的分支的提交将重新定位到基本分支的顶端,然后基本分支本身将快速转发到此新重定位的头部.Rebases会自动将rebased提交的提交者设置为当前用户,同时保持作者身份信息的完整性.此操作不会修改pull请求的分支.

如果由于冲突而无法执行rebase,我们会通知您,以便您可以根据需要手动解决它们.

https://cloud.githubusercontent.com/assets/2195/18671961/a03fa9b6-7f35-11e6-8fa0-e16b2fede8ca.gif