WordPress和Git工作流程


23

我知道这个问题已经被问过一千遍了,但是我真的在尝试找出如何在使用WordPress时充分利用Git的优势。

我已经在网上搜寻并阅读了数十篇文章,所有这些文章似乎都简短地涵盖了该主题。这是我最近读过的一些最著名的书。

-版本控制WordPress

-使用Git管理WordPress主题部署

-使用git而不是FTP管理自定义WordPress主题

目前,我的工作流程如下所示。

  • 在本地安装WordPress
  • 开发主题
  • 从本地服务器导出WordPress数据库
  • 将WordPress数据库导入到远程服务器
  • 通过FTP上传WordPress文件和主题
  • 客户做出改变
  • 通过FTP下载WordPress文件和主题,并从远程服务器导出WordPress数据库
  • 在本地替换文件
  • 进行开发变更
  • 通过FTP重新上传,将数据库导出并导入到远程服务器

我意识到Git可以简化此过程。似乎最好的方法是拥有一个.gitignore文件,该文件忽略不需要跟踪的某些目录,以及具有本地和远程wp-config.php文件。

但是,您如何处理数据库?客户通常会进行更改(帖子/页面/插件)。我仍然需要从远程数据库中导出并重新导入到本地服务器中吗?

有人可以在这里为我建议最佳的工作流程吗?并逐步引导我。

另外,我可能想使用Bitbucket,因为与GitHub不同,它们是免费的私有存储库。

任何帮助,将不胜感激。

提前致谢!


怎么样了 你知道了吗?在这里有同样的问题。
qwerty

3
你能把问题集中一点吗?您询问有关git的信息,但随后跳转到数据库,而git本质上不是用于处理这些信息的工具。
腊斯特

4
我认为您的问题是有效的。我具有相同的工作流程,并且通过与其他开发人员交谈发现它们也具有相同的工作流程。但这确实很耗时,并且为错误提供了很大的空间。我也对更好的解决方案感兴趣。
gdaniel

Answers:


6

我是WP Migrate DB Pro的开发人员之一,并且想回答@Ennui的问题:

“您知道它运行的数据库URL替换脚本是否考虑了序列化的字符串吗?”

是的,它确实处理序列化数据。实际上,这就是我在2009年开发免费版本插件的主要原因。

不幸的是,我的声誉只有41岁,因此无法回复@Ennui的评论。抱歉


1
现在有50个:)很棒的插件人。
Andrew Bartel

4

我对以“不具建设性”的态度来结束这一决定投反对票,因为这似乎是在征求辩论和意见,而不是回答。但...

那不是我的工作流程,它使我的方法(和答案)与到目前为止的大多数其他答案有所不同。

  1. 在本地安装WordPress
    1. 这是从包含最新稳定发行版的本地裸Git存储库中克隆的。
    2. 我还保留了我几乎总是安装的一些插件的最新版本的本地副本。
  2. 构建主题和任何必要的插件
  3. 上载到公共登台服务器
    1. 客户端被授予访问权限,但无法更改代码,并且它告知数据库编辑内容不会转移到生产站点。
    2. 这意味着没有理由将代码下载回开发服务器。
    3. 而且没有理由重新同步本地数据库
  4. 根据我们的员工和客户的反馈意见对本地站点进行更改。
  5. 上载变更
  6. 视需要重复(但阻力增加:))
  7. 如果我们提供的内容(并非总是如此),我们(不是客户端)将清理登台服务器上的数据库并上传内容。
  8. 通过将本地代码上传到生产站点进行部署。
  9. 如果我们创建了内容,则将内容通过临时导出工具从暂存站点中导出,然后导入到生产站点中。
    1. 这是我唯一的一次移动数据库的过程,它是使用非常标准的工具完成的。如果需要,我将使用Velvet Blues更新URL清理数据库。
  10. 除错
  11. 结束

基本上,在我们移交网站之前,我会尽量让客户远离我的东西。

代码以一种方式-从本地转移到阶段或生产。它永远不会向相反方向移动。这省去了您的一些步骤,让我省心。我不想因为我的代码修改客户端而受到指责,也不想导入一些被黑客入侵的文件,这是一种非零的可能性。

而且数据库仅移动一次(如果有的话),从而极大地减少了问题。因此,我想我可以通过减少或消除移动数据库的需求来管理“数据库移动”问题。它还减少了可能出现的数据库损坏问题,并减少了导入黑客的机会。

没错,我必须配置生产站点(永久链接,菜单等),但这迫使我在生产站点上工作,因此我认为这是一种调试。它可以帮助我确认事情在生产现场中应有的运作方式。


1
11.结束 -您从未需要维护/修补/改进WordPress网站吗?
西蒙·伊斯特


2

看一看基岩堆。它使用composer来管理Wordpress和第三方插件的版本,还包括用于部署的capistrano和vagrant / ansible用于设置服务器(包括用于开发的本地虚拟服务器)。


2

最近,我对此进行了大量测试,这是我使用的工作流程,它几乎可以满足您的要求:

  • 我使用wp-cli管理wordpress核心并更新wordpress。
  • 我与http://wpackagist.org一起使用composer 来管理插件和主题依赖项。
  • 我使用git并将核心wp文件放在.gitignore中。因此,大多数wp-config.php和子主题文件位于git中。

我对数据库迁移工具不熟悉,但是将是此工作流程的重要补充。

以下是有关工作流程的完整详细信息:http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli


1

关于数据库“克隆”,我使用WP Migrate DB Pro:http : //deliciousbrains.com/wp-migrate-db-pro/

它是一项付费服务​​,但价格不高,并且可以轻松地将数据库从开发人员拉入或推送到实时服务器,反之亦然。它会更改URL以及在此过程中需要更改的所有其他内容。


1
您知道它运行的db url替换脚本是否考虑了序列化的字符串吗?一个简单的更新查询来替换url是不好的,因为它会破坏其中带有URL的任何序列化字符串(除非新URL与旧URL的字符数相同,至少可以说是很少的)。这会破坏文本小部件和许多插件。我现在使用这个脚本,但是如果它做同样的事情,我会对这个插件感兴趣。
恩努伊

我刚刚通过电子邮件发送给开发人员,以回答该问题。我还没有这个需要。
deadlyhifi

1
我使用此插件满足所有迁移需求,但尚未看到序列化字符串和url替换的任何问题。所有自定义字段的传输都没有问题。请记住,默认情况下它将替换所有内容。这包括用户/密码/等...
hereswhatidid
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.