Mercurial 最佳实践 - 功能/任务分支？
我刚刚从 SVN 切换到 Mercurial。我已经完成了一些基本的工作（导入代码、进行提交、掌握日志/提交/恢复等）并阅读了一些有关分支/合并的教程。
我现在的问题是：使用 Mercurial 的最佳（“Mercurial”）方式是什么？”我不想遵循 SVN 范例；我想以“正确”的方式做事。
我应该提到我是大多数项目的唯一开发人员，并且我正在使用敏捷/Scrum 实践，也许我的问题实际上应该是我应该根据任务进行克隆/分支吗？ 我记得。读到这应该是 Git 的情况，这允许您本质上保持多个副本同时工作，并将功能与错误修复与其他任何东西分开（即为您正在处理的每个不同的事物保持单独的工作副本）这显然也是 Mercurial 最佳实践的一部分
。一份副本，进行更改，然后大量提交。无论如何，
如果这个问题太主观，我不介意关闭它，只要有人可以将我链接到一些关于如何最好地使用 Mercurial 的阅读材料。 。这就是我所追求的。
I just switched to Mercurial from SVN. I've done some basic stuff (importing my code, making commits, getting the hang of log/commit/revert/etc.) and read some tutorials on branching/merging.
My question now is: What's the best ("Mercurial") way to use Mercurial?" I don't want to follow SVN paradigms; I want to do things the "right" way.
I should mention that I'm a sole developer on most of my projects, and I'm using agile/scrum practices. Maybe my question should really be should I be cloning/branching per feature? Per task? I remember reading that this should be the case for Git, and this allows you to essentially keep multiple copies working at the same time and separate features vs. bug-fixes vs. whatever (i.e. keep your working copy separate for each different thing that you're doing). And it's also apparently part of Mercurial's best practices.
Or I could just keep one copy, make my changes, and commit prolifically. Whatever.
If this question is too subjective, I don't mind closing it, provided someone can link me to some reading materials on how to use Mercurial best. That's what I'm after.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
作为一名（大部分）独立开发者，我想我的答案是……是的。当我知道我正在进行快速更改时，我会在“主”开发目录中进行更改，但如果我对某些内容的长度/复杂程度有任何疑问，我会从一开始就进行分支。令人高兴的是，您确实可以以任何适合您的方式（以任何顺序）进行操作。如果您正在一个较长的 mod 上的主开发目录中工作，并且有人进来并且现在需要快速修复，只需克隆主干，修复它，签入它，鲍勃就是您的叔叔！
我悲伤地回顾我在 SCCS/RCS/CVS 的日子。
我即将带领三位设计师进入应许之地。他们是老派，多年来一直在共享目录中使用 Dreamweaver（太恐怖了！）。本周末，我们将把它们转移到 XAMPP、TortiseHG、rsync 和开发/登台/生产的世界。
更新：我以一种非常含糊的方式表达了我的答案。感谢您给我打电话，Michael E。
我的“主开发目录”实际上是 Production-master 的克隆。当我说“分支”时，我的意思是我将在某件事上工作一段时间，通常是几天到一个月或更长时间，但它仍然是“某件事”的克隆。我知道这听起来很模糊，但有时我正在与其他开发人员合作，我们会来回传递东西，我们只是不太担心合并到主干，直到需要进行登台为止。 （即使如此，它通常也很轻松。）
因此，对我来说，“快速修复”意味着将我的“主”开发目录更新到主干、黑客攻击、测试、推送到主机上的暂存（和测试），然后推送到生产环境（和测试）。大多数时候，快速修复是作为匿名分支完成的。
顺便说一句，克隆本地存储库是如此之快，没有理由（在我看来）做任何其他事情。我有一个中等规模的项目，包含超过 7,000 个文件，并且有 4 名开发人员在大约 4 年的时间里几乎每天都会提交——存储库大约有 200MB。克隆时间（在我车库里一台又旧又慢的机器上）是 10 秒。我保留远程生产主机的本地克隆，并使用 cron 每小时进行一次获取。 HTH。
Speaking as a (mostly) solo developer, I think my answer is ... yes. When I know I'm making a quick change I do it in my "main" development directory, but if I have any doubt about how long/complicated something will be, I branch right at the beginning. The nice thing is that you can really do it in any way (and in any order) that works for you. If you are working in your main dev directory on a longish mod and someone comes in and needs a quick fix now, just clone trunk, fix it, check it in, and Bob's your uncle!
I look back on my days with SCCS/RCS/CVS with sadness.
I am about to lead 3 designers into the Promised Land. They are old-school and have been using Dreamweaver in shared directories (the horror!) for years. This weekend we are moving them to a world of XAMPP, TortiseHG, rsync, and deve/staging/production.
Update: I phrased my answer in a highly ambiguous way. Thanks for calling me on it, Michael E.
My "main development directory" is actually a clone of production-master. When I say "branch" I mean that I'm going to be working at something for a while, often for several days to a month or more, but it's still a clone of "something." I know that sounds vague, but sometimes I'm working with other developers and we are passing stuff back and forth and we just don't worry too much about the merge to trunk until it's time to go to staging. (And even then it's often pretty painless.)
So a "quick fix" for me means updating my "main" dev dir to trunk, hacking, testing, push to staging on the main machine (and test), and then push to production (and test). Most of the time quick fixes are done as an anonymous branch.
BTW, cloning against a local repository is so fast there's no reason (in my mind) to do anything else. I have one medium-ish project with something over 7,000 files and about 4 years of near-daily commits from 4 developers -- the repository is about 200MB. Clone time (on an old-and-slow machine in my garage) is 10 seconds. I keep an local clone of the remote production master and do hourly fetch'es with cron. HTH.
基本指南：
https://www.mercurial-scm.org/guide/
有关分支的指南：
http://stevelosh.com/blog/2009 /08/a-guide-to-branching-in-mercurial/
我更喜欢 搁置以进行快速修复，匿名分支用于两到三个变更集更改，并克隆任何比这更大的内容。
Basic guide:
https://www.mercurial-scm.org/guide/
A guide on branching:
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
I prefer shelving for quick fixes, anonymous branches for two-to-three changeset changes, and cloning for anything bigger than that.
请点击此链接。 http://hginit.com/
Joel Spolsky 清楚地解释了传统集中式 VCS 和 DVCS 之间的区别。
他还从颠覆背景指导您完成熟悉 Mercurial 工作流程的步骤。
Follow this link. http://hginit.com/
Joel Spolsky clearly explains the difference between legacy centralized VCS and a DVCS.
He also guides you through the steps to get acquainted to the mercurial workflow, coming from the subversion background.
我发现在某些情况下命名分支比克隆更好。如果项目设置未签入源代码管理，则克隆需要我将这些设置复制到我的所有克隆。我的大部分工作都是在 Django 中进行的，其中
local_settings.py不在源代码管理中是一种常见的习惯用法。我还发现共享克隆并不像共享命名分支那么容易。如果我是唯一开发某个功能的开发人员，那么克隆就可以了。第二个我需要有人帮助我完成某个功能时，命名分支将是更好的选择。@k3b 提到了 gitflow，并且有一个正在开发的 hg 插件可以在 hg 中使用命名分支执行相同的操作。 https://bitbucket.org/yinwm/hgflow/wiki/Home
I have found named branches to be preferable to cloning for a couple of cases. If have project settings that are not checked into source control them cloning requires me to copy these settings around to all of my clones. Most of my work is in Django where having a
local_settings.pynot in source control is a common idiom. Also I find that sharing clones is not as easy as sharing named branches. If I'm the only developer working on a feature then cloning is fine. The second I need someone to help me on a feature a named branch would have been the better choice.@k3b mentioned gitflow and there is a hg plugin in development to do the same thing in hg which uses named branches. https://bitbucket.org/yinwm/hgflow/wiki/Home
不。我会克隆功能分支的工作目录/存储库，而不是分支。
我遵循 a-successful-git-branching-model。
请注意，引用的文章是针对 git 的，而不是针对 hg 的。然而，分支模型是通用的，只是 git 和 hg 之间的语法不同。
[更新2013-01-31]
感谢@Alex 的评论。我不知道 hg 和 git 之间的差异。是否有人具有 hg 经验，可以验证 git 分支模型是否适用于 hg 或需要修改才能与 hg 一起使用（命令行语法除外）？
No. Instead of a branch i would clone the working directory/repository for a feature branch.
I am following the excelent descrition in a-successful-git-branching-model.
Note the referenced article is for git not for hg. However the branching model is universal just the syntax between git and hg differ.
[update 2013-01-31]
Thanks @Alex for your comment . i was not aware of the differences between hg and git. Is there somebody out there with hg experience that can verify that the git branching modell is applicable to hg or needs modificatoins to work with hg (excpet the commandline syntax)?