我们有多个开发人员在共享git存储库上工作(他们推动这个).
我们发现开发人员完成的一些提交都丢失了.
我们可以使用gitk命令(在windows中使用)查看这些提交历史记录.
但是当我们去gitk中显示的提交中指定的文件并使用git log filepath我们看不到提交时,我们看不到提交.
我们不知道这是怎么发生的,也不知道如何恢复.
我们认为来自不同开发者的10多个提交都以这种方式丢失.
其中一个奇怪的事情是,我们检查了一些旧的提交使用git checkout 034534fd
并git cherry-pick 234234321逐个提交.在执行此操作时,我们收到了丢失的提交,但在"234234321"的提交日志中没有显示有关受影响文件的信息.
Ric*_*sen 11
我对你的问题感到有些困惑.你是说你可以看到提交gitk而不是提交git log -- filepath?
如果是这样,你的提交不会丢失; git log历史简化是将它们隐藏起来,因为它认为它们无趣.如果您将--full-history参数传递给git log您应该看到它们.
默认情况下,当您这样做时git log -- filepath,如果Git认为更改无趣,Git将不会向您显示该文件的更改.这被称为"历史简化".这通常发生在樱桃挑选中.
有关历史简化的文档(请参阅参考资料git help log)编写得不是很好(非常难以理解),但以下是关键部分:
默认模式
将历史简化为最简单的历史,解释树的最终状态.最简单的,因为如果最终结果相同(即合并具有相同内容的分支),它会修剪一些侧分支
[...]
如果对任何父母不是TREESAME,则包含提交(尽管可以更改,见
--sparse下文).如果提交是合并,并且它是一个父级的TREESAME,则只关注该父级.(即使有几个TREESAME父母,也只能跟随他们中的一个.)否则,请跟随所有父母.
换句话说,当Git走向历史寻找改变filepath并遇到合并提交的提交时,它并不总是遍历合并提交的所有父级.它通常只挑选一个父母,只走那个父母的祖先.这意味着如果提交位于其他分支之一中,您将不会看到修改该文件的提交.
该--full-history参数告诉git log所有父母走路,从而显示每一个修改filepathGit是否认为有趣的提交.
| 归档时间: |
|
| 查看次数: |
5876 次 |
| 最近记录: |