我一直对“压扁”或重写历史持怀疑态度，现在我只是坚信应该禁止这种做法来自我管理的回购协议。但是也许有人可以回答这个问题，并为我的壁球冠军节省了一天的时间。
我刚遇到了一段代码，我想了解其背后的原因，因此我使用了git annotate来找出谁写的以及为什么写的。但是它指向“压缩的”提交，一长串提交消息标头，其中包含许多功能和错误修复，但没有详细信息。真的没有帮助。
“哦，但总有reflog，”我确信。 “信息永远不会在git中丢失！”好吧，很高兴听到它！但是我尝试了git reflog <squashed-commit-hash>，却没有任何输出-毫无帮助。我还尝试了git rev-list <squashed-commit-hash>，并获得了数百个哈希的列表，并使用git show手动检查了其中的一些哈希后，我得出结论，它们不属于被压缩的部分，也无济于事
那么实际上是否有可能找出哪个单一提交促成了该行代码，并查看该提交的整个消息？是否可以在一个git命令中完成，而不必成为bash专家？还是实际上这些信息实际上在git中丢失了？
答案 0 :(得分：3)
挤压提交会将许多提交变成一个提交，使提交者可以选择维护每个单独提交的提交消息。
如果他们选择 not 来做到这一点，那么就无法辨别有关合并为一个的单个提交的信息。
我应该强调：
我已经放心了； “信息永远不会在git中丢失！”
这仅与 关联到Git下的文件，该文件通常是源代码。自然，当一个人重写历史记录时，所有赌注都关闭了。
由于您可以看到谁进行了这项工作，因此，获取有关该特定代码行的更多信息的最佳选择是与他们一起进行代码审查。如果他们不再与您合作，那么您要做的就是减少整个提交。
答案 1 :(得分：2)
由于其他答案尚未解决，我认为这一点需要指出：
“哦，但是总有reflog，”
不。 100％错误。刷新日志是本地的和临时的。
的确，git在防止历史丢失方面做得很好（除非您明确地指示它失去历史），但是说信息永不丢失绝对是不准确和危险的。人们需要了解信息丢失（和不会丢失）的方式，以便他们知道何时以及如何依赖git真正提供的保护。
关于更广泛的问题：
重写共享历史记录通常不是一个好习惯。提倡积极进取基础的大多数人都想在推向远端之前，在 之前重写历史记录。这不仅是一种不受欢迎的做法，而且即使您愿意也禁止它是几乎不可能的（因为当我推送一个提交时，您不知道我是否通过压缩多个先前的提交来创建它）。
最终提交的可接受的粒度以及每个提交的可接受的文档是您需要与团队一起设置的标准。执法最终可能会变得更具社会性而非技术性。
答案 2 :(得分：1)
那么实际上是否有可能找出哪个单一提交促成了该行代码，并查看该提交的全部信息？
就您的项目历史而言，“单个提交”是压缩的提交，因此这将作为代码更改的源显示。这是有意的，实际目的是将多个提交合并为一个，以保持git历史记录的可管理性。这是我何时压缩项目上的提交的示例：
我正在研究中型功能。需要几天的时间才能完成。我倾向于定期进行“在建工程”（WIP）的提交，并且总是每天结束。我的提交消息通常在我正在使用的当前功能的范围内，而不是整个项目。一旦功能完成并且我合并到任何工作分支（比如dev）中，这些消息就很难在项目上下文中解析，并且我在功能分支上所做的提交之间的差异对于可维护性而言并不重要。重要的区别在于功能之前与功能之后，因此我将所有提交合并到一个标记为“（（票证编号）-（功能名称）”