我们的项目已经使用Git一个星期左右了，我们都很享受它（在一个紧密的协作组中使用它变成了一个完全不同的Git体验）。为了使事情尽可能简单，我们不会进行任何变基或历史修改。但我们确实在第一周犯了一些错误。做了一些不应该做的提交，我们设法将一个功能分支合并到错误的集成分支（1.1而不是1.0）。在他们长期进入我们的历史之前，我们没有发现这些事情。
现在我看到很多关于重写历史的警告，但我不确定我是否理解所涉及的危险。我们使用共享的裸存储库，并将所有分支推送到那里进行备份。
我希望如果你重写历史记录（比如删除一个提交），后续提交的完整列表将“丢失”该提交（并且可能无法编译/工作）。我也希望如果发生这种情况，我实际上可以选择在历史的顶部解决这个问题（并将这部分历史留作非编译）。
git pull上发生合并失败？任何关于这个主题的文章/教程的参考也会非常好。
答案 0 :(得分：16)
Git用户手册中的必读值为Problems with rewriting history。
如果我重写历史（并且所有受影响的分支都编译/工作），我的同事是否需要做任何特殊命令（即如果我做得好，他们会“知道我已经完成了吗？”）？
他们会知道，Git会毫不含糊地告诉他们某事是错误的。它们将获得意外的错误消息，并且可能在尝试解决由此产生的合并冲突的过程中，无意中还原了以前的提交。这个问题会产生真实的信息，如果您想知道发生了什么，您可以随时在存储库的临时副本上进行尝试。
具有我不知道的本地更改的任何用户是否有资格在git pull上合并失败？
当然，见上文。
我错过了这里必不可少的东西吗？
避免以（几乎）所有费用重写历史记录！
答案 1 :(得分：6)
正如其他答案评论中所提到的，实际上每次提交都是唯一的，重写历史记录会进行新的提交。
您可以将其视为切断树枝，然后立即种植新树。他们甚至可能看起来相同但不是。是的，伏都教魔法。在这个类比中，恢复几乎就像支持一个带有日志的下降分支一样，所以它会在没有掉下来的情况下发展。
这导致我们a couple good reasons to rewrite history：
那些已经揭示了Greg已经说过的内容：如果存储库是公共的（推送提交），则重写历史will potentially screw up everyone。之所以我也提倡不惜一切代价避免这样做，即使是在私人回购中，只是为了保持良好的习惯：所以重写历史应该不惜一切代价避免 （这意味着要给予在做之前要充分考虑：减轻利弊！）
至少还有另一个哲学和被忽视的原因：重写历史是数据丢失。是的，revert的git历史可能看起来比reset更糟糕。但是如果写得恰到好处，那些“乱七八糟”的东西都可以隐藏在分开的分支中，但我们仍然可以准确地看到恢复的完成点。即使有理由或证据证明为什么要这样做。
回到树的比喻，即使你删除了支持日志，回复的分支也会显示曲折的生长曲线，它很漂亮！