Mercurial每个功能工作流程，单个开发人员

Question

我已经阅读了SO的相关帖子，官方Hg指南，许多文章和指南，我仍然不清楚按功能开发的最佳Hg工作流程是什么。也许网上的一些文章已有数年之久，并未包含Hg的最新功能。显然，如何处理它也有很多选择。

我是一名处理项目的个人开发人员，其中将修复或功能的请求作为任务提交给我，例如“任务＃546 - 更改任何内容”。其中一些任务需要几天时间，有些任务会持续数月，而且一次最多只能执行十几项任务。在请求者批准后，任务将被运送到最终站点。

Hg指南似乎建议每个功能都有一个克隆。但是在我的驱动器上有十几个完整的网站副本似乎......浪费？我想尝试一下，但我已经看到了更有意义的其他建议。人们真的一次在开发机器上有十几个每个站点的副本吗？

首先将名称分支听起来像我想要的那样，我在哪里命名一个分支“任务546”，然后在它发布时将其合并。我看到很多关于名称的持久性和有这么多分支的讨论（尽管它们可以被关闭）。有些人似乎关心这一点，有些则不关心。我不知道Hg是否足以知道我是否关心，以及缺点是什么意思。

最后，书签似乎在最近的文章中很受欢迎，似乎使用它们的最佳方式是设置像“任务546”这样的书签然后当你使用提交将其合并回主分支时在其中包含任务编号的消息，以保留对工作中正在执行的操作的引用。我知道你可以删除书签，但目前还不清楚在最终合并后我是否需要这样做。

所以我想要采用综合方法：

一个回购

三个命名分支：

• “default”，其中包含已发布的网站版本
• “dev”，我在其上进行功能开发
• “测试”，其中包含客户正在审核的所有任务

在分支上的

我会为我正在处理的每个任务使用书签，所以我对每个任务都有一个负责人

我的任务/功能工作流程是：

1. 更新到“dev”命名分支的主线
2. 使用任务“任务＃123”
的书签开始新的分支
3. 提交更改，直到我准备好让客户审核
4. 将“任务＃123”合并到“测试”分支
5. 将“test”部署到测试服务器
6. 重复提交，合并，部署直到准备生产
7. 获得批准后，使用包含任务名称的提交消息与“dev”分支的主线合并
8. 将“dev”合并到“默认”分支。
9. 将“默认”分支部署到实时服务器
10. 将“默认”合并到开放功能分支

思考？我是否会更好地为每个功能制作一个克隆，以及我推送的“实时”和“测试”回购？

编辑：我从一些链接中看到我应该从“默认”开始进行开发，所以我对列出的进程的第一个更改是使用名称“production”分支而不是命名的“dev”分支。 / p>

Answer 1

书签风格的分支（类似Git的“分支”）在两种常见案例中效果不佳

1. 交叉任务在开发过程中合并
2. 时间倒车机，当你想看到“任务＃123的变化的整个历史”时（你可以直观地做，有些做鬼脸和跳跃，使用revsets）

虽然使用命名分支没有这样的问题，但顺便说一句，带有命名分支的工作流（并且只有默认分支作为聚合点）将不那么复杂且更符合逻辑

• 默认仅包含来自任务分支的合并集，默认的头部始终是“稳定版本”
• 指定分支机构的负责人是WIP;分支，合并为默认 - 完成（并由客户接受 - 见下文）工作
• 默认，合并到任务分支（在开发任务之后，在将任务分支合并到默认值之前）相当于您的“测试”：不影响主线，您可以测试功能的最终状态，集成到您的稳定应用程序中，显示结果给客户
• 通过将命名分支合并到默认
，将已接受的工作添加到稳定主线
• 过去每项任务的历史记录（完整历史记录）可以通过使用单一，简单，简短，令人难忘的日志记录轻松恢复：-r "branch(TASK-ID)"

Answer 2

我喜欢它。 +1。这就是我这样做的方式。