我已经阅读过类似的 SO、官方 Hg 指南、许多文章和指南的帖子，但我仍然不清楚按功能开发的最佳 Hg 工作流程是什么。也许网络上的某些文章已有多年历史，并且不包含 Hg 的最新功能。显然，在如何处理它方面也有很多选择。
我是一名独立开发人员，正在从事一个项目，其中修复或功能的请求将作为任务提交给我，例如“任务 #546 - 更改任何内容”。其中一些任务需要几天时间，有些任务需要几个月的时间，而且通常一次要完成十几个任务。在请求者批准后，任务将被运送到最终站点。
Hg 指南似乎建议每个功能都有一个克隆。但是在我的驱动器上拥有该网站的十几个完整副本似乎......浪费？我愿意尝试，但我看到了其他更有意义的建议。人们真的在他们的开发机器上同时拥有每个站点的十几个副本吗？
起初命名分支听起来像我想要的，我会在哪里命名一个分支“任务 546”在它上面工作，然后在它发布时将它合并回来。我看到很多关于名称的永久性和有这么多分支的讨论（尽管它们可以关闭）。有些人似乎关心这一点，而有些人则不关心。我对 Hg 了解得不够多，无法知道我是否关心，以及缺点的真正含义。
最后，书签似乎在最近的文章中很受欢迎，使用它们的最佳方法似乎是设置一个像“task 546”这样的书签，然后当你使用提交消息将它合并回主分支时其中的任务编号，以保持对工作中正在完成的工作的引用。我知道您可以删除书签，但不清楚在最终合并后是否需要这样做。
所以我对组合方法的想法是：
一个回购
三个命名分支：
- “默认”保存网站的发布版本
- 我在其上进行功能开发的“dev”
- “测试”将保存客户正在审查的所有任务
在“开发”分支上，我会为我正在处理的每个任务使用书签，所以我对每个任务都有一个负责人
我的任务/功能工作流程是：
- 更新到名为“dev”的分支的主线
- 使用任务“task #123”的书签开始一个新分支
- 提交更改，直到我准备好让客户审查
- 将“task #123”合并到“test”分支
- 将“test”部署到测试服务器
- 重复提交、合并、部署，直到准备好生产
- 获得批准后，使用包含任务名称的提交消息与“dev”分支的主线合并
- 将“dev”合并到“default”分支中。
- 将“默认”分支部署到实时服务器
- 将“默认”合并到打开的功能分支中
想法？我是否最好为每个功能都有一个克隆，以及我推送的“实时”和“测试”存储库？
编辑：我从一些链接中看到我应该从“默认”进行开发，所以我对列出的流程的第一个更改是使用名称“生产”分支而不是命名“开发”分支。