gpt4 book ai didi

Git 丢失的提交无法在历史中找到

转载 作者:太空狗 更新时间:2023-10-29 13:48:04 26 4
gpt4 key购买 nike

我们有多个开发人员在一个共享的 git 存储库上工作(他们推送到这个)。

我们发现开发人员所做的一些提交丢失了。

我们可以使用 gitk 命令(在 windows 中使用)查看这些提交历史。

但是,当我们查看 gitk 中显示的提交中指定的文件并使用 git log filepath 查看历史记录时,我们根本看不到该提交。

我们不知道这怎么会发生,也不知道如何恢复。

我们认为以这种方式丢失了来自不同开发人员的 10 多个提交。

一件奇怪的事情是,我们使用 git checkout 034534fd 检查了一些旧的提交并完成 git cherry-pick 234234321 一项一项的提交。在执行此操作时,我们得到了丢失的提交,但是“234234321”的提交日志中没有显示有关受影响文件的任何内容。

最佳答案

我对你的问题有点困惑。你是说你可以在 gitk 中看到提交,但在 git log -- filepath 中看不到?

如果是这样,您的提交不会丢失; git log 的历史简化对您 stash 了它们,因为它认为它们无趣。如果您将 --full-history 参数传递给 git log,您应该会看到它们。

解释

默认情况下,当您执行 git log -- filepath 时,如果 Git 认为该更改无趣,则 Git 不会向您显示该文件的更改。这被称为“历史简化”。这种情况经常发生在 cherry-pick 时。

关于历史简化的文档(参见git help log)写得不是很好(极难理解),但这里是关键部分:

Default mode

Simplifies the history to the simplest history explaining the final state of the tree. Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content)

[...]

Commits are included if they are not TREESAME to any parent (though this can be changed, see --sparse below). If the commit was a merge, and it was TREESAME to one parent, follow only that parent. (Even if there are several TREESAME parents, follow only one of them.) Otherwise, follow all parents.

换句话说,当 Git 遍历历史寻找更改 filepath 的提交并遇到 merge 提交时,它并不总是遍历 merge 提交的所有父级。它通常只选择一个 parent ,并且只走那个 parent 的祖先。这意味着如果提交在其他分支之一中,您将看不到修改该文件的提交。

--full-history 参数告诉 git log 遍历所有父级,从而显示每个修改 filepath 的提交是否 Git 相信它有趣与否。

关于Git 丢失的提交无法在历史中找到,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9603072/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com