git可以完全删除远程历史记录吗？ 当我们考虑在工作中从Svn移动到Git时，一个同事提出了一个担心，即恶意或容易出错的开发人员可以使用 Git ReBase从我们的共享回购中删除远程历史。

编辑：正如答案中所指出的，还可以使用

git push origin:branch name

从远程回购中删除整个分支

---

这是一个现实问题吗？如果是这样的话，我们可以采取什么方法来防止它？

使用rebase可以弄乱历史记录，但通常远程回购不会接受修改历史记录的更改（除非使用git push--force），但更重要的是，具有推送权限的开发人员可以完全删除分支（git push origin:branch name）。因此，简单的规则是：

• 不要让您不信任的开发人员获得推送权限

• 当回购协议被共享时，不要弄乱历史记录，避免在过去的提交中使用回基。如果需要添加来自不同分支的内容，请使用“合并”或“樱桃拾取”，在这种情况下，历史记录不会受到影响

• 您可以维持在共享回购上不使用“push-f”的策略，在这种情况下，开发人员会知道，如果推送被拒绝，那么就会出现问题（很可能本地分支机构与远程分支机构不同步），并且应该在本地解决问题，而不是强制推送

---

关于如何防止使用修订系统的问题，这就像开发人员的本地存储库和主repo之间提交的中间步骤，具有良好的修订web界面，您可以向任何人授予推送到修订存储库的权限，但是，在验证和批准之后，更改将合并到主分支中（这需要您通常授予核心开发人员的一些权限）。您可能会看到Mahara项目的情况：在这种特殊情况下，只有gerrit bot被允许推送至master（即）而不是其他人。

我倾向于同意您的同事的观点，这里存在一个问题，因为：

• 无论你多么信任你的提交者，总有人为错误的可能
• 更繁重的审查流程（如Gerrit）并不总是合适的
• 从备份中恢复可能会很慢，而且会带来PITA问题

您考虑过和配置参数了吗？AFAICT在Git 1.6以后的版本中提供

从Pro Git：

如果重新设置已推送的提交的基础，然后尝试推送 再次，或者尝试将提交推送到 不包含远程分支当前指向的提交， 你会被拒绝的。这通常是好政策；但在这种情况下 在重新设定基准时，您可能会确定您知道自己在做什么，并且可以 使用push命令的

-f

标志强制更新远程分支

禁用强制将远程分支更新到的功能 非快进引用，设置

receive.denynonfastforts

另一种方法是通过服务器端接收挂钩，我将在后面介绍。这种方法可以让你做更复杂的事情，比如拒绝非快进到某个用户子集

正如作者所提到的，这个规则也可以通过一个接收钩子来强制执行

---

这些技术应该可以防止在共享repo中意外（或恶意）丢失历史记录。

像Gerrit这样的企业Git服务器有一些扩展，可以检测历史记录重写和分支删除，并将它们备份到一个特殊的ref下，以便在需要时可以恢复它们，而不会被垃圾收集删除。如果出于法律原因需要，Gerrit管理员仍然可以删除选定的提交

@sehe这并没有解决人为错误问题，并且使得git的采用成为一个组织问题和技术问题。你有什么要说的吗？采用VCS工作流是一项组织挑战。另外，我觉得很有趣的是，你在接受了一个同样的回答并提议使用Gerrit来缓和推送访问之后，这样说。。。在8月8日，我要说的一点是，“你必须信任每一个开发人员，或者有一个看门人，没有人会犯错误”，对于我（同事）的问题，这并不是一个令人满意的答案。我接受了一个粗略的回答，假设这是唯一的解决办法，但几周后，一个不同的方法被提出。我会尝试配置参数的方法，如果成功的话，这将是我的首选答案。这对我们来说是一个很好的解决方案——但我对接受它的完整性感到紧张。考虑到git有多少种不同的使用方式，可能仍然存在允许删除代码的漏洞