我从基础https://github.com/GoogleCloudPlatform/java-docs-samples分叉了一个存储库
对新分支进行了更新，并提交了pull request
审阅者/合作者建议并更改了文件。我选择了“解决对话”，可以看到changed files。
问题：
我如何将PR 2972上审阅者所做的更改带入我的本地分支“ ksurendra：helidon-mp-example-appengine-java11”？
我是否还需要将所有更改的文件放入本地存储库分支，进行验证，然后再次“推送”到PR 2972？还是审阅者已经拥有必要的更改文件？如果是这样，是否只是我需要更新我的仓库/分支以拥有更新的文件？
关于this page的详细信息不够清楚。
答案 0 :(得分：1)
我误解了最初的问题。
代码未更改：维护人员正在讨论并提出更改建议。
您需要在分支上进行代码更改，然后提交并推送，这将自动更新PR。
我最初完全误解了这个问题。有了标题，无论如何，我都会在下面留下这个答案。
如果我分叉了该存储库，然后将其克隆到本地，那么我接下来要做的就是
git remote add upstream git@github.com:GoogleCloudPlatform/java-docs-samples.git
这将创建另一个指向父存储库的remote。 upstream不是一个特殊名称，但它是一个约定，就像origin是fork的约定一样。
现在，将更改集成到原始存储库中后，我可以将它们快速拉入本地副本并将其推送到我的fork：
git pull -r upstream <optional branch name if different from current branch>
列出您的遥控器
git remote -v
因此，在您的情况下，您可以直接从上游拉入分支机构
git checkout ksurendra:helidon-mp-example-appengine-java11
git pull upstream master
或更新您的本地master并将其合并：
git checkout master
git pull upstream
git checkout ksurendra:helidon-mp-example-appengine-java11
git rebase master # Or git merge master
请记住，git是分布式版本控制系统。这正是“分布式”的含义：没有中央主干-从理论上讲，您可以直接推和拉到同事的工作站。只是出于心理上的简单性而没有这样做。
git真正以这种分布式方式真正使用的最常见情况是在维护fork时：多个（通常是完整的）存储库副本。