对于小型软件开发，我希望更改遵循定义的过程，其中集成分支将仅包含“完整”更改。这个想法源于我博客上关于从 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 上添加一个钩子(Hook)( 而不是 precommit 或 pretxncommit ，因为我相信这些会在您创建标签时被触发)。钩子(Hook)会检查，如果你在集成分支上，有两个父节点，这意味着这是合并的结果，如果不是这样，则失败。但是，据我所知，克隆存储库时不会复制钩子(Hook)。由于这将是特定于项目的设置，因此不应在用户级别进行设置。那么我如何阻止用户克隆存储库(从而丢失钩子(Hook))，直接在集成分支上进行更改，然后推送？
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 时正确的工作流程方法吗？
最佳答案
我想你说你想要一种“结构化的工作方式”，所以我想知道你正在寻找的是代码中尉。这意味着门是从里面锁上的，只有中尉才能打开它，只有当中尉拉进来时，代码才会命中中央存储库。经过您批准过程的代码被拉入中央或权威存储库，这是一种“结构化的工作方式”。
通过谈论仅在 repo 中拒绝写入分支，而不是拒绝写入整个中央 repo，在我看来，这听起来几乎就像您在问如何取消 DVCS 的 #1 伟大属性，这 (a)不仅有一个副本，而且每个副本都可以有自己的读/写访问规则，如果您愿意，其中一个副本是核心副本，并且 (b) 提交与对任何人施加它们是分开的别的。提交是本地工作副本操作。直到这些提交到达权威存储库(中央存储库或由您的代码助理管理的存储库)之后，您才在此受控过程中使用 DVCS 进行了真正的更改。
或者您是否认为用户甚至不应该在不创建分支的情况下提交到他们自己工作的 DVCS 本地实例？
简而言之，你可以说，每台本地机器的工作副本都是一个分支，一个不可见的分支，不会影响任何人，甚至不会被命名，直到由将进行代码审查和集成测试整个变更集的中尉轮询，这在功能上等同于您可能在 CVCS 中称为“功能分支”的内容。那些不可见的分支都是可写的，中央repo(不是分支，单独的REPO)只能凭借其设置方式读取；用户可以从中同步，但不能推送到它，除了将新更改拉入其中的中尉。基本稳定，但仍然每个人都可以完成工作。
关于mercurial - 如何在 Mercurial DVCS 中执行提交策略，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6371819/