提交如何从一个文件的日志中消失？答案

【问题标题】：How does a commit disappear from the log of one file?提交如何从一个文件的日志中消失？
【发布时间】：2011-09-24 19:22:26
【问题描述】：

所以我对文件进行了更改，将其推送到我们的主仓库，在那里看到了它。大卫从那个 repo 中取出并做了——嗯，一些事情——但看不到我的变化。由于 David 是典型的 Microsoft 受害者，我让他将他拥有的东西推回 repo，我会在那里查看。

git log --name-only 产生

commit 194b7f5dbb59d29ace340a376f10906752978db5
Merge: 484df79 afc2dec
Author: David Good <david@company.com>
Date:   Sat Sep 24 11:47:14 2011 -0700

[ David's merge ]

commit afc2dec4a828de05350c39526eeecf9d3a15e465
Author: Michael <info@company.com>
Date:   Sat Sep 24 10:58:54 2011 -0700

[ my changes ]

backend/theimportantfile.js

commit e4e2f9ce9df3adf5ed0547ed16521eb742cc2ac1
Author: Michael <info@company.com>
Date:   Sat Sep 24 10:47:09 2011 -0700

[ some other thing ]

但git log backend/theimportantfile.js 产生

commit eb470fe1792220779b14e90337f74fb216fc9f7f
Author: David Good <david@company.com>
Date:   Mon Sep 12 17:20:25 2011 -0700

[ comment ]

commit 63ddd2be020092a4bf65d1eac106ece5fd7fbbd3
Author: David Good <david@company.com>
Date:   Fri Sep 9 16:23:53 2011 -0700

[ comment ]

因此，根据 git 的说法，backend/theimportantfile.js 几周内没有被触及，但它也在两个小时前被 afc2dec 提交更改。如何追踪发生的事情？

【问题讨论】：

这很奇怪，大卫做了push --force 吗？
对于文件的最新更改，差异说明了什么？真的变了吗？
尝试git log --decorate=full，以防万一有一个名为backend/theimportantfile.js的标签或分支。这不是很好笑吗？
@rodrigo -- 这并不好笑，但实际上，实际名称要长得多，并且有多个文件处于相同的情况。
日志说更改是在 afc2dec 中进行的，然后在 194b7f 中恢复（这是有道理的）。

标签： git

【解决方案1】：

看来大卫的合并是你所做的。我这样说是因为合并似乎已经“恢复”了你的更改。

#this command will show you if anything 'strange' happened during the merge"

git show 194b7f

如果该命令没有给出有趣的输出，那么 David 可能与“我们的”策略合并，或者巧妙地将我的文件 cp 到临时位置；混帐合并；覆盖冲突文件； git commit 的工作流程。

无论这种状态是如何到达合并的，都需要丢弃并重做，因为它显然是错误的。您也可以考虑更改您的工作流程，以便 David 不再需要进行合并，而是提交非正式（或正式）“拉取请求”，然后您负责合并。

【讨论】：

David 在 Git 之上使用了一个非常简单的 Windows GUI。他当然没有指定什么奇怪的策略。
简单地用某处的副本覆盖文件就可以了吗？使用 'git checkout ' 也可能是罪魁祸首。或者让文件在编辑器中打开并重新保存，然后提交结果...

【解决方案2】：

我不确定这是否是您问题的本质，但默认情况下，git log 有时会过滤掉它认为没有“有用”或“有趣”的提交，以便了解最终状态提交树。来自the git log docs：

有时您只对历史的一部分感兴趣，例如修改特定的提交。但是History Simplification有两个部分，一个是选择提交，另一个是如何做，因为有多种策略可以简化历史。

以下选项会影响简化的执行方式：

Default mode
将历史简化为解释树最终状态的最简单历史。最简单，因为如果最终结果相同（即合并具有相同内容的分支），它会修剪一些分支。

您可以在文件中传递--full-history 标志，而不是使用默认模式，然后查看“丢失”提交是否以这种方式显示：

git log --full-history -- backend/theimportantfile.js

来自git log 文档：

--full-history
与默认模式相同，但不会删除某些历史记录。

编辑

我知道这有时会起作用，因为我遇到了这样一种情况，即我在 master 中提交了 X，其中包含对文件 theFile 的更改。提交 X 然后被同事挑选到 anotherBranch 中，所以我们将新提交称为 Y。然后anotherBranch被合并到master中。

当我们这样做时

git log -- theFile

我们不会在提交列表中看到Y，只有X，但是当我们使用时

git log --full-history -- theFile

只有这样X 和Y 才会出现。我猜 Git 默认没有显示 Y，因为它对提交树的最终状态引入了相同的更改，因为它是从 X 中挑选出来的。

【讨论】：

【解决方案3】：

看起来他可能遇到了合并冲突，并通过接受他的版本（这可能是一个不存在的文件）而不是您的版本来解决它。你可以把文件拿回来。见how to resurrect a file or folder

【讨论】：