在不破坏Git存储库和生产网站的情况下升级Drupal核心的最佳实践是什么


13

我有一个Git存储库,我所有的代码都在master分支中,以前我只是忽略了所有Drupal文件,因此我在编写(或修改或可能修改)的代码与代码之间严格分开可以用Drush或其他方式生成

在我不得不升级Drupal之前,这似乎是一个不错的策略。我意识到如果情况不佳,我希望能够回滚,并且可以使用比Git更好的工具来做到这一点。我以为自己这是功能分支的理想情况,所以我做了一个drupal-7.14分支,让它自己.gitignore忽略了我所有的代码和设置文件,只注意了Drupal安装中的文件,而我不会这样做。不要碰。我手动进行了升级(下载,解压缩,解压缩,复制),对诸如robots.txt和.htaccess之类的边界案例进行了排序,并用我自己的脚本覆盖了Drupal的.gitignore。我修复了一些适用于7.14但不适用于7.15的设置,以从500错误中恢复,然后一切似乎都很完美。我将分支重命名为,drupal-7.15并且愉快地前进了。

直到我意识到自己无意间做了什么:当我签出master时,以前由master分支取消跟踪但留在工作目录中的文件现在已从工作目录中删除,因为它们不再是取消跟踪的文件! 天哪!

如果我将drupal-7.15分支与master 合并,则将失去代码分离。

可能存在将分支转换为子模块的某种方法。假设这是可能的,那可能是最好的策略。在执行此操作之前,我知道子模块是“正确的”解决方案,但是由于我没有意识到对以前未跟踪的文件使用分支的副作用,因此我决定走捷径。(此外,我所见过的在Drupal中使用子模块的所有方法都假设您正在启动一个新项目,而Drupal将成为master分支。我不希望将其他人的代码设为master分支,而我已经拥有了带有主分支的仓库。这看起来像只是进行升级就不必要地复杂。)

可能还有其他我没有想到的解决方案。

我如何才能以最少的弊端从中最好地恢复过来?

更新:这正在开发中(在我的笔记本电脑上是Linux VM),尚未投入生产。到我们投入生产时,我计划将所有功能包装在功能模块中,但是目前为止还没有。

更新2:子模块可能无法正常工作。根据 Pro Git的说法,“子模块允许您将Git存储库保留为另一个Git存储库的子目录”。Drupal没有提供任何这种很好的分离。并不是所有的Drupal代码都在一个子目录中,而是差不多颠倒了这种关系,但是仍然没有明确的分离,因为您可能正在编辑.htaccess和robots.txt,因此您的代码和Drupal仓库混合在一起了。我正在寻找解决此问题的方法


您的问题实际上是关于git的。我认为通过将其迁移到不是Drupal特定的站点,您将获得更好的答案。关于升级:我总是通过在新目录中构建make文件,然后将符号链接从旧目录更新到新公共目录来进行升级,这使得代码回滚变得微不足道。
Letharion 2012年

2
@Letharion我不同意。每个人都将经历将网站从当前版本升级到新版本的过程。使用git升级核心相当普遍,因为这是一种广泛使用的模块升级方法。像我以前一样,很多人都会为这个问题而苦苦挣扎。当前在网络上没有很好的文档可以解决这个问题,我相信这是个好地方。
iStryker

为了明确起见,我认为关于“升级Drupal的最佳实践”的问题会更合适,因为这个问题实际上是“我如何修复git错误”,我认为这不属于这里。不过,对该主题没有任何强烈的感觉,因此我将其保留。:)
Letharion 2012年

好,可以。布兰登遇到的问题相当普遍。也许我应该创建一个新问题或重写这个问题(然后将其余问题移至另一个问题)。前2-3段很常见。您创建了7.x-1.0的git仓库,并且想要升级到7.x-1.1。问题文件是.gitignore,.htaccess和robot.txt。有时您希望它们因为被修改而被跟踪,有时您不希望它们由于被修改而被跟踪。升级仓库时,您会创建一个新分支合并还是仅更新主分支。@Letharion建议?
iStryker

@Letharion:我考虑过将它作为Git问题放在StackOverflow上还是作为Drupal问题放在这里。如果我把它放在那儿,每个人都会抱怨说这真的与Drupal有关,我认为他们真的是对的。尽管Git可能是修复情况的工具,但采取的方向取决于Drupal的知识。每个Drupal用户都使用Git(如果不使用,则应该使用Git),但是只有极少数的Git用户使用Drupal。回答有关Git问题的人不会了解Drupal背景。
iconoclast 2012年

Answers:


10

从上面的讨论看来,您的问题不是关于修复git repo,而是关于在git中维护Drupal网站,以及它如何与核心更新一起工作。

我认为标准做法实际上是将所有文件(包括Drupal核心)保留在您的存储库中。将Drupal代码与自定义代码分开似乎是一个好主意,但我认为这不是必需的,而且我也看不到它给您带来什么好处。似乎还假定您永远都不想修补核心(或必须在部署过程中进行修补),虽然这不是最佳实践,但绝对是您希望在出现问题时能够做的事情在生产中。保持良好的提交和专注的态度也有助于实现这种分离。

我使用的解决方案是将所有代码保留在同一个存储库中,将其尽可能多地放入“功能”或其他类型的导出/代码/配置中,并维护需要应用于外部的补丁列表。 -box核心和贡献。

更新核心时,请从您的开发环境开始:

  • 确保工作目录是干净的
  • 转储最新数据库(drush sql-dump)。通过转储进行提交或将其保存在安全的地方。
  • 更新核心(drush up drupal
  • 提交所有更改。
  • 检查补丁文件。如果需要应用任何补丁,请应用它们,然后再次提交
  • 如有必要,运行update.php(如果使用drush进行更新,则已完成)
  • 测试您的开发站点。如果一切正常,则将代码推送到生产环境。运行drush updb生产。
  • 如果存在问题并且您需要还原,请还原或重置您的存储库(git reset --hard HEAD~2应该这样做),或者如果您想保留历史记录,请还原两个提交。用转储替换数据库。

数据库转储是必需的,因为否则您将无法撤消通过更新对数据库所做的更改。您也可以在分支中进行更新,在这种情况下,还原仅意味着检出master。如果您在一个开发站点上工作,那是不明智的,因为由于数据库的原因,您不能真正切换回master并继续并行工作。

使用这个更简单的git-side工作流将允许您在需要时使用git的全部功能,而不会导致子模块等的复杂化。如果这似乎还不够,您能否解释为什么需要进一步分离代码?


0

从我上面的评论中,您有一个问题是关于使用git 维护Drupal站点文件,以及它如何与核心更新一起工作。您没有提到有关备份和升级数据库的任何内容。我将尽量不要从goron答案中复制任何内容。

我已经创建了有关此问题的博客文章, 使用Git在您的网站上升级Drupal核心

替代方法

  1. 运行Drush命令 drush up drupal
  2. 应用版本之间差异的补丁。参见http://drupal.org/node/359234http://fuerstnet.de/en/drupal-upgrade-easier

你没有说明这一点,但如果你有兴趣跟踪Drupal的版本之间的变化,我会用做标签,而不是分公司。将升级提交到master后,将代码标记为7.x。


如果我理解正确,那么您还建议我将所有Drupal核心代码都保存在同一存储库中。这似乎是共识。我不太愿意,但我可能不得不屈服并这样做。
iconoclast 2012年

是的,全部集中在一个存储库中。我在核心/主存储库中有模块,配置文件和主题,它们是自己的git仓库。我不知道最好的方法,但是我知道这是最好的方法。
iStryker

该解决方案无法返回。我投票的理由。
Andre Baumeier

@Serpiente:我不明白为什么缺乏回退的方式应该是投票失败的原因。如果这是最好的方法,那就足够了。如果您认为这不是最好的方法,请说明原因。
iconoclast 2014年

@iconoclast如果您无法返回时间表,修订系统会如何?例如,考虑更新失败-在这里恢复的方式是什么?“任何”软件的出厂版本应具有明确的依赖性,尤其是框架核心。否则,您可以简单地删除git并再次开始进行FTP部署。只是我的2美分。
安德烈·鲍米耶

0

我正在像OP一样使用两个分支来运行安装程序:一个分支仅包含我的自定义代码,另一个分支同时包含我的自定义文件和核心文件。我遇到了同样的情况:在分支之间切换时,被忽略的核心文件被删除了。

我最终拥有两个完全相同的git目录:-一个用于处理自定义代码的核心文件存在但被忽略了,并且我永远都不会切换到该目录中的“完整”分支-一个用于执行合并,因此我将仅在此目录内执行分支切换和合并。

我选择此两分支设置的原因是因为我想轻松跟踪对核心文件的所有本地提交,因此在升级核心文件时更容易检查并重新应用核心mod。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.