我需要在Mercurial存储库（我们称之为“foo”）上与一些人进行协作，这些人通常是版本控制的新手，尤其是Mercurial。
我正在努力想出一个工作流程，使我们能够使用Mercurial而不需要花费太多额外的努力（混淆）或我的结束（清理）。
我担心的是，作为新手我需要让他们犯错误，我需要允许他们以受控制的方式这样做，否则他们根本不会使用该工具，因为他们太害怕了。但我不希望有一个糟糕的变化来不必要地污染存储库。
我不希望他们能够正确合并或使用mq扩展名。这不是
这是一个低估它们的问题，而是根据SVN过去的经验以及我自己的Hg经验，这是一个现实的评估。
以下哪种方法最有意义？或者，如果有更好的方法，它是什么？
我们有一个存储库foo-submit，所有人都可以读/写，还有一个存储库foo-trunk，所有人都可读，但管理员可以写。用户从foo-trunk拉出，并将更改推送到foo-submit。清理：如果我找到一个好的改变，我会按原样通过;如果我发现一个不好的变化，我会通过与之前的版本合并来“绕过”它。
我们有一个可供所有人读取的存储库foo-trunk，可由管理员编写。每个用户都负责维护他们自己的克隆，该团队的其他人可以读取。当有人想要推动变更时，他们会告诉我并将其从存储库中提取出来，并根据需要进行适当的清理（与＃1相同）
我们有一个存储库foo-dev，所有人都可以读/写，还有一个存储库foo-trunk，所有人都可读，但管理员可以写。用户拉/推到foo-dev，如果需要进行大量开发，可以在命名分支中工作。我负责执行合并和清理。 foo-trunk存储库仅用于具有“干净”副本，该副本具有分支，其中小费始终处于良好状态。
答案 0 :(得分：2)
好问题，而且我从来没有见过很好的答案。
那就是说，我喜欢选项2.这就是＆＃34; Pull Request＆＃34; Linux内核使用的模型，受GitHub欢迎。它允许管理员充当守门人/审核者，只允许好的变更集在他们开心时通过它们。如果他们认定开发人员没有提供有价值的东西，那么拉取请求就会被拒绝（有原因）。然后开发人员可以离开，修复他们的代码/回购，并提交另一个拉取请求。
在其上运行带有RhodeCode之类的服务器有助于掌握拉取请求。随着事情的发展，你可以拥有处理子系统的低级守门员，以及处理整个项目的更高级别的守门员。
我从来没有完全理解这一点，即被拒绝的变更集应该发生什么，以及开发人员决定放弃而不是修复并再试一次。它们可以被关闭，但随后可能会出现错误，作为未来拉动请求的一部分。它们无害，但可能令人困惑。另一种方法是剥离它们，但这听起来像是给人们自己开发的工具。
您提供的其他两个选项值得一点评论。
1类似于2.您仍在执行＆＃34; Pull Request＆＃34;类型流，但现在你有服务器端分支镜像开发人员的克隆。没有什么区别，这就是RhodeCode，GitHub，BitBucket服务器如何让你工作，除非你不必去寻找变化。服务器会告诉你他们正在等你看。
3的问题是，在您到达之前，所有人的更改都会在foo-dev上合并在一起。他们将开始变得相互依赖，挑选樱桃会变得混乱。您可能最终graft将更改集设置为foo-trunk，这意味着您正在使用新哈希创建新的更改集。当开发人员拉动他们时，他们现在会在两个地方进行改变;他们原来的foo-dev版本和您的嫁接foo-trunk版本。这对我来说听起来不可持续。
答案 1 :(得分：1)
如果你不想使用mq（对你来说最麻烦的话），我能想到的最好的方法就是拥有你的开发
从长远来看，他们要学习mq，这并不难理解。
答案 2 :(得分：1)
3a - foo-dev已保护default分支（只有部分管理员可以推送/合并到此分支），用户使用命名分支