2

我需要在 Mercurial 存储库（我们称其为“foo”）上与一些通常是版本控制新手的人合作，尤其是 Mercurial。

我正在尝试提出一个工作流程，使我们能够使用 Mercurial，而无需在他们的一端（混乱）或我的一端（清理）付出很多额外的努力。

我担心的是，作为新手，我需要期望他们犯错误，并且我需要允许他们以可控的方式这样做，否则他们根本不会使用该工具，因为他们太害怕了。但我不希望一个糟糕的改变不必要地污染存储库。

我不希望它们能够正确合并或使用mq扩展。这不是低估它们的问题，而是考虑到过去使用 SVN 的经验和我自己使用 Hg 的经验，这是一个现实的评估。

以下哪种方法最有意义？或者如果有更好的方法，它是什么？

  1. 我们有一个存储库foo-submit，所有人都可以读/写，还有一个存储库foo-trunk，所有人都可以读，但管理员可以写。用户从中拉取foo-trunk更改并将更改推送到foo-submit. 清理：如果我发现一个好的变化，我就让它通过；如果我发现一个不好的变化，我会通过与以前的版本合并来“绕过”它。

  2. 我们有一个foo-trunk所有人可读、管理员可写的存储库。每个用户负责维护他们自己的克隆，该克隆可供团队其他成员读取。当有人想要推送更改时，他们让我知道，然后我从他们的存储库中提取它，并根据需要进行适当的清理（与 #1 相同）

  3. 我们有一个存储库foo-dev，所有人都可以读/写，还有一个存储库foo-trunk，所有人都可以读，但管理员可以写。用户拉/推到 foo-dev，如果他们需要进行广泛的开发，他们可以在命名的分支中工作。我负责执行合并和清理。存储库foo-trunk仅用于拥有一个“干净”副本，该副本具有尖端始终处于良好状态的分支。

4

3 回答 3

2

好问题，而且我从未见过一个很好的答案。

也就是说，我喜欢选项 2。这是 Linux 内核使用的“拉取请求”模型，并在 GitHub 上很流行。它允许管理员充当看门人/审阅者，只有在他们高兴时才允许好的变更集通过他们。如果他们认为开发人员没有交付有价值的东西，那么拉取请求将被拒绝（有原因）。然后开发人员可以离开，修复他们的代码/仓库，并提交另一个拉取请求。

运行带有RhodeCode之类的服务器可以帮助掌握拉取请求。随着事情的发展，您可以拥有处理子系统的较低级别的看门人，以及处理整个项目的更高级别的看门人。

我从来没有完全理解的是被拒绝的变更集应该发生什么，并且开发人员决定放弃而不是修复并重试。它们可能会被关闭，但随后可能会错误地出现在未来的拉取请求中。它们是无害的，但可能会令人困惑。另一种选择是剥离它们，但这听起来像是给人们工具，他们会割伤自己。

您提供的其他 2 个选项值得一提。

1 类似于 2。您仍在执行“拉取请求”类型的流程，但现在您拥有反映开发人员克隆的服务器端分支。几乎没有区别，这就是 RhodeCode、GitHub、BitBucket 服务器让您工作的方式，除了您不必去搜索更改。服务员会告诉你他们在等你看。

3 的问题是每个人的更改都foo-dev在您到达之前全部合并在一起。他们将开始相互依赖，挑选樱桃会变得一团糟。您可能最终会graft更改更改集，foo-trunk这意味着您正在使用新的哈希创建新的更改集。当开发人员拉出这些时，他们现在将在两个地方进行更改；他们的原始foo-dev版本和您的移植foo-trunk版本。这对我来说听起来不可持续。

于 2013-04-23T16:57:31.643 回答
1

3a -foo-dev有受保护的default分支（只有一些管理员可以推送/合并到这个分支），用户使用命名分支

于 2013-04-02T18:53:07.970 回答
1

如果您不想使用 mq（以最少的麻烦理解），我能想到的最好方法是让您的开发人员

  1. 为正在开发的当前功能创建自己的分支
  2. 完成并验证后将其合并回主开发分支（或移植/移植）
  3. 然后关闭分支。

从长远来看，让他们学习 mq，掌握起来并不难。

于 2013-04-02T18:21:58.283 回答