如果我单击该选项，在基础分支和功能分支上究竟会发生什么？

*基础分支（dev）：什么都没有。
*您的功能分支：将被重新定位。

我也不能测试，因为我害怕把事情搞砸。
不用担心，GitHub UI中的两个选项都只修改你自己的特性分支，就像Git中的大多数东西一样，如果你搞砸了，通常很容易修复。你也可以在本地测试它们，当你完成测试后，你可以把你的本地分支吹走，用服务器版本替换它：

git fetch
git reset --hard @{u} # replace local branch with remote tracking branch

# Note that is the same as
git reset --hard origin/my-feature-branch

合并和变基选项之间有什么区别？

假设您在几天前从dev创建了一个名为feature的分支。在创造的那一刻，这两个分支是相同的。（即，它们都指向相同的提交ID）。现在，您希望创建一个PR来将feature合并到dev中，在过去的几天里，dev上还有20个提交不是“in”（也称为“reachable by”）feature。如果你决定用最新版本的dev来更新你的分支，以包含那20个缺失的提交，你有两个选择：
1.将dev * 合并到 * feature中。在命令行中，您可以自己执行此操作：

git fetch # get the latest version of origin/dev
git switch feature
git merge origin/dev
git push

这将通过添加一个新的合并提交到你的分支来修改你的分支，它将dev上的20个新提交合并到你的分支中。
1.将feature * 的基重置到 * dev上。在命令行中，您可以自己执行此操作：

git fetch # get the latest version of origin/dev
git rebase origin/dev feature
git push --force-with-lease

这将通过完全重写来修改你的分支，使它看起来像是你今天从当前版本的dev创建的，然后将你的每个提交添加到这个新分支的“顶部”。这将看起来“更干净”，并且在其历史中不会有新的合并提交。注意-提交的作者日期时间和用户名不会改变;只有提交者的日期时间和用户名会改变--他们会变成你，而且是现在。当查看一个重新定基的分支的历史记录时，通常会看到你的提交在顶部的日期比它下面的提交更早。
注意事项：
1.不管是合并还是变基，分支的结束状态都应该是相同的，但是图形历史会有所不同。
1.任何时候你重写你的分支（例如rebase或amend a commit），你必须强制推送它而不是常规推送。
1.无论你在本地进行合并/变基，还是让GitHub为你做，最终结果应该是相同的。
1.如果你对结果不满意，你总是可以在本地修复它，并强制将分支推回。
1.合并和变基都可能发生冲突，在某些情况下，您可能需要在本地而不是在GitHub UI中中止并解决它们。

这与您在本地运行git rebase origin/dev然后强制推送的操作相同。
确保首先运行git fetch以获得origin/dev的最新版本。

简而言之：
它将重写你的分支，并将dev分支提交放在你的feature提交之前。即使你的feature提交是在dev之前完成的。