git：删除的代码神秘地重新出现
所以我只是对我们的一个文件进行修补，我看到了一些不应该存在的代码（加上这个流氓代码引起的网页错误）。几个月前，代码已添加到补丁中，然后在一个月前通过恢复该提交而删除。所以它真的不应该存在。
我尝试了几种方法来追踪它的来源：
git blame：奇怪的是，向我展示了添加代码的原始提交的提交标记和消息，就好像恢复从未发生过一样。
git log - filename：显示我期望在那里进行的所有提交，包括恢复，但之后没有提示它应该重新出现。
手动检查补丁（bisect）：代码在恢复后直接重新出现在提交中，但是当我检出该补丁时，它的日志完全不同，并且没有恢复。
最后一个观察结果使我得出结论，所讨论的补丁是一个混乱，但提交消息没有提到合并，我们的团队通常会保留git生成的合并消息。
那看起来是这样的吗？在解决冲突期间做出错误选择是否重新引入了代码？如果是这样，有没有更快的方法来找到这种东西？例如，git blame说代码来自我原来的补丁。但有没有办法让它直接告诉我它在修复后重新引入补丁X？如果git不知道它在合并期间是否受到影响，那么git如何跟踪每段代码的来源？是否能够告诉我在合并冲突期间有人搞砸了那段代码？我曾经认为合并本身应该出现在责任中。
没有找到相关结果
已邀请:
1 个回复
琶竞捆栓
在向你展示这种关系时应该具有启发性 @Tesserex 好的......，我说“看起来像”:) 仍有可能是你被git [1]的奇妙但必然不完美的合并跟踪（基础检测）所困扰。也许您可以在合并时查看show-branch和merge-base的输出。如果这是最后一次合并，你可以这应该返回三个sha1：。这里，mergecommit只是在合并发生时，mergetarget是'mybranch'而mergesource是'previousmergedbranch'，所以你可以运行上面的命令。 弹性提交（你还原）可能仍在等待合并（根据git）并且因此已经全部合并，撤消你的'revert'撤消......这可能由于各种原因而发生（例如原始提交已被手动转移或冲突的挑选，使得git无法检测到提交已经应用于合并目标） 我甚至不确定git是否会在合并（提交序列）中主动检测到一个非冲突（'纯'）的cherrypick;虽然它当然可以：这将显示git在合并时两个引用之间的'提交'中看到的delta作为delta。 git-log的手册页解释了--cherry-pick告诉git消除输出中的提交，即使它们有不同的commit-id（hash）但是diffs对于所有意图和目的都是相同的。 [1] OT：这是一个难题：我们可以让软件变得更聪明，但只要有漏洞抽象，就会出现问题： 合并跟踪在git中不是密不透风的 git在补丁集中合并以重放提交，但仅将所有数据存储在快照中;这在恢复合并提交时表面，例如，或者在使用移植物“伪造”历史关系时 一般的经验法则似乎是：最精细的工具将导致更少的问题。然而，当缩减打破时，狗屎将只是精致的品种:)