【发布时间】：2015-12-12 05:05:20
【问题描述】：
在我的工作场所，我们首先创建一个分支，在我们的 Github 存储库中为该分支创建一个拉取请求，然后有人对其进行审查并点击“合并拉取请求”来提交代码。这是一个非常标准的工作流程。
通常，当我们点击“Merge pull request”时，Github 会创建一个名为“Merge pull request #1234 from branchname”的新提交，其中包含 2 个父级 - master 的 HEAD，以及 PR 中的最新提交。
今天我像往常一样合并了一个 PR，不知何故 Github 决定不使用 master 的 HEAD 作为父母之一，而是使用一天前的提交（我们每天进行 20 到 30 次提交）。它使用的这个提交是 PR 分支所基于的提交。这导致 master 分支丢失了从那时到此 PR 合并之间的所有提交。
有谁知道这是怎么发生的？这是 Github 的错误吗？还是提交 PR 的开发者做了什么坏事，可能会覆盖 master？我认为所有提交都将简单地合并到 master 中，而无需在 Github 中进行任何 rebase 或历史重写。
【问题讨论】：
-
我不认为开发人员在这方面可以做任何坏事；您要么在 github 上遇到了错误，要么认为已经将提交推送到 github 的假设不成立（我怀疑是后者）。
-
是公开的，能链接到相关的commit吗？
-
您是尝试从命令行远程合并，还是使用 GitHub 的绿色“合并”按钮？
-
不幸的是，这是一个私人存储库，否则我会链接它。我使用 Githubs 绿色合并按钮合并，我们总是这样合并。
-
Github 包含 master 丢失的所有提交，它们仍在我们的 deploy-staging 和 deploy-prod 分支中（master 在经过测试后合并到这些分支中）
标签： git github merge git-branch git-history-graph