如何在 Mercurial DVCS 中实施提交策略
对于小型软件开发，我希望更改遵循定义的流程，其中集成分支将仅包含“完整”更改。这个想法源于我博客上关于获取有用的历史日志的帖子 来自 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 上添加一个钩子（不是 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 时工作流程的正确方法吗？
For a small software development I would like changes to follow a defined process, whereby an integration branch would contain only "complete" changes. The idea stems from a post on my blog about getting useful history logs from Mercurial. However this isn't just about generating logs, but about a structured way of working.
In summary the idea is that a repository would have an "integration" branch which would not be directly developed on, instead any work would be carried out on another branch, and when complete would be merged into the integration branch - below is a rough example, with commit comments in braces:
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
The "integration" branch would only allow being merged-to and tagged.
This is similar to how we do development at work (on a server-based non-DVCS system), where you make changes on your work branch, and when complete (and reviewed, tested, ...) you merge those changes into an integration branch, for formal test and release.
Anyway, my question is - how would I enforce the policy of making changes only on a work branch, while on the integration branch we only allow merging or tagging?
My initial thought is to add a hook on pre-commit (not precommit or pretxncommit, as I believe these get fired when you, for example, create a tag). The hook would check that, if you were on the integration branch, there are two parents, meaning this is the result of a merge, and fail if that wasn't the case.
However as I understand it, the hooks are not copied when you clone a repository. As this would be a project-specific setting it shouldn't be set at the user-level. So how would I stop a user from cloning the repository (thus losing the hooks), making changes directly on the integration branch, and then pushing?
hg clone main_repo
hg update integration_branch
(make changes without starting a new branch)
hg commit -m "I made some changes"
hg push
Also, how could I enforce this when using a system such as Bitbucket?
Alternatively, is this not the correct approach to a workflow when using a DVCS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想你说过你想要一种“结构化的工作方式”，所以我想知道你是否正在寻找的是代码副官。这意味着门是从里面锁上的，只有中尉才能打开它，并且只有当中尉将其拉入时，代码才会到达中央存储库。已通过批准流程的代码将被拉入中央或权威存储库，这是一种“结构化的工作方式”。
通过谈论仅在存储库中拒绝写入分支，而不是拒绝写入整个中央存储库，在我看来，您几乎在问如何剥夺 DVCS 的 #1 伟大属性，即 (a)不只有一个副本，并且每个副本都可以有自己的读/写访问规则，如果您愿意的话，其中一个副本就是中央副本，并且 (b) 提交与对任何人造成影响是分开的别的。提交是本地工作副本操作。直到这些提交到达权威存储库（无论是中央存储库还是由您的代码管理员管理的存储库）时，您才可以在此受控流程下使用 DVCS 进行真正的更改。
或者您是否认为用户甚至不应该在不创建分支的情况下提交自己的工作 DVCS 本地实例？
简而言之，您可以说，每台本地计算机的工作副本都是一个分支，一个不可见的分支，不会对任何人造成影响，甚至不会被命名，直到由将进行代码审查并对整个变更集进行集成测试的中尉进行轮询，它在功能上相当于 CVCS 中的“功能分支”。那些不可见的分支都是可写的，而中央仓库（不是分支，单独的 REPO）由于其设置方式而只能读取；用户可以从中同步，但不能推送到它，除非中尉将新的更改拉入其中。基本稳定，但还是大家都能完成工作。
I think you said you want a "structured way of working", and so I wonder if what you are looking for instead, is code lieutenants. That means that the door is locked from the inside, and only the lieutenant opens it, and code hits the central repo, only when the lieutenant pulls it in. Code that has been through your approval process is pulled into a central or authoritative repository, which is a "structured way of working".
By talking about denying write to a branch only in a repo, instead of denying write to the entire central repo, It sounds to me almost like you're asking how can you take away the DVCS's #1 great attribute, which (a) that there is not just one copy, and that each copy can have its own read/write access rules, one of those copies is the central one if you like it to be so, and (b) that commits are separate from inflicting them on anyone else. A commit is a local working copy action. It is not until these commits hit the authoritative repository, either the central one, or the one managed by your code lietenant, that you have even made a real change, under this controlled process, using DVCS.
Or are you thinking that users shouldn't even commit into their own working DVCS local instances, without making branches?
In short, you could say, each local machine's working copy IS A BRANCH, an invisible branch, not inflicted on anyone, or even named, until it is polled by the lieutenant who will do the code review, and integration test the entire changeset, which is functionally equivalent to what you might have called a "feature branch" in a CVCS. Those invisible branches are all writeable, and the central repo (not a branch, separate REPO) is read only by virtue of how it is set up; users can sync from it, but not push to it, except the lieutenant who pulls new changes into it. Fundamentally stable, but still everybody can get work done.
如果您有权访问中央存储库的
hgrc，则可以定义pretxnchangegroup挂钩，用于验证集成分支上的传入变更集有 2 个父级（而第一个必须位于集成分支上）。 AFAIK，在 Bitbucket 上，您只能使用经纪商设置事后检查。这些经纪人不会阻止任何不需要的推送，但可能会在有人不遵守规则的情况下通知您。然而，我个人赞同@Zhehao 的评论，即只是尝试让每个人都遵守规则，并让那些违反规则的人为同事提供一周的咖啡（大约一周，你明白了）。
最后，您可以维护一些共享的 hgrc 和相应的钩子，每个开发人员都必须在她的系统上设置（一次）。如果在系统上全局设置，则无需为每个克隆再次设置它们。
If you have access to the central repo's
hgrc, you could define apretxnchangegrouphook which validates that incoming changesets on the integration branch have 2 parents (while the first one must be on the integration branch). AFAIK, on Bitbucket you could only set up post-checks using brokers. These brokers do not prevent any unwanted pushes but may notify you in case someone did not follow the rules.However, personally I second @Zhehao's comment, i.e. just try to get everyone follow the rules and let those breaking them serve coffee to colleagues for one week (or so, you get it).
Finally you could maintain some shared
hgrcand corresponding hooks which every developer has to set up (once) on her system. If set globally on a system, there's no need to set them up again for each clone.