重写 Git 历史会产生什么实际后果？

Question

我们的项目现在已经使用 Git 大约一周了，我们都非常喜欢它（在紧密的协作小组中使用它结果证明是一种完全不同的 Git 体验）。为了使事情尽可能简单，我们不进行任何变基或历史修改。但我们在第一周确实犯了一些错误。进行了一些不应该完成的提交，并且我们设法将功能分支合并到错误的集成分支（1.1 而不是 1.0）。直到这些事情进入我们的历史很长一段时间后，我们才发现它们。

现在我看到很多关于重写历史的警告，但我不确定我是否理解其中的危险。我们使用共享的裸存储库，所有分支都被推送到那里进行备份。

我希望如果您重写历史记录（例如删除提交），后续提交的完整列表将“丢失”该提交（并且可能无法编译/工作）。我还期望，如果发生这种情况，我实际上可以选择在历史记录的顶部修复此问题（并将历史记录的那部分保留为非编译）。

• 如果我重写历史记录（并且所有内容都在所有受影响的分支中编译/运行），我的同事是否需要执行任何特殊命令？ （换句话说，如果我做得好，他们会“知道我已经做到了”吗？）
• 任何具有我不知道的本地更改的用户是否有资格在 git pull 上合并失败？
• 我在这里遗漏了什么重要的东西吗？

任何有关此主题的文章/教程的参考也非常好。

Answer 1

必读内容是问题重写 Git 用户手册中的历史记录。

如果我重写历史记录（并且所有内容都在所有受影响的分支中编译/运行），我的同事是否需要执行任何特殊命令（即，如果我做得好，他们会“知道我已经做到了”吗？）？

他们会知道，Git 会毫不含糊地告诉他们出了什么问题。他们会收到意外的错误消息，并且可能在尝试解决由此产生的合并冲突的过程中，无意中恢复以前的提交。这个问题会创建一条真实的消息，如果您想看看会发生什么，您可以随时在存储库的临时副本上尝试它。

任何进行了我不知道的本地更改的用户是否有资格在 git pull 上合并失败？

绝对可以，见上文。

我在这里遗漏了什么重要的东西吗？

（几乎）不惜一切代价避免重写历史！

Answer 2

正如其他答案评论中提到的，实际上每个提交都是唯一的，重写历史记录将产生新的提交。

你可以把它想象成砍掉一棵树的树枝，然后立即长出新的树枝。它们甚至可能看起来相同，但实际上并非如此。是的，巫毒魔法。在这个类比中，恢复几乎就像用一根圆木支撑一根掉落的树枝，因此它会继续生长而不会掉落。

这引导我们重写历史的几个充分理由：

• 在公开之前精简私有存储库：例如，创建一个新的本地私有分支，测试，测试，重写，推送。
• 在公开之前从私人存储库中删除敏感数据。

这些已经揭示了格雷格已经说过的话：重写历史 可能会搞砸每个人。为什么我也主张不惜一切代价避免这样做，即使是在私人回购中，只是为了保持好习惯：所以应该不惜一切代价避免重写历史 ^{（这意味着只给在这样做之前要考虑足够的考虑：权衡利弊！）}

而且至少还有另一个被忽视的哲学原因：重写历史就是数据丢失。确实，带有 revert 的 git 历史记录可能看起来比 reset 更混乱。但如果编写得当，所有这些“混乱”都可以隐藏在单独的分支中，并且我们仍然可以准确地看到恢复是在哪一点完成的。即使有理由或证据说明为什么这样做。

回到树的比喻，即使你去掉了支撑原木，恢复的树枝也会呈现出蜿蜒的生长曲线，非常漂亮！