这是设置。我有一个主要的github存储库我会称之为team/repo，也是它的一个分支，我称之为me/repo。在me/repo我在feature分支做了一些变化（还有一个master分支），并在develop向team/repo分支创建拉动请求。什么是从develop的team/repo分支（包括我刚刚提出的拉动请求）的所有变化返回master上的me/repo分支的正确方法是什么？
实际上，没有“适当的方法”，不同的团队只采用不同的策略/流程。
听起来你可能正在遵循Gitflow分支管理模型。在Gitflow下，你有一个master分支，这是一个半不可触摸的提交，代表已发布代码的永久副本。您还有一个活跃的develop分支（可能不止一个），release分支和feature分支。
既然你有一个repo的分支，那也是在Github上（如果我理解你的话），那么你的PC上也会有一个本地回购。通常你会将me/repo设置为一个名为origin的遥控器，将原始的team/repo设置为一个名为upstream的遥控器。当你想要更新你的前叉时，你从upstream下拉，然后将这些更改推送到origin。如果这部分有任何问题，请参阅This Answer on "Syncing A Fork"。
您可能已经拥有了所有这些设置 - 但它并非100％清晰。如果没有这样设置，以下可能会偏离目标。
现在回答的核心 - 如何从本地/分叉到team/repo（或upstream，原始团队中央回购）进行更改。
首先，考虑是否需要fork。它可能是，但除非存在信任问题或者这是一个大型分布式（可能是多团队）项目或开源，否则可能不需要fork。如果可以，请考虑直接在team/repo中使用功能分支，并避免增加fork的复杂性。
假设需要fork，你可以使用feature分支，并在team/repo分支上对develop执行拉取请求。这很好，并且可以将您的更改作为一系列提交中的rebase或作为组合的单个提交进入开发分支。
从这里开始，它完全取决于您的团队的工作流程，了解变更如何/何时变为master。如果开发遵循Gitflow，则不需要立即转到master。你应该从feature分支你的develop分支，而不是master。在你的PR进入develop之后，然后将新的develop提交下拉到你的本地仓库，并推到你的前叉，并在feature上创建一个新的develop分支或继续在你现有的feature分支工作，直到下一个PR是需要。
最终，该团队将develop提交合并到master，并且可能其中一些将最终进入release分支。如果是这样，可能有一段时间你需要分支master或release分支而不是develop，但新功能应该分支develop，而不是master（develop将合并并从master拆分）。
您的团队可能会以不同的方式处理此问题，但这应该让您了解其工作原理并让您提出正确的问题。重点是这里不一定存在问题，你的变化需要立即进入master。如果他们确实将它放入master，你仍然可以从upstream将它们拉下来，尽管你可能需要检查当地的master并将其合并到upstream/master以快进它，然后将它推到你的前叉。