这是设置。我有一个主要的github存储库，我将其称为team/repo，也是它的一个分支，我称之为me/repo。在me/repo我在feature分支中进行了一些更改（还有一个master分支），并在develop中向team/repo分支创建了拉取请求。从develop中的team/repo分支（包括我刚刚提出的拉取请求）返回master上的me/repo分支的所有更改的正确方法是什么？< / p>
答案 0 :(得分：3)
实际上，没有“正确的方法”，不同的团队只采用不同的策略/流程。
听起来您可能正在遵循分支管理的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执行拉取请求。这很好，并且可以将您的更改发送到develop分支，作为一系列提交中的rebase，或者作为组合的单个提交。
从这里开始，这完全取决于您的团队的工作流程，了解该变更如何/何时变为master。如果开发遵循Gitflow，则不需要立即转到master。您应该将feature分支从develop分支出来，而不是master。在您的PR进入develop之后，只需将新的develop提交下拉到您的本地仓库中，然后推送到您的分支，然后创建一个新的feature分支develop 1}}或继续在现有的feature分支中工作，直到需要下一个PR。
最终，该小组会将develop次提交合并到master，其中一些也可能会在release个分支中合并。如果是这样，您可能需要分支master或release分支而不是develop，但新功能应该从develop分支出来，不是master（develop会合并到master）并从之拆分。
您的团队可能会以不同的方式处理此问题，但这应该让您了解其工作原理并让您提出正确的问题。重点是这里不一定存在问题，您的更改需要立即进入master。如果他们确实将其放入master，您仍会将其从upstream下拉，但您可能需要结帐本地master并将其合并到upstream/master以加快转发它，然后把它推到你的前叉。