细分3种Github UI的细分

Question

我一直在使用Github UI来合并PR（拉取请求），UI看起来像：

我试图了解这三件事情如何更加谨慎。以下是这三个选项的最佳猜测：

1. 创建合并提交

git merge <base> <other>

2. 壁球和合并

git merge --squash <base> <other>

3. 重新基础和合并

git rebase <base> <other>

这准确吗？或者我错过了什么？

Answer 1

我在Merge pull request in git causes the upstream branch to go ahead of origin有一个更长版本的答案，但这里是速记等价物。所有人都假设你在基础分支上开始，即git checkout branch。下面的消息是Merge pull request #number from repository，hash是从pull请求自动计算出来的。

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-也跟踪用于创建拉取请求的“基本分支”是否是/最新，但目前尚不清楚他们是如何做到的。）