我在 GitHub 上 fork 了一个项目，推送了一些更改，并打开了一个拉取请求。维护者签署并在新提交中应用更改（而不是合并我的提交），因此提交图如下所示：
* 03a0687 (origin/master) frotz: Corrected MAN_PREFIX
| * 11d3e98 (HEAD, master, jleedev/master) frotz: Corrected MAN_PREFIX
|/
* 9c3dd1a yajl: use direct patch from Github.
显然，我必须重新设置或强制更新我的本地分支。然后我是否必须强制推送到我在 GitHub 上的分叉？我主要是因为强制更新不应该是自动的。当您的更改被维护者精心挑选时，这是标准的做法吗？
最简单的事情就是总是在主题分支上工作。这样，您的 forks 主分支总是看起来像上游，因此一旦上游包含您的更改，您总是做同样的事情，只需删除您的主题分支。
如果上游合并了您的更改，您的主分支和主题分支都包含相同的提交，您可以安全地删除主题分支。如果上游樱桃选择了您的提交，那么在验证对上游所做的更改之后，您可以删除主题分支。
这样做的另一个主要好处是您可以轻松地将您的主题分支重新定位为 master。有时，如果没有手动解决冲突就无法在上游应用补丁，他们会要求您重新设置基准或合并并自己解决冲突，因为它是您的代码并且您对此了解更多。我还怀疑他们选择了您的提交，因为他们在您进行分叉之后已经提交并且不想只为少量提交引入合并提交。通过挑选樱桃，他们使他们的历史更加线性和清晰。如果你经常变基，对他们来说可能只是一个快进合并，他们不需要挑选。
至于您现在要做什么的问题，强制更新您的本地分支然后强制推回您的分叉是您唯一真正的选择。