适用于约 15 名开发人员的 Mercurial 工作流程 - 我们应该使用命名分支吗？
我的团队刚刚开始使用 Mercurial 和中央存储库。我们让 Hudson 构建“默认”分支的尖端 - 这基本上是我们的主线。我们对旧的 VCS 有一项签入政策，即必须在签入主线之前完成代码审查、测试等。
因此，假设您正在开发功能 X。您基于“默认”开发一些内容，然后提交部分功能作为检查点。在本地，您的“默认”现在已被破坏 - 您尚未与任何人共享它，但如果您要进行推送，那么现在您在主线中的代码已损坏。
即使你等到把所有事情都解决之后再推动，似乎在某些情况下（例如同时处理两件事）你需要推动一些更改，但不是全部。
此外，如果您签入所有检查点更改，那么主线中将会有一些构建的修订，而主线中的其他修订则不会构建。
我们已经开始使用命名分支 - 但我读得越多，我就越认为我们错误地使用了命名分支。
关于如何设置一个良好的工作流程，让我们能够运行 Hudson 并保持我们的主线策略，有什么建议吗？
My team's just starting out with Mercurial and a central repository. We have Hudson building the tip of the "default" branch - which is basically our mainline. We had a check-in policy with our old VCS that code reviews, testing, etc. must be done before you check-in to the mainline.
So, let's say you are working on feature X. You work on some stuff, basing it off of "default", and then you commit a partial feature as a checkpoint. Locally your "default" is now broken -- you haven't shared it with anyone yet, but if you were to do a push, well now you've got broken code in mainline.
Even if you wait to push until you've got it all sorted out, it seems like there are situations (e.g. working on two things at once) where you'd need to push some changes but not all.
Additionally, if you check in all your checkpoint changes, then there will be some revisions in mainline that build, and others in mainline that don't build.
We have started using named branches - but the more reading I do the more I think we're mis-using named branches.
Any suggestions on how to setup a good workflow that allows us to run Hudson and keep our mainline policy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
首先，我强烈推荐 Mercurial 分支指南
接下来，您可以仅推送当前分支：轻推 - 温和版本的推送
也许您可以决定只允许每个分支一个头：32。防止会创建多个头的推送
与命名分支相关的其他 SO 问题：
First, I highly recommend A Guide to Branching in Mercurial
Next, you could push just the current branch: Nudge - A Gentler Version of Push
And maybe you could decide to allow only a head per branch: 32. Prevent a push that would create multiple heads
Other SO questions related to named branches:
您可以考虑至少两个存储库。 “主线”存储库包含您经过测试和审查的代码。只有在 Hudson 对其进行测试并且完成您所做的任何审核之后，代码才会被推送到此存储库。 “测试”存储库将是主线的克隆。这是 Hudson 监控的存储库，因此每当将变更集推送到测试存储库时，Hudson 都会进行测试。您可以设置一个 Hudson 构建步骤，如果测试通过，则将更改从测试存储库推送到主线。
开发人员总是推送到测试存储库，但只从主线拉取，因此他们只拉取经过测试的代码。如果他们需要共享未经测试的变更集，他们可以直接在彼此的本地存储库之间推送/拉取。也许可以将 Hg 配置为使主线仅接受来自测试存储库的推送，这样开发人员就不会意外地推送到主线而不是测试。
拥有一个评论存储库可能也很好。因此开发人员推送测试，Hudson 推送测试过的代码进行审查，然后将审查过的代码推送到主线。
免责声明：我只在琐碎的项目中以琐碎的方式使用过汞。
You might consider at least two repositories. The "mainline" repository has your tested and reviewed code. Code is only pushed to this repository after Hudson has tested it and after whatever reviews you do have been completed. The "testing" repository would be a clone of the mainline. This is the repository that Hudson monitors, so that whenever a changeset is pushed to the testing repository, Hudson tests is. You can probably set up a Hudson build step that pushes changes from the testing repository to your mainline if the tests pass.
Developers always push to the testing repository, but only pull from the mainline, so they only ever pull in tested code. If they need to share untested changesets, they could push/pull directly between each other's local repositories. Maybe it is possible to configure Hg to so that the mainline only accepts pushes from the testing repository, so that developers can't accidentally push to mainline instead of testing.
It might be good to have a review repository as well. So developers push to testing, Hudson pushes tested code to review, and then reviewed code is pushed to mainline.
Disclaimer: I have only used Hg on trivial projects and in trivial ways.
我们在我的公司所做的是使用命名分支来区分稳定版本（我们只提交错误修复）和进行开发的下一个版本，并且我们定期将修复从稳定版本反向移植到默认版本（使用
hg merge stable在默认分支上）。对于代码审查，我们使用 mq 扩展来使开发人员能够提交干净的补丁。开发人员可以从彼此的存储库中提取内容，而不会污染参考存储库。
免责声明：我们不使用 Hudson。
What we do in my company is use named branch to distinguish the stable version (on which we only commit bug fixes) and the next version on which the development happens and we backport fixes from stable to default on a regular basis (with
hg merge stableon the default branch).For code review we use the mq extension to enable the developers to submit clean patches. And developers can pull from each others repositories, without polluting the reference repository.
Disclaimer : we don't use Hudson.
这是一个心态问题。分布式 VCS 不需要您保留单个中央存储库。
不要将主线开放给所有人查看，而是将其设置为具有有限的写入访问权限。只有已批准（测试、签署、任何对您有意义的内容）的变更集才会合并到主线中。
如何管理将更改纳入主线是一个广泛开放的问题，有许多可能的答案。以下是我想到的两个：
It's a question of mindset. The distributed VCSes don't require you to keep a single central repository.
Rather than having mainline open to all to check into, set it up with limited write access. Only changesets which have been approved (tested, signed off, whatever makes sense for you) are incorporated into mainline.
How you manage getting changes into mainline is then a wide open question with many possible answers. Here are two off the top of my head:
您还可以考虑使用 书签 扩展而不是命名分支。
如果您熟悉 git，书签的行为就像 git 分支而不是 Mercurial 分支。
You could also consider using the Bookmarks extension instead of named branches.
If you're familiar with git, bookmarks behave like git-branches instead of mercurial branches.