限制推送内容避免意外推到开发部门

Question

(这是我的earlier question关于如何在cvs中管理标准开发和特定客户开发的后续问题。)

我们在mercurial中使用不同的分支来区分标准开发(标准软件的开发)和特定于客户的开发(开发特定于客户的标准软件)。

那么，假设我们有以下分支：

• 默认(标准开发分支)
• 修订1.0(用于修复错误的标准开发分支)
• 修订1.1(用于修复错误的标准开发分支)
• customerA (修改后的版本1.0中的一个克隆)

当客户A想从1.0升级到1.1时，我们只需从Revsion1.1升级到customerA (并解决合并冲突)。到现在为止还好。

我想避免的是，开发人员不小心将一些特定于客户的代码合并到标准开发分支中。我们可以通过它的Java命名空间识别“特定于客户的代码”。

有办法这样做吗？

编辑:将“推送”改为“合并”，因为这是正确的术语

Answer 1

您可以阻止开发人员将错误提交或合并到“中心”存储库，但不能阻止他们在本地执行这些操作。例如，您可以使用一个pretxnchangegroup钩子来确保push不会导致revision1.0分支(或克隆)中特定于客户的代码，但这只会拒绝开发人员的推送。他(她)仍然会在当地做出错误的承诺，并且需要解开它。

上面的评论有些混乱，因为你在混淆术语。一个将事物合并在(命名)分支之间，并在存储库之间推送事物。

Answer 2

这并不是问题的真正答案，但是如果你使用分支而不是克隆，那么，在我看来，这个问题不值得担心。

只要开发人员使用分支名称而不是修订号合并分支，并且客户分支的分支命名与其他分支相当不同，就很难有人意外地进行“hg合并自定义”。我们(由12名开发人员组成的团队)已经有了类似的分支策略运行了几年，还没有有人意外地合并错误的分支。

在罕见的情况下，它确实发生，它通常会在一个小时或两个小时内解决与反向提交。而且，由于您似乎没有将customerA合并回任何东西，您甚至可以对该分支执行反向提交，以使更改返回。

Answer 3

您可以通过不允许所有上的推送来防止意外的推送。假设main (可能是"team")存储库有一些明智的管理员，您可以依赖于使用专用的拉请求。这可以防止任何推送，并且只有主回购的管理员才有权把东西拉到主回购中。或者--如果事情看起来不是可以接受的--拒绝它。

Pieter建议使用专用的存储库(每个目的只进行一次回购，这样一个回购就可以扮演一个分支的角色)。他创建这个组织的原因之一就是为了防止被推到回购中而造成的意外混乱。参见http://hintjens.com/blog:24中的“冲突中的健壮性”和“隔离的保证”。

请注意，这似乎更适合使用git然后Mercurial，因为Mercurial会将分支名称烧录到提交中，因此您没有那么自由地使用它们。