几个月来，我一直在尝试为使用git版本控制进行WordPress网站开发规划一个良好的项目结构，该结构不牺牲通过WP仪表板更新核心和插件的能力，不需要非传统的目录结构（WP父文件夹之外的WP内容），并且易于管理和部署整个网站。我读过关于子模块、子树、嵌套式回购等的书，但我仍然很难将其整合在一起，并选择正确的策略。
以下是我现在的想法，括号中是我如何处理git回购的想法。
root (main project repo)
|-- wordpress (public git repo added as subtree)
| |-- wp-content
| | |-- plugins
| | | |-- my-custom-plugin (git repo added as subtree)
| | | |-- other-plugin-with-git-repo (git repo added as subtree)
| | | +-- other-plugin-without-git-repo (ignored/untracked)
| | |-- themes
| | | |-- my-custom-theme (git repo added as subtree)
| | | |-- other-theme-with-git-repo (git repo added as subtree)
| | | +-- other-theme-without-git-repo (ignored/untracked)
| | +-- uploads (ignored/untracked)
| |-- wp-admin
| +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt
这给我留下了几个问题；
自动更新；我喜欢新的自动更新功能，它可能会节省很多时间和精力来保持我的网站的更新和安全，但它似乎对使用git跟踪代码更改带来了麻烦。在允许WordPress core自动更新的同时，有没有办法跟踪我的代码更改？
在WordPress core repo下有子树是否会阻止我使用git合并新的核心更新或将更改推回到WordPress core repo（如果我决定成为核心贡献者）？
对于没有公共git repo的插件，完全忽略它们会导致无法在新服务器上快速克隆整个站点，而不将文件手动复制到服务器上的问题。如果我想对插件的代码进行更改，也会导致问题，这些更改不会被跟踪，并且很容易在插件升级中丢失。
所以，总而言之，什么是好的git+WordPress设置可以避免这些问题？我将感谢您对我提议的项目结构的反馈。任何方式，你可以帮助我改善这一点，将不胜感激！
PS，如果有更好的讨论论坛，请告诉我。
SO网友:Rarst
在我看来，您的计划有两个问题——Git和“传统”结构。所以基本上一切都是这样。：）
Git（以及一般的版本控制）对于整个站点堆栈来说是一个糟糕的工具。在那里，做了那件事，很痛。
一段时间以来，对于任何严肃的网站来说，将内容与核心内容分离的“非传统”结构都是一种非常传统和稳健的选择。
几乎没有将整个站点堆栈与本机更新相结合的全套方法。由于它试图在不同级别的项目中实现不同的目标（控制中的开发人员与控制中的最终用户），所以它不能很好地结合在一起。
如果你问我整个网站WordPress堆栈的最佳匹配是当前Composer, 然而，意见可能会有所警惕。：）
关于您的具体问题：
如上所述，本机更新（更为自动）无法与严格控制的堆栈配合使用。
WordPress core不是用Git开发的，也不接受pull请求，所有贡献（到目前为止）都是通过补丁文件提交给Subversion的。
你可能必须将这些插件提交到你的回购协议中。或者使用其他方法，如Composer。
SO网友:Wyck
这种类型的开发属于“不太容易，需要定制工作流，可能需要很长时间才能满足”。
我发现子树、子模块或嵌套式回购协议是一种巨大的痛苦。
一些想法（追踪一切）。
使用git/svn启用自动更新：add_filter( \'auto_upgrade_ignore_checkout_status\', \'__return_true\' );通过手动提交+电子邮件的安全方法：
您可以使用暂存服务器并通过电子邮件向自己发送更新通知，提交更新并推送到关闭自动更新的实时服务器。
这还允许您随意为自己的回购复制/粘贴文件夹，我经常这样做。它还可以很容易地克隆/销毁多个临时服务器，git由于是分布式的，所以它确实可以通过这种方法生效。
缺点：复制/粘贴文件夹、管理。
自动方法
设置一个构建脚本（Phing、Ant、Bash、Capistrano等）和一些自定义代码，在应用更新时执行git添加+提交，并将其发送到实时服务器。您还可以分离插件/主题库，然后让脚本编译/移动/无论它们是什么，和/或混合使用Composer。
自动化这样的工作流也往往缺乏灵活性，只有当您看到真正需要投入的时间时，才值得这样做。
缺点：缺乏灵活性，需要时间来创建。
Git不应用于备份，一般来说，您不需要克隆WP的提交历史记录。
SO网友:Josiah Sprague
再想一想，既然我肯定想利用本机WP更新来节省自己的工作量，那么跟踪WP将使用git更新的任何内容是没有意义的。这里有一个修改后的想法。
root (main project repo)
|-- wordpress (ignored/untracked)
| |-- wp-content
| | |-- plugins
| | | |-- my-custom-plugin (git repo not connected to parent)
| | | |-- other-plugin (ignored/untracked)
| | | +-- modified-plugin (unignored, added to main project repo)
| | |-- themes
| | | |-- my-custom-theme (git repo not connected to parent)
| | | |-- other-theme (ignored/untracked)
| | | +-- modified-theme (unignored, added to main project repo)
| | +-- uploads (ignored/untracked)
| |-- wp-admin
| +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt
当然，这样我就无法从VCS中跟踪哪些插件和主题是项目的一部分，但我真的只需要用于备份目的，无论如何我都会使用某种常规备份系统。
因此，我想要的唯一真正缺少的是能够轻松地将整个堆栈部署到不同的服务器，而无需使用FTP手动复制整个堆栈。有人有什么想法吗？
