version-control - 使用现有的各种 VCS(版本控制系统)来跟踪 Drupal 项目有什么优点？

Question

我正在尝试为我的 Drupal 工作流程找到最佳版本控制策略。我每次安装有多个站点，我很确定我将为每个站点都有一个单独的存储库。据我所知，值得考虑的VCS有:

SVN

集市 (bzr)

Git

Mercurial ( Mercurial )

我知道这些通常如何相互比较，但想了解它们对 Drupal 的优缺点。如果您正在(或已经使用)Drupal 中的任何一个:

你的设置是什么？

您选择的 VCS 对管理 Drupal 项目的效果如何？

什么没有？

Answer 1

另一个颠覆设置在这里。

基本设置为:

我们跟踪 Drupal 核心和我们使用的所有贡献的模块/主题，每个模块/主题都位于我们存储库的一部分中的自己的文件夹中

每一个都有一个子文件夹“drop”，一旦我们开始使用它们，新版本就会被复制到其中。

然后我们将其提交为“删除版本 6.xy” - 这会导致 Drupal 核心或相关模块的发布版本的本地历史记录(与 drupal.org 上的“官方”cvs 历史记录冗余，但更方便出现问题时搜索/差异)

然后我们为drop创建一个分支，以版本命名(例如drupal-6.15，views-6.x-2.8)——这通常会按原样使用(参见下面的“外部”)，但也用作对模块进行自定义更改的基线，如果我们需要的话。我们尽量避免更改核心或贡献的模块，但有时我们需要修复错误并且不能等到修复最终以正式版本结束。因此，我们进行更改并在该分支上提交。一旦有新版本进来，我们就可以将它与我们的分支进行比较，并最终将修复重新应用到新版本分支，如果它尚未包含修复。通过这种方式，我们对我们在不同项目中使用的所有核心和模块版本有一个完整且可重用的概述，包括我们最终需要的任何自定义。

对于我们的每个项目(站点)，我们在存储库的不同部分创建通常的 SVN 主干/分支/标签层次结构

然后我们使用 Subversions 'externals' 定义来拉入核心版本，以及我们从上述分支中需要的所有附加模块。这里的重要部分是我们可以拉取我们需要的任何版本，因此有些站点可能使用模块 x 的特殊补丁版本，而其他站点可能会拉取未打补丁的先前版本，而另一个站点则使用最新最好的官方版本——我们不不必跟踪这个烂摊子，因为 SVN 可以随时准确地告诉我们何时何地使用了什么!

然后我们添加我们的项目/站点特定的东西 - 设置文件、.htaccess 文件、项目特定的模块/主题等。

新开发发生在主干

到达发布点后，我们创建一个发布分支并标记为

我们根据需要将该标签导出到测试/登台/实时服务器

同时，新的开发可以在主干

上继续

如果我们需要对当前发布版本应用修复，这发生在发布分支

再次提交、标记并最终导出和部署修复程序

如果修复是一般需要的东西，它会被合并回主干，以便它在 future 的版本中可用

起泡、冲洗、重复...

优点:

主要是对我们任何项目中任何代码发生过的所有事情的完整概述:)

特别是，能够跟踪和重用不同项目中不同版本的核心或贡献的模块，即使是任意自定义更改，也不会造成无法管理的困惑(我们何时、为什么以及在何处在 pathauto 中使用此自定义单行修复，以及何时，为什么以及我们在哪里停止使用它 - SVN日志会回答)

可重复部署 - 如果生产服务器上出现任何问题，我们可以导出那里使用的确切代码集，并在现场进行所有一次性修复、调整和“专业”(显然仅与适当的数据库备份结合使用；)

缺点:

从上面的描述中很容易看出，在导入新的核心/模块版本时，这种设置会产生一些管理开销(而且大多数时候它甚至看起来是不必要的，因为应用特殊修复是一种罕见的事情)

像这样广泛使用外部定义使得对本地结账的更新操作有点冗长

当变更集意味着对项目本身和通过外部导入的自定义模块的更改的组合时，它不会是原子提交，因为它们必须单独 checkin !

结论:

只要您只需要管理少数项目/站点，这可能不会有效，您可能会更好地提交和维护在一个分支内组合的整个设置(核心、贡献和自定义内容)。

但是我可以保证，一旦您必须并行管理 10++ 个项目(一些在 5.x 上，一些在 6.x 上，都处于不同的更新和/或自定义级别，通常重复使用相同的自定义)，能够分辨究竟在哪些地方使用了哪些代码是一个巨大的缓解!

PS:重读我的布道，很明显，它并没有真正解决您关于不同 VCS 与彼此相比的优点的问题 - 抱歉，但无论如何它可能会有所帮助；)