我读过SO，官方的Hg指南，许多文章和指南的类似帖子，目前还不清楚什么是通过功能进行开发的最佳Hg工作流程。也许网络上的一些文章已经过时了几年，并没有包含汞的最新功能。显然，如何解决这个问题也有很多选择。Mercurial per feature工作流程，单个开发人员
我是一个独立开发人员，负责处理某个修复或功能请求作为任务提交给我的项目，例如“任务＃546 - 更改任何内容”。其中一些任务需要几天时间，有些任务可能需要几个月才能完成，一次通常需要多达十几个任务。在请求者批准后，任务将被运送到最终的网站。
汞指南似乎建议有一个克隆每个功能。但是，我的驱动器上有十几个完整的网站副本似乎......浪费？我正在尝试它，但我看到了其他更有意义的建议。每个人的开发机器上的每个站点一次真的有十几个副本吗？
名称分支最初听起来像我想要的，我在哪里命名分支“任务546”在它上面工作，然后在它发货时将其合并回来。我看到很多关于名称永久性的讨论，并且有很多分支（尽管它们可以关闭）。有些人似乎关心这一点，有些人却不关心。我不知道汞是否足以知道我是否在意，以及缺点是什么意思。
最后，书签似乎很受最近的文章的欢迎，看起来使用它们的最好方法是设置一个书签，如“任务546”，然后当您将它合并回主分支时使用提交具有任务编号的消息，以保持对工作中正在进行的操作的引用。我知道你可以删除书签，但目前还不清楚在最终合并后是否需要这样做。
所以我对相结合的办法想到的就是有：
一个回购
三个已命名的分支：
- “默认”持有该网站的发布版本
- “ dev“，我在其中进行功能开发
- ”测试“，它将保存客户正在审阅的所有任务
我的工作流任务/功能会于：
- 更新的“开发”为主线的命名分支
- 开始使用该任务的书签“任务＃123”一个新的分支
- 提交更改，直到我准备好了客户回顾
- 合并“任务＃123”到“测试”分支
- 部署“测试”测试服务器
- 重复提交，合并，部署，直到准备生产
- 一旦获得批准，合并与主线包含任务名称的提交消息的“dev”分支的合并“
- 将”dev“合并到”默认“分支中。
- 部署的“默认”分支直播服务器
- 合并“默认”进入开放特性分支
的思考？对于每个功能都有一个克隆，以及我推动的“实时”和“测试”回购，我会更好吗？
编辑：我从一些链接看到，我应该从“默认”开发，所以我第一次更改到我列出的过程将是使用名称“生产”分支，而不是命名的“开发”分支。
既然你问“我会过得更好......”，那么它就意味着有一种方法可以量化一种解决方案比另一种更好。您提出的解决方案是否有效？是的，它确实。它会缩放吗？根据[this]（http://stackoverflow.com/a/9170497/267），是的。 –
量化一种解决方案是否优于另一种解决方案的一种方法是经历所有需要的事情，以确保您的代码持久，良好等。如果您在本地有十几家分支机构，那么使用特定任务，因为您必须手动选择合适的文件夹（克隆）才能使用。但是，您是否可以确保所有这些克隆都能在磁盘崩溃后继续存在？另一方面，如果您使用普通分支机构或书签（同步到中央回购站），即使您的机器被盗，丢失或完全冲洗，您仍然会一切。我会使用分支/书签。 –
@ LasseV.Karlsen，对我来说“更好”是1）我的代码安全并且易于使用，2）它是高效的流程，并且极少容易出错。大多数情况下，我确信我正在尝试做的事情相当普遍，其他人以相同的方式工作，可能已尝试过几种工作流程方法，并对最适合他们的工作方式有一些反馈意见。 –