我们的GitHub存储库存在问题。我将解释我们的工作流程：
开发人员从主线分支创建功能/错误修复分支。他们拉取请求他们的更改以将其合并回来。他们可以从主线分支重新定义，以便在它们工作时从中获取最新更新。在一次变革之后，他们推动 - 强制他们的功能分支。
最近使用GitHub Web界面自动合并了两个拉取请求。随后 - 在请求合并后大约两天 - 发现这些提交中的更改不在代码中。历史上没有任何内容表明这些变化被还原或覆盖。合并本身不会出现在提交历史记录中，并且单独的提交本身也不会出现。但拉取请求已成功合并。其中一个遗失的提交不再适用于樱桃选择。当我们尝试时，我们得到一个致命的 - 坏对象消息。
我们怀疑对历史进行了一些重写。我们如何才能发现以及如何防止这种情况发生。我们的工作流程是否存在根本性问题？
答案 0 :(得分：2)
您面临的问题与您的开发人员从主分支重新定位然后强制推动其分支机构有关。 git rebase实际做的是取消提交您所做的所有更改，合并主分支，然后重新应用您的提交（就像它们是补丁文件一样） 。这将使用全新的哈希创建一个全新的git提交。
简而言之，旧的提交已丢失，并且创建了一个新的相同提交。
这就是为什么非常不鼓励任何公开的工作，因为你正在有效地改变历史。如果他们的工作基于不再可用的变更，那么从你的工作中分支出来的任何人都会度过非常糟糕的一天。
编辑：提交本身并没有丢失，它仍然存在于您的仓库中。但是，它已不再适用于手头的分支