4

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

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

  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我最初的想法是在( not precommit or上添加一个钩子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 时工作流的正确方法吗？

4

2 回答 2

2

我想你说你想要一种“结构化的工作方式”，所以我想知道你正在寻找的是否是代码副手。这意味着门是从里面锁上的，只有副手打开它，代码才会到达中央仓库，只有当副手把它拉进来的时候。已经通过你的批准过程的代码被拉到一个中央或权威的仓库中，这是一种“结构化的工作方式”。

通过谈论仅在 repo 中拒绝写入分支，而不是拒绝写入整个中央 repo，在我看来，这听起来几乎就像您在问如何才能带走 DVCS 的 #1 伟大属性，其中 (a)不只有一个副本，每个副本都可以有自己的读/写访问规则，如果您愿意，其中一个副本是中央副本，并且（b）提交与将它们施加于任何人是分开的别的。提交是本地工作副本操作。直到这些提交到达权威存储库，无论是中央存储库还是由您的代码管理员管理的存储库，您甚至在这个受控过程下使用 DVCS 进行了真正的更改。

或者您是否认为用户甚至不应该在不创建分支的情况下提交到他们自己的工作 DVCS 本地实例？

简而言之，你可以说，每台本地机器的工作副本都是一个分支，一个不可见的分支，不会对任何人造成影响，甚至不会被命名，直到将进行代码审查和集成测试整个变更集的副手轮询它，这在功能上等同于您可能在 CVCS 中所谓的“功能分支”。那些不可见的分支都是可写的，而中央仓库（不是分支，单独的 REPO）是只读的，取决于它的设置方式；用户可以从中同步，但不能推送到它，除了将新更改​​拉入其中的副手。基本稳定，但仍然每个人都可以完成工作。

于 2011-06-17T02:06:00.903 回答
1

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

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

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

于 2011-06-16T13:01:09.510 回答