三种Github UI合并的细分

Question

我已经使用Github UI合并PR（拉请求）已有一段时间了，该UI看起来像：

我试图更仔细地理解这三件事。这是我对这三个选项的最佳猜测：

1. 创建合并提交

git merge <base> <other>

1. 压缩并合并

git merge --squash <base> <other>

1. 变基并合并

git rebase <base> <other>

这是准确的吗？还是我错过了什么？

Answer 1

我在Merge pull request in git causes the upstream branch to go ahead of origin中对此答案有更长的版本，但这是等效的简写。所有人都假设您是从基础分支开始的，即git checkout branch。下面的 message 是Merge pull request #number from repository，而 hash 是根据提取请求自动计算的。

1. 创建合并提交

   git merge --no-ff -m message hash

2. 压缩并合并

   git merge --no-commit --squash hash && git commit -m message

3. 重新合并并合并

   git rebase --force-rebase hash

（请注意，如果发生合并冲突，rebase-and-merge将不起作用。我不清楚GitHub系统是否使用--merge进行检查，或者不进行检查，或者完全以其他方式进行检查。拉取请求已经检查了有git merge有无--squash的合并冲突； refs/pull/head/number一直存在，但是refs/pull/merge/number仅在没有这样的冲突的情况下存在。他们（GitHub）还跟踪用于创建拉取请求的“基础分支”是否是最新的，但还不清楚他们是如何做到的。）