git - 重写 Git 历史的实际后果是什么？

Question

我们的项目已经使用 Git 一周左右了，我们都非常享受它(在一个紧密协作的团队中使用它是一种完全不同的 Git 体验)。为了尽可能简单，我们不做任何 rebase 或历史修改。但是我们在第一周确实犯了一些错误。做了一些不应该做的提交，我们设法将一个功能分支 merge 到错误的集成分支(1.1 而不是 1.0)。直到它们长期存在于我们的历史中，我们才发现这些事情。

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

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

• 如果我重写历史(并且所有受影响的分支都编译/工作)，我的同事是否需要执行任何特殊命令？ (换句话说，如果我做得好，他们会“知道我做了”吗？)
• 在 git pull 上进行 merge 失败但我不知道的任何用户是否有资格 merge 失败？
• 我是否遗漏了任何重要信息？

任何对此主题的文章/教程的引用也非常好。

Answer 1

需要阅读的是Problems with rewriting history在 Git 用户手册中。

If I rewrite history (and everything compiles/works in all affected branches), will my co-workers need to do any special commands (i.e. will they "know that I have done it" if I did it well?)?

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

Will any users with local changes that I do not know about be eligible for merge failures on git pull ?

当然，见上文。

Am I missing anything essential here ?

(几乎)要避免重写历史!