进行 Magento 更新（维护不善的 Magento 安装）的最佳实践是什么。
我想到了以下几点：
主要问题是：在旧的、维护不善的 Magento 安装中比较文件时，您永远不知道被复制的原始文件具有哪个版本。有时我试图通过查看文件评论中 Magento 的版权来识别旧版本。
为了避免更新过程中的麻烦，我们通常会执行以下操作：
[Mycompany BEGIN] ... [Mycompany END]但是，如果没有采取这些预防措施，如何进行更新？
正如其他人所指出的那样，这里的关键是使其与全新安装相当，所以这就是我在版本控制的帮助下要做的事情。
让自己获得当前使用的 Magento 的干净版本，并且不要忘记使其具有可比性。或者使用现有的 magento git 镜像（查看更多http://blog.speedupmate.com/post/4063307705/magento-git-mirror）
建立一个基于 1. 的主仓库并在手边
在评论中询问：您的最终目标是拥有一个干净的核心，其中包含 git 中存在于 magento 安装文件中的所有文件。这是必需的，因此您可以将所有内容与全新安装进行比较。管理核心更改、核心文件树（现有的、不存在的、添加的文件）。您可以使用 .gitignore 处理您的异常（不包括媒体、缓存、所有具有服务器特定范围 local.xml .htaccess 的字段）。我发现将 Magento 核心文件移出到不同的（非公共）目录很容易（如此处所述http://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento) 这会给我一个代码状态，其中 .htaccess 在升级时不会发生冲突。我也从不在版本控制、缓存和 magento 生成的所有临时文件中包含媒体。这将保证您清除升级路径，因为您可以在升级期间禁用所有。稍后比较代码将为您提供需要概述的内容范围，并且您可以估计比较更改的部分并上线升级需要多长时间。
现在使用您现有的站点和 git 配置（以使其具有可比性）git init在您的代码库上执行一个并将所有内容添加到 git 那里，这将检查您的 git 配置并使每个文件具有可比性（相同的换行符、空格等）然后修复文件权限相同。之后，您可以从您的站点中删除 .git 文件夹，因为您只使用 git 来使文件在那里进行比较。
在评论中询问：这里的重点是让 git 为您工作，例如将所有行尾转换为 unix 样式并忽略空格，理论上您也可以忽略权限，但这没有用（这里的格式有点不对，所以 \ 代表换行符命令之间
git config core.autocrlf input \
git config core.eol lf \
git config apply.whitespace nowarn
现在，如果您git init
添加这些配置并将所有内容添加到 git，那么在提交阶段 git 将替换所有 Windows 行尾和所有废话，以统一和可比较的样式。请注意，zend 编码标准建议使用 unix 样式的行结尾，但是您还会看到 Zend 库不遵循其自己的标准的文件。这里的关键点是您需要您的文件具有可比性，以最大限度地减少您必须做的差异负载。在 git 为您格式化所有错误的安装文件后，您将删除 .git 文件夹。Git仅用于在此步骤中自动化“使事物具有可比性的过程”，仅此而已
根据 1. 中的主存储库签出您的测试存储库
从该结帐文件夹中删除所有内容并仅保留 .git ，因此它是空的，但版本控制仍然存在。它将处于所有内容都已删除的状态，这在这里很重要，因为您将知道您可能在坏网站上删除了哪些文件。
在评论中询问：我通常在 git config 中添加忽略空格（本地或全局范围可用）并让 git 为我处理。在团队中工作时，我们始终同意基于 Zend 标准：4 个空格用于制表符，unix 样式行尾和 3 中提到的 git config 变量。如果涉及构建脚本，我们会使用提交挂钩进行代码格式化和验证。
将所有文件移动到您的空目录（请注意，您已经从现有站点中删除了 .git 目录，使其具有可比性）从您安装的 magento 安装（它们现在是可比较的）并运行git status > changes.txt. 这个文件现在列出了你在“f cked up installation”中拥有的所有差异、你拥有的任何新文件、任何已删除、重命名等文件，以及你当前使用的干净的 Magento 代码。
根据评论解释：我通常这样做git status --porcelain
有一个 .gitignore 文件来帮助您丢弃 local.xml var/* 或您不需要版本控制的每个文件/目录，以及 .DS_Store、.Thumbs.db 和您的 ide 从 git 创建的项目文件。您不需要所有媒体和缓存文件以及版本控制中每台服务器中不同的文件。
从那里您应该仔细查看该列表，并根据该列表，您应该：
git checkout filename）现在你的状态仍然很差，但你现在是：
现在，您可以受益于版本控制、可比较和基于您的主分支的单独分支，其中包含 Magento 的可合并版本。因此，让我们尝试升级，这是 100% 成功的关键点。
第一步是禁用您现在已分离到 app/code/local/Mage/ 和分离主题的所有“废话”。如果您的核心清晰并且可以禁用主题，则您没有自定义代码干扰升级过程。所以继续禁用：
现在，如果您的 repo 中的主树中的所有主要版本都单独标记或分支，那么获得更高版本只是一个命令： git merge "magento-vhateverthenextversionis"
如果您已经将 2. 迭代到您想要的 magento 版本到最新版本，那么是时候吃掉您继承的“s*it”并执行以下操作：
如果您到了这一点，那么您已经完成了大量工作，这取决于安装的混乱程度，这可能需要几天时间。但是，嘿，现在您有一个干净的 magento 核心，它是受版本控制的、合并和概览的单独覆盖，以及可以禁用的单独主题中的所有内容。
有趣的部分是，如果 magento 的下一次升级可用，您可以吹口哨并将其添加为与您的主树相比并合并更改，了解更改的内容并明确概述和测试的范围。
我将首先指出您的问题内容表明对（我至少认为是）最佳实践有清晰的理解。
关于潜在的多个原始版本：软件升级的目标是使新的类和方法到位。这意味着（正如您所提到的）移植任何自定义，无论它们是如何实现的。
除了勤奋的差异之外，不幸的是，适合您情况的最佳技术将是回归测试- 检查生成的多个视图的输出。
很有可能您可能需要下注，即从全新安装开始并积极引入仍然认为必要的自定义功能和主题。这似乎不是最有效的方法，但我认为以下是超出明显开销的好处：
我要做的第一件事是将站点复制到开发环境中。现在对此进行备份，以便您可以随时恢复到该状态。同样在这一点上，我会将实时站点置于代码锁定状态。除非绝对必要，否则不再更改代码（如果有更改，您将不得不在新的开发环境中复制它们）
既然您已经拥有了可供您使用的网站的安全副本，那么乐趣就开始了。
我要做的第一件事是下载您正在运行的 Magento 库存版本的副本。在股票版本和您当前拥有的版本之间对 /app/code/core 进行比较。这将告诉您您的差异是什么。我会尝试维护您当前拥有的所有功能，同时让核心恢复正常。
希望此时您已经安装了相当干净的 Magento。您可以考虑将其推回实时服务器，但我有一种感觉，您可能不得不做很多事情才能做到这一点，所以它可能不是一个可行的选择。
现在，我将对开发站点进行单独备份，以便您可以在需要时返回到这一点。
现在，我将尝试在开发站点上进行升级。希望一切顺利，升级没有问题。如果您不这样做，请进行所需的更正并从那里继续。
此时，您应该有一个在升级时稳定的代码库。再次实时备份（只是为了安全起见），向上推送新代码，并希望一切正常。