gpt4 book ai didi

mercurial - 如何在 Mercurial DVCS 中实现提交策略

转载 作者:行者123 更新时间:2023-12-02 23:16:00 25 4
gpt4 key购买 nike

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

总之,这个想法是,存储库将有一个“集成”分支,不会直接在其上开发,而是任何工作都将在另一个分支上进行,完成后将 merge 到集成分支中 - 下面是一个粗略的示例,大括号中包含提交注释:

  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

“集成”分支只允许 merge 和标记。

这类似于我们在工作中进行开发的方式(在基于服务器的非 DVCS 系统上),您可以在工作分支上进行更改,完成后(并进行审查、测试……),您可以 merge 这些更改变更为集成分支,进行正式测试和发布。

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

我最初的想法是在 pre-commit 上添加一个钩子(Hook)(不是 precommitpretxncommit,如我相信当您创建标签时,这些会被解雇)。该钩子(Hook)将检查,如果您位于集成分支上,则有两个父级,这意味着这是 merge 的结果,如果不是这种情况,则会失败。

但是据我了解,当您克隆存储库时,不会复制 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 时工作流程的正确方法吗?

最佳答案

我认为您说过您想要一种“结构化的工作方式”,所以我想知道您是否正在寻找的是代码副官。这意味着门是从里面锁上的,只有中尉才能打开它,并且只有当中尉将其拉入时,代码才会到达中央存储库。已通过批准流程的代码将被拉入中央或权威存储库,这是一种“结构化的工作方式”。

通过谈论仅在存储库中拒绝写入分支,而不是拒绝写入整个中央存储库,在我看来,您几乎在问如何剥夺 DVCS 的 #1 伟大属性,即( a) 不只有一个副本,并且每个副本都可以有自己的读/写访问规则,如果您愿意,其中一个副本就是中心副本,并且 (b) 提交与造成影响是分开的他们对其他任何人。提交是本地工作副本操作。直到这些提交到达权威存储库(无论是中央存储库还是由您的代码管理员管理的存储库)时,您才可以在这个受控流程下使用 DVCS 进行真正的更改。

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

简而言之,你可以说,每台本地机器的工作副本都是一个分支,一个不可见的分支,不会对任何人造成影响,甚至不会被命名,直到由将进行代码审查和集成测试的中尉轮询为止。整个变更集,其功能相当于 CVCS 中的“功能分支”。那些不可见的分支都是可写的,而中央仓库(不是分支,单独的 REPO)由于其设置方式而只能读取;用户可以从中同步,但不能推送到它,除非中尉将新的更改拉入其中。基本稳定,但还是大家都能完成工作。

关于mercurial - 如何在 Mercurial DVCS 中实现提交策略,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6371819/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com