在我的组织中，我们有一个提交钩子，如果树中的任何提交的作者值与特定模式都不匹配，该提交钩子将拒绝提交。通常用于在错误的提交合并到目标分支之前捕获错误的提交。它也可以扫描目标分支中的现有提交，这一事实通常并不重要，因为该钩子可防止合并那些“受污染的”提交。
但是，维护该挂钩的人昨天遇到了生产问题，导致所有开发人员都被封锁。因此，他们将其关闭，直到他们弄清楚它为什么破裂。
我立即对此感到担心，因为这意味着没有充分注意的开发人员可能会合并作者价值不佳的一个或多个提交。
正如我预期的那样，我的担忧得以实现，因为一位开发人员设法做到了。
我们有一个烦人的解决方法，即使目标分支中存在一些“污染的”提交，钩子也可以通过验证（要求在中央存储库（BitBucket）中创建源分支，而不是在本地存储库中创建），但是我真的不想这样做，或者让其他所有开发人员都这样做。
我真的只想修复已经合并的提交。
因此，这意味着交互式变基。我了解流程，甚至了解如何更改每次提交的作者值。我担心的是有关“重写历史记录”的警告，以及这是否会破坏任何内容。当您在仅由您使用且尚未合并到目标分支的拉取请求分支上工作时，Interactive rebase很好。我说的是在“主人”上这样做。
但是，我要对所有这些提交所做的唯一更改是作者值。如果这是我所做的唯一更改，那么会有什么风险？这样是否可以消除主要的“重写历史记录”风险？
答案 0 :(得分：1)
当您重写提交历史记录并将其强制作为中央存储库在远程计算机上时，此操作不会更改当前正在使用此存储库的其他人在自己的本地存储的引用副本。
就后果而言，这意味着什么？
他们可能已经从master的旧引用中分支了自己的功能分支（并对其进行了处理），该引用在其现在重写的历史记录中已不存在。此时，请注意，最早的重写提交之后的所有历史记录都将被自身重写，因为它在生成哈希值时使用其父级的引用，因此即使您仅修改一个提交，所有历史记录将从此提交重写到最新提交。
因此，他们将无法将任何东西推送到不再识别其回购历史记录版本的遥控器。 （此外，请注意不要破坏标签和已签名的提交，感谢phd的提醒）
为此，他们必须备份其当前分支，将其master的本地版本还原到新版本，然后在其基础上重新部署/樱桃选择。
所以团队沟通是这里的关键。如果某人不知道该过程，并且（...由于他在尝试推动时被拒绝...）在过程中的某个时刻强行推动他的旧裁判。得到（吓人）的照片。召集每个用户围绕此进行讨论，当每个人都同意同一行动方案时，这将成为可解决的案例。
（要超越这些一般性原则，请看一下torek's answer here，它对这个主题很有帮助。）