Question

对于小型软件开发，我希望更改遵循已定义的过程，即集成分支仅包含“完整”更改。这个想法源于我的博客上关于从Mercurial获取useful history logs的帖子。然而，这不仅仅是关于生成日志，而是关于结构化的工作方式。

总之，这个想法是存储库将有一个“集成”分支，不会直接开发，而是任何工作将在另一个分支上执行，并且当完成将合并到集成分支 - 下面是一个粗略的例子，在大括号中提交注释：

  O   {Implemented new feature X}
  |\
  | O {...}
  | |
  | O {...}
  |/
  O   {Fixed bug 002}
  |\
  | O {...}
  |/
  O   {added tag "Release 1.0"}
  |
  O   {Fixed bug 001}
  |\
  | O {...}
  |/
  O  -- integration branch
 /
O  -- default branch

“整合”分支只允许合并和标记。

这类似于我们在工作中进行开发的方式（在基于服务器的非DVCS系统上），您在工作分支上进行更改，并在完成（并经过审核，测试......）时将这些进行合并更改为集成分支，用于正式测试和发布。

无论如何，我的问题是 - 我如何强制执行仅在工作分支上进行更改的策略，而在集成分支上我们只允许合并或标记？

我最初的想法是在pre-commit上添加一个钩子（不是 precommit或pretxncommit，因为我相信当你这样做时会被解雇创建一个标签）。钩子会检查，如果你在集成分支上，有两个父节点，这意味着这是合并的结果，如果不是这样，则会失败。

但据我了解，克隆存储库时不会复制挂钩。由于这是项目特定的设置，因此不应在用户级设置。那么我如何阻止用户克隆存储库（从而丢失钩子），直接在集成分支上进行更改，然后推送？

hg clone main_repo
hg update integration_branch
(make changes without starting a new branch)
hg commit -m "I made some changes"
hg push

另外，在使用Bitbucket等系统时如何强制执行此操作？

或者，这不是使用DVCS时工作流程的正确方法吗？

Answer 1

我认为你说你想要一种“结构化的工作方式”，所以我想知道你所寻找的是代码中尉。这意味着门是从内部锁定的，只有中尉打开它，代码才能击中中央仓库，只有当中尉把它拉进去时。经过批准程序的代码被拉入一个中央或权威的存储库，这是一种“结构化的工作方式”。

通过谈论仅仅在回购中拒绝写入分支，而不是拒绝写入整个中央回购，这对我来说几乎就像你在问你怎么能拿掉DVCS的＃1伟大属性， a）不只有一个副本，并且每个副本都有自己的读/写访问规则，如果您愿意，其中一个副本是中心副本，并且（b）提交与冲突分开他们在其他人身上。提交是本地工作副本操作。直到这些提交到达权威存储库，无论是中心存储库还是由代码管理员管理的存储库，您甚至在此受控流程下使用DVCS进行了真正的更改。

或者您是否认为用户甚至不应该在没有分支的情况下进入自己的DVCS本地实例？

简而言之，你可以说，每个本地机器的工作副本都是一个不可见的分支，不会对任何人造成任何影响，甚至不会被命名，直到由将要进行代码审查的中尉进行轮询，并进行集成测试整个变更集，在功能上等同于您在CVCS中称为“功能分支”的功能。那些不可见的分支都是可写的，中央回购（不是分支，单独的REPO）只能通过它的设置来读取;用户可以从中同步，但不能推送到它，除了向其中提取新变化的中尉。基本稳定，但仍然每个人都可以完成工作。

Answer 2

如果您可以访问中央存储库hgrc，则可以定义pretxnchangegroup挂钩，验证集成分支上的传入变更集是否有2个父节点（而第一个必须位于集成分支上））。 AFAIK，在Bitbucket上你只能使用brokers设置后检查。这些经纪人不会阻止任何不必要的推送，但如果有人不遵守规则，可能会通知您。

然而，我个人第二次@ Zhehao的评论，即只是试图让每个人都遵守规则，让那些打破他们的咖啡给同事喝咖啡一周（或者说，你得到它）。

最后，您可以维护一些共享的hgrc和相应的钩子，每个开发人员必须在她的系统上设置（一次）。如果在系统上全局设置，则无需为每个克隆再次设置它们。

如何在Mercurial DVCS中强制执行提交策略

2 个答案: