我们有PR，它工作正常，但PR有一个非常旧版本的原始分支，自PR分支创建以来，原始分支已经更新了很多。
那我怎样才能模拟＆＃34;实际合并到原始分支之前的合并和运行测试？
答案 0 :(得分：2)
您只需从开发分支执行以下操作即可复制分支指针：
git checkout -b test-branch
现在您在test-branch，这与您的开发分支相同。继续并合并（或者更好的是，rebase）到当前主分支：
git merge master
OR
git rebase master
您可能需要解决一些冲突。如果发生这种情况，Git将打印出如何执行此操作的明确说明。现在test-branch合并在master之上，从你的开发分支首次分歧开始。您的开发和主分支不受此操作的影响。
如果您对合并感到满意，可以使用test-branch删除git branch或将开发分支移动到合并点：
git branch -f development test-branch
请记住，如果您的原始主分支已更改，您应该在尝试合并或变基之前更新：
git fetch origin
git checkout master
git merge --ff-only origin/master
或者，如果您不介意从其他分支机构提取更改，您可以git pull。
答案 1 :(得分：0)
从master（或要测试的分支）创建分支
以这种方式合并您的拉取请求： Merge pull request to a different branch than default, in Github
测试你的东西
如果测试成功，请合并为master并删除测试分支
答案 2 :(得分：0)
Mad Physicist's answer是正确的（并且已经投票），但图表可能有所帮助。
理解这一点的关键是，对于Git中的大多数用途，分支名称几乎完全无关紧要。重要的是提交图（以及附加到该图中每个参与提交的快照）。
我们假设您有以下图表：
...--A--B--C <-- mainline
\
D--E--F <-- feature
并且您建议将git merge功能分支提交到主线分支。通常你会这样做：
git checkout mainline && git merge feature
这会指示Git使用提交B和C执行合并（＆＃34;合并＆＃34;作为动词）＆＃34;我们做了什么＆＃34;，以及提交B和F作为＆＃34;他们做了什么＆＃34;。如果一切顺利，Git会自动进行 new 提交，调整标签mainline以将指向新提交。如果事情进展不顺利，Git会强迫我们修复混乱（编辑工作树中的内容，并git add结果）并自己进行新的提交。这也会产生一个新提交，它还会调整标签mainline以指向新提交。在任何情况下，新提交都有两个父项：提交C和F（按此顺序）。换句话说，新提交是 a 合并（＆＃34;合并＆＃34;作为名词）。所以，让我们画一下：
...--A--B--C------G <-- mainline
\ /
D--E--F <-- feature
现在，请注意，此图表与此图表相同：
C
/ \
...--A--B \-----G <-- mainline
\ /
D--E--F <-- feature
但是想象一下，我们可以让Git 不在我们提交之后移动标签mainline，这样我们就可以得到这个图：
C <-- mainline
/ \
...--A--B \-----G <-- ??? (HEAD)
\ /
D--E--F <-- feature
除了单独留下分支名称mainline之外，效果完全相同：我们执行相同的合并动作工作并进行相同的合并 - 作为 - 一个名词提交对象G。
如果您创建一个新的分支名称（填写???部分），会发生这种情况。 ＆＃34;在新合并之前＃34;图片是：
C <-- mainline, test-branch (HEAD)
/
...--A--B
\
D--E--F <-- feature
并且合并后的图片是添加了合并提交G的图片。
Git根据HEAD了解要更新的分支名称。
请注意，您甚至可以使用Git＆＃34;分离的HEAD＆＃34;进行合并。模式。在此模式下，名称HEAD将直接指向提交ID，而不是让HEAD文件存储分支名称。 Git的其余部分照常工作，但是在进行新的提交时，而不是更新存储在HEAD中的分支名称 - 没有一个Git只更新HEAD本身。
一旦您确定合并是好的，您就可以让Git向＆＃34;滑动名称mainline向前＆＃34;在快进操作中：
C <-- (old mainline)
/ \
...--A--B \-----G <-- HEAD, (new mainline if slide-forward works)
\ /
D--E--F <-- feature
这＆＃34;向前滑动＆＃34;操作失败，如果它不可能只是向前滑动。例如，假设我们的工作是合并，解决冲突或我们必须做的任何事情，然后运行我们的测试，花了相当长的时间......在那段时间里，其他人偷偷摸摸并更新了mainline，添加了一些自己的新提交：
C---------H <-- mainline
/ \
...--A--B \-----G <-- HEAD
\ /
D--E--F <-- feature
它不再可能向前滑动＆＃34;到G：名称mainline首先必须＆＃34;向后滑动＆＃34;到C，失去H。快进操作将失败，让我们知道我们的临时合并G毕竟不能成为分支mainline的永久成员。
（我已将新提交H绘制为普通提交，但它是一个简单的提交还是合并提交并不重要：关键在于它在C之后，而不是在G之后。这些快进操作必须仅移动＆＃34;转发＆＃34; -right，在这些图形图中。）