我一直对"挤压"或重写历史持怀疑态度，现在我几乎确信我应该在我管理的存储库中禁止这种做法。但也许有人可以回答这个问题，为我的壁球冠军同事节省一天的时间。
我刚刚遇到了一行代码，我想了解背后的原因，所以我用git annotate来找出是谁写的以及为什么。但它指向一个"压缩"的提交，一长串关于无数功能和错误修复的提交消息标头，没有细节。不是很有帮助。
"哦，但总有回避日志，"我确信;"信息永远不会在 Git 中丢失！"好的，很高兴听到它！但是我尝试了git reflog <squashed-commit-hash>，根本没有输出 - 没有帮助。我也尝试了git rev-list <squashed-commit-hash>，并得到了数百个哈希的列表，在用git show手动检查了其中的一些哈希后，我得出结论，它们不是被挤压的一部分 - 也没有帮助。
那么，是否真的有可能找出哪个单个提交贡献了该行代码，并查看该提交的整个消息？可以在单个 git 命令中完成，而不必成为 bash 大师吗？或者这些信息实际上实际上在 git 中丢失了？
由于其他答案尚未解决，我认为这需要指出：
"呵呵，但总有回执
。"
不。 100%错误。 引用日志既是本地的，也是临时的。
的确，git 在防止丢失历史记录方面做得很好(除非您特别指示它丢失历史记录(，但是说信息永远不会丢失是非常不准确和危险的。 人们需要了解信息可以(和不能(丢失的方式，以便他们知道何时以及如何依赖 git 真正提供的保护。
关于更广泛的问题：
重写共享历史通常不是一个好的做法。 大多数主张积极变基的人都希望在推进远程之前重写历史。 这不仅是一种不那么不受欢迎的做法，而且即使您愿意，也几乎不可能禁止(因为当我推送提交时，您不知道我是否通过压制之前的几个提交来创建它(。
最终提交的可接受粒度以及每个提交的可接受文档是您需要与团队一起设置的标准。 执法最终可能会更多地是社会而不是技术。
压缩提交会将许多提交变为一个，使提交者可以选择为每个单独的提交维护提交消息。
如果他们选择不这样做，那么就无法辨别有关合并为一个的单个提交的信息。
我应该强调：
我已经放心了;"信息永远不会在 Git 中丢失！"
这仅与 Git 下的文件有关，通常是源代码。 当然，当一个人改写历史时，所有的赌注都落空了。
由于您可以看到谁提交了工作，因此获取有关该特定代码行的更多信息的最佳选择是与他们一起进行代码审查。 如果他们不再与您合作，那么您所要做的就是整个被压扁的提交。
实际上是否有可能找出哪个单个提交对该行代码的贡献，并查看该提交的整个消息？
就项目的历史记录而言，"单个提交"是压缩的提交，因此这就是将显示为代码更改源的内容。这是有意为之，实际目的是将多个提交合并为一个，以保持 git 历史记录的可管理性。下面是我何时压缩项目提交的示例：
我正在开发一个中等大小的功能。需要几天时间才能完成。我倾向于在"正在进行的工作"(WIP(提交时非常定期地提交，并且总是在一天结束时。我的提交消息通常在我正在处理的当前功能的范围内，而不是整个项目范围内。一旦功能完成并且我合并到任何工作分支(假设 dev(中，这些消息很难在项目的上下文中解析，并且我在功能分支上所做的提交之间的差异对于可维护性并不重要。重要的差异是在功能之前与功能之后，所以我将所有提交合并到一个标记为"(票号(-(功能名称("之类的内容中