在SCons项目中，我们使用mercurial和bitbucket。我们希望不同的人正在开发几个正在进行的功能（可能是多个人在处理单个功能，或者是一个人在处理多个功能）。我们尝试过命名分支，但它们在mercurial中的功能开发方面确实不太好用。我们喜欢像git branch系统这样的东西，分支的重量更轻，不是永久性的，但仍然是共享的。除了每个功能的单独回购，我不认为我们已经准备好（过于激进），社区似乎说书签是去这里的方式;在默认分支上进行所有开发，但每个头（功能）都有书签。
第一个问题：合理的工作流程是什么？是否有其他项目以这种方式运作？
第二个问题：尝试过这一点，有一件令人困惑的事情就是当你hg update default它是半随机的时候，你会得到它;这取决于最后更新的是哪一个。你真的必须做hg update featureX或hg update featureY或者（a）你落在一个随机的头上，（b）没有书签被激活＆＃34;所以你最终没有向前移动那个书签。这似乎是失败的秘诀。我想我错过了什么。任何人都使用这样的工作流程：你如何克服这个过程？
答案 0 :(得分：-2)
命名分支......它们在mercurial
中的功能开发中效果不佳
RLLY？我一直使用NB，很长时间都找不到任何问题。我做错了吗？
忘记（如果它发生了）推送一次--new-branch，获得拒绝并重复正确命令最低成本所有命名分支有用
社区似乎说书签是去这里的方式
这是一个合理的工作流程吗？
至少Steve Losh在“Mercurial分支指南”中note
是否有其他项目以这种方式运作？
为什么不呢？书签式在某些人眼中具有一些优势（在另一种情况下同时也有缺点）
当你
hg update default时，它是半随机的，你得到的是
只需完全忘记 hg up，使用branch-name或无参数，始终使用所需的书签名称进行更新。如果你的团队由记忆力较差的年轻女孩组成，他们可以用一两个aliases的形式制作拐杖。
在非绝望的情况下，它可能像
bup = update ACTIVE-BOOKMARK-NAME
ACTIVE-BOOKMARK-NAME是一个占位符，用于分配给用户书签（并且用户负责编辑.hgrc并在更改任务时替换书签），用户必须hg up才能更新为书签和hg up ANY以使用自由格式更新
对于金发女郎和代码猴子，你可以准备两个别名的集合，其中一个重载默认值hg up：严格不推荐
可以创建与现有名称相同的别名 命令，然后将覆盖原始定义。这是 几乎总是一个坏主意！
但可能，例如，f.e。
update = update ACTIVE-BOOKMARK-NAME
pup = update $1
I.e hg up | hg update没有参数用户只能更新为书签，因为（罕见）更新到任何其他变更集必须使用hg pup CSET-ID形式的新命令
理论上（未经测试），每个编码器都可以获得自己的唯一别名，可以使用Projrc Extension以{{3}}集中维护和部署到工作场所，使用特定于用户的{{1用于从中央存储库include