你应该总是为你创建的每个合并请求创建新的分支。在你将它推送到github创建请求之前，你应该将你的分支重定向到最新的上游分支。
Github说你可以使用git merge，如果没有太大的变化，我更喜欢使用git rebase upstream/master，这将防止 * 合并提交 *。
有时候，变基操作无法继续，因为你所做的修改已经在上游分支中被修改了。例如，假设您有一个text.txt文件，如下所示：

Lorem ipsum

您创建了一个PR来将其更新为Lorem ipsum!，而上游分支已经将其更改为Hello World。如果您在创建请求之前进行了一次变基，以使代码保持最新，则会出现合并冲突。该文件使用 * 冲突标记 * 更新，您可以选择要使用的版本，甚至可以编辑它，在我们的示例中，我们在text.txt中得到了这个：

<<<<<<< YOUR_PR_BRANCH
Lorem Ipsum
=======
Hello World
>>>>>>> THE_UPSTREAM_BRANCH

之后，添加更新的文件git add并执行git rebase --continue。

好吧，如果你的repo是fubar，那么下面是恢复的步骤：

$ git remote update     # make sure origin and upstream are up to date
$ git checkout master
$ git branch my_changes   # just to make sure my stuff isn't lost
$ git reset --hard upstream/master
$ git status
# On branch master
# Your branch is behind 'origin/master' by 8 commits, and can be fast-forwarded.
#

忽略快进的废话，它不会帮助你，只是重置主。

$ git push origin +master   # now, fork matches upstream/master

现在，如何恢复以前的工作，使它的审查？

$ git diff --no-ext-diff --no-prefix master..my_changes > patchfile
$ patch -p0 < patchfile   # apply the patchfile to master
$ git diff     # to verify patch visually.
$ rm patchfile   # clean up
$ rake spec      # verify that it really works.
$ git add .
$ git status     # double triple verify
$ git commit .
$ git push origin master

太烂了我试着做rebase，但它一直说“没有变化”，并没有要求我签入任何东西？我很确定我不明白这里发生了什么，这就是为什么我张贴我的斗争，所以有人可以解释我如何避免这种混乱，并从A到B更优雅，现在它的充分记录。我愿意把这归咎于git缺乏经验，但我认为拉取更改应该是git中非常常见的事情-我一定错过了什么。

git pull --rebase为我工作，并保持历史干净。
如果使用多个远程和分支，则指定远程和分支可能是有益的，即。

git pull --rebase [REMOTE] [BRANCH]
git pull --rebase upstream master

upstream被定义为可以用git remote -v打印的git repo的远程