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

对于小型软件开发，我希望进行更改以遵循定义的过程，从而使集成分支仅包含“完整”更改。这个想法源自我的博客上的一篇关于从Mercurial获得useful history logs的文章。然而，这不仅仅是生成日志，而是关于一种结构化的工作方式。如何在Mercurial DVCS中执行提交策略

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

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时，这不是正确的工作流程方法吗？

来源

2011-06-16 icabod

难道你不能让每个人都同意不对集成分支进行更改吗？ – 2011-06-16 12:34:42

是的，当然这是一种选择，但我更多地考虑阻止意外更改等事情......这意味着您可以进行更改，但是除非您完成了'hg branch newbranch'，否则提交将失败。 – icabod 2011-06-16 13:35:04

我认为你的评论更多关于Mercurial，所以它的主题行听起来会更好，因为“如何在Mercurial DVCS中强制执行提交策略” – bialix 2011-06-16 19:12:27

我想你说你想要一个“结构化的工作方式”，所以我不知道你在找什么，而是代码中尉。这意味着门从里面被锁住了，只有中尉打开门，代码才打到中央回购站，只有当中尉拉进去时。已经通过您的审批流程的代码被拉入中央或权威的存储库，这是一种“结构化的工作方式”。

通过谈论否认只写在回购中的分支，而不是拒绝写入整个中央回购库，这听起来对我来说几乎就像你问你如何拿走DVCS的＃1伟大的属性，这（a）不只有一个副本，并且每个副本都可以有自己的读/写访问规则，如果你愿意，副本中的一个副本是中央副本，并且（b）提交是独立的将他们强加给其他人。提交是本地工作复制操作。直到这些提交到权威仓库，无论是中央仓库还是代码管理者，您甚至可以在这个受控过程中使用DVCS进行真正的更改。

或者你是否认为用户甚至不应该承诺自己的工作DVCS本地实例，没有分支？

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

来源

2011-06-17 02:06:00

尽管这是一个很好的工作流程（对于这个问题而言是一个合理的解决方案），但它并没有使技术规定（例如通过挂钩）完全过时。如果开发者自己处于早期状态，即他们承诺或推动时，认识到他们违反了工作流规则，那么代码中尉不必处理意外中断的规则，但可以专注于更复杂的问题。 – 2011-06-17 08:01:03

我认为把这些结合起来的一个好方法是让代码钩子自动生成提交到中央仓库的提交，然后可以将其标记为“通过烟雾测试”或其他任何方式，或者您甚至可以对构建，用于标记构建为良好，作为整合的一部分。但是如果你实际上阻止了提交，你就会阻止工作。块集成移动（拉/推），不提交。 – 2011-06-17 17:26:20

接受的答复。我认为这已经引导我远离钩子的想法，而是允许每个克隆的repo作为它自己的分支（毕竟这是Mercurial作为DVCS的一种方式）。将中央仓库设置为只支持也是一个不错的主意 - 将其与诸如bitbucket之类的服务相结合，可能可以通过让用户可以使用的分支来实现，而主仓库只能由中尉推动。 – icabod 2011-06-21 10:33:36

如果您有权访问中心回购的hgrc，您可以定义一个pretxnchangegroup挂钩，以验证集成分支上的传入更改集有两个父级（而第一个必须位于集成分支上）。 AFAIK，在Bitbucket上，您只能使用brokers设置后检查。这些经纪人不会阻止任何不必要的推动，但如果有人不遵守规则，可能会通知您。

但是，我个人对@ Zhehao的评论，即试图让每个人都遵守规则，让那些违反规定的人在一周内为同事提供咖啡（或者你明白了）。

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

来源

2011-06-16 13:01:09

对于共享的hgrc，您还可以在钩子中检查当前回购库中初始提交的哈希/标识if你只希望钩子适用于特定回购的克隆。 – 2011-06-17 00:09:44

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

回答

相关问题