如何更新一个维护不良的Magento安装程序，有哪些最佳实践？
以下是一些想法：
主要问题是：在旧的、维护不良的Magento安装程序中对文件进行差异化比较时，您永远不知道复制的原始文件是哪个版本。有时我会通过查看文件注释中Magento版权来确定旧版本。
为避免更新期间的麻烦，我们通常采取以下措施：
[Mycompany BEGIN] ... [Mycompany END]但如果没有采取这些预防措施，该如何进行更新呢？
如其他人所指出，关键在于将其与清洁安装进行比较，因此以下是我会用版本控制的方法完成的。
获取当前使用的Magento干净版本，并确保其可比较。或使用现有的Magento git镜像(查看更多：http://blog.speedupmate.com/post/4063307705/magento-git-mirror)
基于第一步设置一个主repo并随手准备好
问：您的最终目标是拥有一个所有文件都在git中的干净core，这些文件存在于Magento安装文件中。这是必需的，以便您可以将所有内容与干净安装进行比较。管理核心更改、核心文件树(现有、不存在、添加的文件)。您可以通过.gitignore(排除媒体、缓存、具有特定服务器范围的所有文件local.xml .htaccess)来处理异常情况。我发现将Magento核心文件移出到不同的(非公共)目录中很容易(如此处所述：http://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento )，这将为我提供一个代码状态，在更新时.htaccess永远不会发生冲突。我也从版本控制中不包括媒体、缓存和Magento生成的所有临时文件。这将确保您在升级时拥有清晰的路径，因为您可以禁用所有内容以进行升级。稍后比较代码将给您需要审查的范围，并且您可以估计需要多长时间来比较更改部分并进行升级。
现在，在现有站点和配置下(使其可比较)，在您的代码库上执行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步中基于您的主repo检出您的测试仓库，然后检出一个以当前版本命名为“testsomething”或任何您需要的分支
从该checkout文件夹中删除所有内容，只留下.git，因此它是空的但仍存在版本控制。状态将如同每个文件都已删除，这在这里非常重要，因为基于此，您将知道您可能已在错误的站点上删除了哪些文件。
在评论中提问：我通常将忽略空格添加到git配置（可以是本地或全局范围），并让git为我处理。当我们在团队中工作时，我们总是遵循基于Zend标准：制表符使用4个空格，Unix样式的行尾和第3步中提到的git配置变量，并且如果涉及构建脚本，则使用提交挂钩进行代码格式化和验证。
将所有文件从您的“糟糕的Magento安装”（它们现在是可比较的）移动到空目录中（请注意，在使其可比较之后，已从现有站点中删除了.git目录），然后运行git status >changes.txt。此文件现在列出了您拥有的每个区别，任何新文件，任何已删除，重命名等文件，以及与您当前使用的干净Magento代码不同的文件。
根据评论说明：我通常执行git status --porcelain
要有一个.gitignore文件来帮助您放弃local.xml var/*或无需进行版本控制的每个文件/目录，以及.DS_Store，.Thumbs.db和您的IDE创建的项目文件。您不需要在版本控制中包含所有媒体和缓存文件以及每个服务器上都不同的文件。
然后，您应该仔细查看该列表，并基于该列表执行以下操作：
git checkout filename放弃核心中的更改）现在虽然情况仍不理想，但你现在处于以下状态：
现在您可以受益于版本控制、可比性和基于您的主干分支的单独分支，该分支包含可合并版本的Magento。因此，让我们尝试升级，以下是100%成功执行此操作的关键点。
第一步将是禁用所有现在已分离到app/code/local/Mage/和独立主题中的"废物"。如果您的核心清晰，主题可以禁用，则没有自定义代码干扰升级过程。所以，请继续禁用：
现在，如果您的存储库中的主干树已经标记或单独分支了所有重要版本，则升级到更高版本只需要一个命令：git merge" magento-vhateverthenextversionis"
如果您已经将第2步迭代到所需的Magento版本，则现在是时候吃下您继承的"翔"并执行以下操作：
如果您完成了上述步骤，那么您已经完成了大量的工作，取决于安装有多乱，可能需要几天时间。但是现在您拥有了一个干净的Magento核心，该核心已进行版本控制，合并和概述了分离的覆盖，并且所有内容都在单独的主题中，可以禁用。
有趣的部分是，如果下一个Magento升级可用，您可以轻松添加它并将其与主树进行比较，并向下合并更改，知道发生了什么更改并明确了要进行概述和测试的范围。
git init 然后再删除 .git 文件夹。
关于第六点）在这种情况下，您也可以执行类似于 git diff -p --diff-filter=M -b -w > modifications.txt 的操作来查看某些或所有文件的修改情况。您可以忽略此时可以忽略的空格，从而了解哪些文件已更改。 - Matthias Zeis我会先将网站复制到开发环境中。现在备份一份，以便随时恢复。同时，在此时我会将现场网站锁定代码状态，除非绝对必要（如果有更改，则必须在新的开发环境上进行复制）。
现在你可以使用一个安全的网站副本进行玩耍了。
第一件事是下载你正在运行的 Magento 最新版本的库存版本。在 /app/code/core 上对比库存版本和当前版本，以了解差异。我将尽可能保留你目前拥有的所有功能，并使核心程序重新排列。
希望到这一步，你已经有了一个相当干净的 Magento 安装。你可以考虑将它推回到现场服务器上，但我感觉你可能需要做很多调整，所以这可能不是可行的选择。
现在，我会为开发站点创建一个单独的备份，以便在需要时可以返回到此点。
现在，我将尝试在开发站点上升级。希望一切顺利，您在升级过程中没有任何问题。如果有的话，请进行必要的更正，并继续进行。
此时，您应该拥有一个与升级稳定的代码库。再次备份实时数据（只为安全起见），推送新代码，并希望一切顺利。