好的,我在github上为一个项目做贡献.在GitHub上项目upstream
,在github我的分叉回购是origin
的,我local
在我的电脑上回购.
git checkout -b feature # Working on feature git commit -a -m 'only commit on feature'
然后我提交拉取请求
git push origin master
审查拉取请求并且需要进行不相关的更改.其他人进行提交并合并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"
我不明白.当upstream/master
我推送拉动请求后,当我知道有人提交并合并时,这怎么可能origin/feature
?
谁能告诉我在这种情况下应该采取什么样的正确程序?
您只显示上游仓库的提取.这实际上并没有更新任何本地分支机构.它只会更新你的知识upstream
.您需要确保upstream/master
完全合并到您的内容中master
,例如git pull
,在重新定位之前master
,或者更简单地只是重新绑定到upstream/master
.
即:
git checkout master git pull upstream master git checkout feature git rebase master
要么
git checkout feature git rebase upstream/master
更新:
修复本地feature
分支后,您需要将其推回origin
以完成更新请求.既然你已经推了feature
一次,你就不push
能再简单了,因为一个篮板改变了历史,而且不久就是一个快进.通常情况下,如果推动失败并且"非快进",你可以通过拉动来解决它,但拉动只会结合两个不同的历史,这绝对不是你想要的.这意味着你的旧(pre rebase)feature
分支将与新的(post rebase)分支组合.您希望使用新分支的状态覆盖 ,转储旧分支的任何记录.这意味着你要强迫推动发生,即使它不是快进,使用.注意:origin/feature
feature
git push -f origin feature
危险,你可以失去它的承诺.只有在你完全确定自己知道自己在做什么的时候才使用它,就像在这里一样,你故意想要在pre-rebase feature
分支中删除旧的,无用的提交.
现在我被上游维护者要求"在主人之上修改我的拉取请求"
请注意,自2016年9月起,维护者可以自己触发rebase.
请参阅"重新启动和合并拉取请求 "
当您选择新的"Rebase and merge"选项时,来自pull请求的分支的提交将重新定位到基本分支的顶端,然后基本分支本身将快速转发到此新重定位的头部.Rebases会自动将rebased提交的提交者设置为当前用户,同时保持作者身份信息的完整性.此操作不会修改pull请求的分支.
如果由于冲突而无法执行rebase,我们会通知您,以便您可以根据需要手动解决它们.