7

我们的 GitHub 存储库存在问题。我将解释我们的工作流程：

开发人员从主线分支创建功能/错误修复分支。他们拉取他们的更改以将其合并回来。他们可能会从主线分支重新设置基础，以便在他们工作时从中获取最新更新。在 rebase 之后，他们将 --force 推送到他们的功能分支上。

最近使用 GitHub Web 界面自动合并了两个拉取请求。随后 - 在请求合并后大约两天 - 发现这些提交中的更改不在代码中。历史上没有任何迹象表明这些更改被还原或覆盖。合并本身不会出现在提交历史中，并且单个提交本身也不会出现。但是拉取请求已成功合并。缺少的提交之一不再可用于樱桃挑选。当我们尝试时，我们会收到一个致命的 - 坏对象消息。

我们怀疑已经发生了一些历史改写。我们如何才能发现以及如何防止这种情况发生。我们的工作流程是否存在根本性的问题？

4

1 回答 1

3

您面临的问题与您的开发人员从主分支变基然后强制推动他们的分支有关。git rebase实际上它会取消提交您所做的所有更改，合并主分支，然后重新应用您的提交（就像它们是补丁文件一样）。这将创建一个带有全新哈希的全新 git commit。

简而言之，旧的提交丢失了，并创建了一个新的相同提交。

这就是为什么非常不鼓励对任何公开的工作进行 rebase，因为你实际上是在改变历史。如果他们的工作基于不再可用的更改，那么任何从你的工作分支出来的人都会有一个非常糟糕的一天。

编辑：提交本身并没有丢失，它仍然存在于您的存储库中。但是，它不再在手头的分支上可用

于 2013-12-23T15:40:26.480 回答