（这是我之前关于如何在 cvs中管理标准开发和客户特定开发的问题的后续问题。）
我们使用不同的分支mercurial来区分标准开发（我们的标准软件的开发）和客户特定的开发（我们标准软件的客户特定修改的开发）。
所以，假设我们有以下分支：
当客户 A 想要从 1.0 升级到 1.1 时，我们只需从revision1.1拉到customerA （并解决合并冲突）。到目前为止，一切都很好。
我要避免的是开发人员不小心将一些客户特定的代码合并到标准开发分支中。我们可以通过其 Java 命名空间来识别“客户特定代码”。
有没有办法做到这一点？
编辑：将“推送”更改为“合并”，因为这是正确的术语
您可以阻止开发人员将错误的提交或合并推送到您的“中央”存储库，但您不能阻止他们在本地执行这些操作。因此，例如，您可以使用pretxnchangegroup挂钩来确保推送不会导致revision1.0分支（或克隆）中的客户特定代码，但这只会拒绝开发人员的推送。他或她仍然会在本地有错误的提交，并且需要解开它。
上面的评论有些混乱，因为您混淆了术语。一个合并（命名的）分支之间的东西并在存储库之间推送东西。
这并不是问题的真正答案，但是如果您使用分支而不是克隆，那么，在我看来，这个问题不值得担心。
只要开发人员使用分支名称而不是修订号来合并分支，并且客户分支的分支命名与其他分支完全不同，那么有人很难意外地执行“hg merge customerA”。我们（由 12 名开发人员组成的团队）已经使用类似的分支策略运行了几年，并且还没有有人意外合并错误的分支。
在极少数情况下，它通常会在一两个小时内通过反向提交解决。而且由于您似乎没有将 customerA 合并回任何内容，您甚至可以在该分支上执行反向提交以恢复更改。
您可以通过根本不允许推送来防止意外推送。假设，主（可能是“团队”）存储库有一些明智的管理员，您可能依赖于使用专门的拉取请求。这可以防止任何推送，并且只有主仓库的管理员有权将内容拉入主仓库。或者 - 如果事情看起来不可接受 - 拒绝它。
Pieter Hintjens 提议使用专用存储库（每个目的一个 repo，因此一个 repo 可能扮演一个分支的角色）。他成立这个组织的原因之一就是为了防止由于推送到回购而造成的意外混乱。请参阅http://hintjens.com/blog:24中的“冲突中的稳健性”和“隔离保证” 。
请注意，这似乎更适合使用 git 然后 Mercurial，因为 Mercurial 将分支名称保留在提交中，因此您不能随意使用它们。