DVCS 存储库设计 - 使用分支或单独的存储库将开发与稳定版分开？

Question

我正在工作中制定一个“行动计划”，将我们的源代码管理从 SourceSafe 6.0（呃）迁移到 git 或 Mercurial（最好是 git ATM）等 DVCS。现在我正在研究未来的存储库设计，即分支布局以及如何配置“中央”/blessed 存储库。

现在，到目前为止，我只是真正使用 git 作为将业余爱好开源代码推送到 GitHub 的一种手段，最近也是为了保留我的在工作中拥有自己的私有存储库，以便我对代码修订拥有比 SourceSafe 允许的更细粒度的控制。不幸的是，除了使用简单的功能分支之外，我还没有在我的存储库中经历过广泛的分支/合并场景或其他半复杂的 git 使用。换句话说，我对 DVCS 没有太多的总体经验，因此我认为我无法预测我们将在此处使用的典型工作流程，因此无法自行创建匹配的存储库设计。

因此，我花了很多时间阅读其他人的 git 工作流程，并尝试将这些策略最好地应用于我们在工作中发布代码的方式。我认为无论如何这都是一个起点，我们可以随着进展而改变它。

现在，在查看了许多 git 工作流程之后，我真的很喜欢一个特定的 概述作者：Vincent Driessen，它似乎有一个非常干净的分支布局，非常适合我们在工作中进行部署的方式（或者无论如何应该）：

使用分支分离开发/稳定

---

但是，我承认在看到 Joel Spolsky 的 HgInit 站点，该站点似乎更关注单独的存储库，而不是用于分离开发和稳定代码的分支：

Separate Dev/Stable using Repos

---

问题

---

这个以存储库为中心的分离层是否只是一个 Mercurial 的东西，在 git 中使用不多？如果不是，那么与使用分支来分离开发/稳定代码相比，使用此方法有哪些优点/缺点？或者我完全误解了这里发生的事情？ :-)

如有任何意见，我们将不胜感激；如果由于我的无知而导致这个问题浪费时间，我提前道歉。

Answer 1

最后，这完全取决于您的喜好。我喜欢乔尔所涵盖的分支模型的克隆，但它们都是有效的。这是一篇很棒的文章，涵盖了 Mercurial 和 Git 中的一些不同的分支模型（尽管有标题）：

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

我最大的建议是不要过度思考它。我知道你需要一个管理层可以接受的具体建议，但如果我的经历在你所在的地方重演，你会发现人们非常认真地对待去中心化的部分。您将有临时团队在网络共享方面做一些额外的工作，您将有开发人​​员到开发人员的克隆和拉动，以及各种临时组织。只要你有几个关键的回购协议，并且有坚定、明确的期望（例如：“必须编译”或“必须可交付”或“必须得到吉姆的祝福”），你就会没问题。

Answer 2

我对此的感觉是，你应该避免从除了你最好的测试过的东西之外的任何东西分支。这意味着所有分支都应该来自版本中的修订版。

这样做的原因是双重的。首先，当功能分支中出现错误时，您想知道该错误是该功能的结果，而不是代码中的错误。其次，当您想要发布功能时，您不想强制进行与您的功能无关的任何更改。

我们在工作中采用了一种我称之为“浓密分支”策略的策略。

基本上有功能分支、发布分支、修补程序分支和主分支。所有功能分支都必须有一个在其基础上的主分支中标记的修订版，并且它们在任何时候都不得与其他功能分支合并。不过，它们可能会与主分支中未来的标记修订合并。

一旦某个功能准备就绪，它就会合并到发布分支中进行测试。一旦经过测试，它就会进入主分支。修补程序的处理方式与您在图表中绘制的方式大致相同。

最后，我们有一个一次性的“集成”分支。该分支很大程度上自动合并了可能很快发布的所有功能。该分支需要接受日常构建测试，但不一定与发布分支具有相同级别的严格测试。这是为了在此过程的早期发现功能交互错误。

我是一个善变的人。所以我不认为“分支”和“存储库”之间确实存在显着区别。事实上，对于大多数事情，我不太喜欢多个分支存储库，因为它可以很容易地合并到您实际上不想使用的分支中。我宁愿我的仓库中根本没有修订。