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