git 注释压缩的提交

Question

我一直对“压制”或重写历史持怀疑态度，现在我几乎确信我应该在我管理的存储库中禁止这种做法。但也许有人可以回答这个问题，并为我的壁球冠军同事们拯救这一天。

\n\n

我刚刚遇到一行代码，我想了解背后的推理，所以我使用git annotate找出它是谁写的以及为什么。但它指向一个“压缩”的提交，一长串关于无数功能和错误修复的提交消息标题，但没有详细信息。不太有帮助。

\n\n

“哦，但是总会有转发的，”我得到了保证。“信息实际上永远不会在 git 中丢失！” 好的，很高兴听到！但我尝试了git reflog <squashed-commit-hash>，但根本没有输出\xe2\x80\x94没有帮助。我也尝试过git rev-list <squashed-commit-hash>，并获得了数百个哈希值的列表，并在手动检查其中一些之后git show，我得出结论，它们不是被压扁的部分\xe2\x80\x94也没有帮助。

\n\n

那么实际上是否有可能找出哪一个提交对该行代码做出了贡献，并查看该提交的整个消息？是否可以通过单个 git 命令来完成，而不必成为 bash 大师？或者这些信息实际上已经在 git 中丢失了吗？

\n

Answer 1

由于其他答案没有解决这个问题，我认为需要指出这一点：

“哦，但总有转发日志，”

不，100%错误。reflog 既是本地的也是临时的。

确实，git 在防止历史记录丢失方面做得非常好（除非你专门指示它丢失历史记录），但说信息永远不会丢失是非常不准确和危险的。人们需要了解信息可能（和不能）丢失的方式，以便他们知道何时以及如何依赖 git 真正提供的保护。

至于更广泛的问题：

重写共享历史通常不是一个好的做法。大多数主张积极变基的人都希望在推送到远程之前重写历史。这不仅是一种不太受欢迎的做法，而且即使你想禁止也几乎不可能（因为当我推送一个提交时，你不知道我是否通过压缩之前的几次提交来创建它）。

最终提交的可接受的粒度以及每次提交的可接受的文档是您需要与团队一起设定的标准。执法最终可能更多地是社会性的而不是技术性的。