大部分时间在 repos 中，我们看到一个 PR，然后是该 PR 的合并提交，它只是说“Merged pull request #XXX from ...”。
但最近，我看到了一个压缩版本，其中拉取请求者和提交者的头像重叠，only one clean commit 出现在历史记录中：
如何做到这一点？
我尝试过但不起作用的方法：
更新
one of my PRs 以这种方式合并时的外观示例：
结果：
【问题讨论】：
标签： git github commit pull-request
GitHub 为 squash commits when merging 引入了一个选项，因此您可以直接从其 Web UI 执行此操作：
刚找到这个workflow from the Meteor team（巧合的是，谢谢@Emily）：
当您在 GitHub Web 界面中查看拉取请求时，有一个非常吸引人的“合并”按钮。切勿使用合并按钮。这是一个attractive nuisance。它导致 git 历史比必要的复杂得多：如果 PR 是在一个月前提交的，那么提交的父级将是一个非常旧的修订版，在 git 历史的图形视图中导致的行数比必要的多。另外，如果您使用的是合并按钮，这意味着您从未检查过代码并自己尝试过！以下是获取拉取请求的更好方法。
首先，在您的存储库中，找到.git/config 文件的[remote "origin"] 部分并添加以下行：
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
确保在现有提取行之前添加它。现在，每次 git fetch 时，都会更新 repo 中的所有拉取请求！这是一项一次性更改，可让您永远直接访问 PR。
然后您只需git checkout pr/XXX 并直接处理更改。摘樱桃后的git push origin 将创建紧凑的 PR：
git checkout pr/32
# ... test changes ...
git checkout master
git cherry-pick pr/32
git push
唯一的缺点是 GitHub 不会在 PR 分支关闭时自动删除它们，但只需单击一下即可获得更好的历史记录。
如果 PR 是多次提交，最好的办法是检查它，将其重新定位到您的开发分支，进行您需要的任何其他更改，然后将其合并回开发分支带有明确的合并提交。这类似于 GitHub 合并按钮所做的，除了合并按钮不执行非常重要的 rebase 步骤，因此它在项目的 git 提交历史中留下了难看的意大利面条。为此，请运行：
git checkout pr/32; git rebase devel; git checkout devel; git merge --ff-only pr/32然后测试并推送。
如果您想将一些提交合并为一个提交，您可以通过运行
git rebase -i devel来使用交互式变基。部分教程：http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.htmlhttps://www.atlassian.com/git/tutorials/rewriting-history/git-reflog不幸的是，GitHub 不够智能，无法检测到您手动合并了 PR，因此您需要手动评论并关闭问题并提供相关提交的链接。或者，确保合并提交的消息包含
Fixed #123。
更新：Kahmali Rose 进行了进一步的更新，使 GitHub 能够检测到 PR 已合并，就像点击了邪恶的合并按钮一样：make sure to rebase and merge instead of cherry-picking。
【讨论】：
如果 PR 只是一次提交，您可以将其挑选到 master 分支（或您将 PR 合并到的任何分支）。所以，例如：
$ git checkout -b branch-for-pr master
$ git pull <fork url> <pr branch name>
$ git checkout master
$ git cherry-pick branch-for-pr
或者，您可以将 PR 分支重新设置在 master 之上，以允许快进合并（这将跳过合并提交）：
$ git checkout -b branch-for-pr master
$ git pull <fork url> <pr branch name>
$ git rebase master
$ git checkout master
$ git merge --ff-only branch-for-pr
【讨论】：