合并请求怎么合入：在保留提交、压缩和变基里选一种-育师

这篇讲合并拉取请求时，创建合并提交、压缩合并和变基合并有什么差别。看完你可以在设置 → 拉取请求里只打开团队约定的那一种，合并时看清main上会多出什么样的提交，并按方式删掉已经合入的本地分支。

下文用示例仓库 xlliu/test-pr-example。克隆地址是https://git.anguskit.com/xlliu/test-pr-example.git。这个仓库为了验收三种合入，把允许合并提交、允许压缩合并、允许变基合并都打开了，自动删除分支是关的。新仓库的默认是前两个打开、变基合并关闭、自动删除分支关闭。已经合进去的记录里，#2 在main上留下了合并提交Merge pull request #2 from feature/close-reopen。讲历史长什么样时，仍用一条有三个提交的源分支来画：提交 1、2、3 要合进已经有 A、B 的main。

1. 三种方式合进去之后，main 长什么样

方式	合并后`main`上多了什么	作者与适用场景
创建合并提交	分支上的三个提交原样进入`main`，外加一个合并提交（可快进时直接快进）	原提交保留原作者，合并提交由系统创建；适合保留完整分支脉络
压缩合并	只多一个新提交，内容等于三个提交加起来的总改动	作者是拉取请求作者，提交者是点合并的人；适合把零碎提交压成一条
变基合并	三个提交被逐个接到`main`最新提交后面，生成新的提交哈希	每个提交保留原作者和原说明；适合每个提交都规整、追求线性历史

还有一种情况要知道：选创建合并提交时，如果从拉出分支到合并这段时间里，main上没有任何新提交，AngusGit 会直接把main移到分支的最后一个提交，不再生成合并提交。结果和变基合并一样是一条直线。

2. 在仓库设置里决定允许哪几种

打开设置
进入仓库，切到设置，在左侧选拉取请求。这一操作需要仓库的管理权限。
选择允许的方式
三个开关分别是允许合并提交（「在合并 pull request 时添加所有提交」）、允许压缩合并（「将所有提交合并为一个提交」）和允许变基合并（「在基础分支上重新应用所有提交」）。新仓库默认打开前两个，关闭变基合并。团队约定只用一种时，只打开那一个，其他人合并时就不会选错。
决定合并后是否删除分支
同一页的自动删除分支（「Pull request 合并后自动删除分支」）默认关闭。打开后，拉取请求合并成功时，AngusGit 会删除这条源分支。
保存
点保存更改，提示拉取请求设置已保存。

至少保留一种方式是打开的。三个都关掉时，设置照样能保存，但之后所有拉取请求都没法合并。

3. 合并时选择方式

拉取请求满足合并条件后，在对话页点合并拉取请求。确认框的说明是「选择合并方式并确认合并操作」。

选方式
三个选项都会列出来：创建合并提交（「所有提交都会被添加到基础分支」）、压缩合并（「将所有提交压缩为一个提交」）、变基合并（「将提交变基到基础分支」）。仓库设置里没打开的方式是灰的，点不了。打开确认框时，默认选中按这个顺序排在最前、并且已允许的那一种。
检查提交信息
提交信息会根据方式自动填好，可以修改：
- 创建合并提交：第一行是Merge pull request #<编号> from <源分支>。xlliu/test-pr-example的 #2 合进去之后，main上的提交说明就是Merge pull request #2 from feature/close-reopen。
- 压缩合并：第一行是拉取请求的标题，下面是拉取请求的描述。这就是main上那一个新提交的说明，值得认真改一下，写清这次改了什么。
- 变基合并：输入框是灰的，提示「变基合并不会生成合并提交信息」，因为每个提交都沿用原来的说明。
确认
点确认合并。提示拉取请求已合并后，页面回到拉取请求列表，这一条的状态是已合并。

确认框要等合并拉取请求可以点了才出现。现在打开的 xlliu/test-cicd-example #1 两条流水线都已成功，按钮仍然是灰的，卡上写的是「仍有评审未完成，需等待评审通过后才能合并」。按钮可以点开之后，确认框标题下的说明是「选择合并方式并确认合并操作」，三个选项是创建合并提交、压缩合并、变基合并；仓库设置里没打开的那一项是灰的。

4. 合并之后，本地怎么收尾

先把本地的main更新到最新：

gitswitch maingitpull

然后删掉已经合并的本地分支。三种方式在这一步的表现不一样：

合入方式	删除命令	原因
创建合并提交	`git branch -d feature/close-reopen`	分支上的提交已经原样在`main`里，可直接安全删除。`#2`就是这种合入
压缩合并	`git branch -D feature/close-reopen`	`main`上是一个新提交，确认已合入后用`-D`强制删除
变基合并	`git branch -D feature/close-reopen`	`main`上是新提交哈希，确认已合入后用`-D`强制删除

远端的源分支默认保留。没有打开自动删除分支时，到仓库的分支页签，在那一行点删除分支，确认后提示分支删除成功。

变基合并还会改写服务器上的源分支：合并完成后，源分支指向那三个新提交。如果合并之后还要在这条分支上继续开发，本地先执行git fetch和git reset --hard origin/feature/close-reopen和服务器对齐，再继续提交。reset --hard会丢掉本地没推送的改动，执行前先确认。更简单的做法是从最新的main拉一条新分支。

5. 合并失败时

你看到的	原因	怎么处理
想用的方式在确认框里是灰的	仓库设置 → 拉取请求里没有打开这种方式	请仓库管理员打开对应开关，或者改用已允许的方式
仓库不允许使用变基合并（Rebase Merge）方式合并	在你打开确认框之后，管理员刚刚关掉了这种方式	刷新页面，重新选一种允许的方式
检测到合并冲突，请先解决冲突后再合并	分支和`main`改了同一处代码。变基合并逐个接提交时更容易遇到：总改动不冲突，中间某一个提交单独接上去也可能冲突	在本地把`main`合进分支、解决冲突后推送，再合并；或者改用压缩合并
选了创建合并提交，`main`上却没有合并提交	拉出分支之后`main`没有新提交，AngusGit 直接快进了	这是正常结果，代码已经合入
合并后`git branch -d`删不掉本地分支	用的是压缩合并或变基合并，`main`上的提交号和本地分支不同	确认已合入后用`git branch -D`

常见问题

合并之后能撤销吗？

页面上没有撤销合并的按钮。需要撤回时，在本地用git revert生成一个反向提交，推到新分支，再发起一条拉取请求合进main。用创建合并提交合入的，可以执行git revert -m 1 <合并提交号>一次撤回整个分支；用压缩合并合入的，撤回那一个提交即可。

团队应该统一用一种方式吗？

建议统一。混用时，main上一部分请求是一个提交，另一部分是一串提交，回头查历史和撤回时都要先分辨是哪种。在设置 → 拉取请求里只打开约定的那一种，最省事。

压缩合并之后，原来那几个提交还看得到吗？

看得到。打开这条已合并的拉取请求，提交页签里仍然列着合并前的三个提交。只是main的历史里只有那一个压缩后的提交。

为什么默认不打开变基合并？

变基合并会改写服务器上的源分支，还要求分支上的每个提交单独接到main上都不冲突。团队确定要一条直线的历史、并且每个提交都写得规整时，再打开它。

小结

三种合并方式合进去的代码相同，区别只在main的历史：创建合并提交留下全部提交加一个合并提交，压缩合并压成一个新提交，变基合并把每个提交接成一条直线。仓库管理员在设置 → 拉取请求里决定允许哪几种，团队最好约定一种。合并时检查提交信息，压缩合并尤其要写清楚；合并之后更新本地main，压缩或变基合入的本地分支用git branch -D删除。