文章 "迁移至 MQL5 Algo Forge（第 2 部分）：使用多个存储库"
https://www.mql5.com/zh/articles/17698
在合并之前，我们可以在 MQL5 Algo Forge 版本库的便捷界面上再次直观地查看所有更改。在这种有目的的检查过程中，我们有时会注意到一些在提交过程中漏掉的东西：不必要的注释、意外添加的文件、不理想的更改。从本质上说，这是一种自律。此外，习惯了正确的流程，也就养成了以这种方式工作的习惯（创建独立分支、代码审查......）。
让我猜猜为什么作者没有演示"在 MQL5 Algo Forge 代码库的便捷界面中查看更改"。因为作者做不到，因为 diff 无法工作。diff 失效的原因是 Git 将源代码文件视为二进制文件。您甚至可以从文章的截图中看到这一点：
https://www.mql5.com/zh/articles/17698
合并过程到此结束：article-17698-forge2 分支 合并到develop 分支并删除：
它只从服务器上删除，但不会从 MetaEditor（本地版本库）上删除。要么是作者不小心停在了最有趣的地方，要么是他们选择保持沉默的另一个问题。
[这就像写一篇关于跑车的文章，却忘了加刹车。描述它时速 300 公里是多么美妙，但却忽略了只有撞到墙或好树才能停下来的事实。让我猜猜为什么作者没有演示"在 MQL5 Algo Forge 版本库的便捷界面中查看更改"。因为作者做不到，因为 diff 不起作用。diff 失效的原因是 Git 将源代码文件视为二进制文件。您甚至可以从文章的截图中看到这一点：
遗憾的是，你不可能一次搞定所有事情。这并不是想掩盖问题。我几乎可以肯定，这个问题很容易解决，所以我没有强调。现在我做了一个实验--将一个版本库文件转换为 UTF-8。在 ME 中，它的打开和编译与UTF-16 LE 版本没有任何区别。在网页界面上，你现在可以正常看到差异。一般来说，并不是 Git 把源代码文件视为二进制文件，而是基于 Forgejo 的网页界面设计不适合处理 UTF-16 LE 编码的文本文件，而 MetaEditor 默认使用 UTF-16 LE 编码。
但 MetaEditor 中的 diff 是....。显然，它只能使用UTF-16 LE编码--UTF-8编码文件中的俄文字母无法正确显示，而且由于所有行末的差异，整个文件都被视为已更改：
在写这篇文章的过程中，我没有在 ME 中使用 diff，因为...在 ME 添加 Git 支持的时候，我已经习惯了使用它，而且必须保持 VS Code 并行运行才能完成所有与版本库的操作。这也是我没有把它写进文章的原因。
我试图提出其他方法是有原因的，因为到目前为止，ME 在版本库方面仍然存在问题。但与此同时，我也相信这些问题会得到及时解决。与此同时，让我们利用现有的一切吧。
感谢您的评论。的确，从远程版本库中删除分支时，它不应该从本地计算机上该版本库的所有克隆中自动删除。它应该在本地版本库中单独删除。所有基于 Git 的版本库都是如此，所以这不是 Algo Forge 的问题。
[编辑] 这就好比写一篇关于跑车的文章，却忘了加刹车。描述它以每小时 300 公里的速度行驶有多么美妙，却忽略了只有撞墙或撞树才能停下来的事实。
哦，那是肯定的！虽然老实说，我更希望不要在每个弯道都这样跌跌撞撞。能开就好。在制动不够的地方，我们会尝试使用外部制动器。
不，Git 本身认为二进制文件的编码与 MetaEditor 有时保存它们的编码相同。forgejo 和它的网页界面都与此无关。证据就在 Windows 版 Git Bash 的版本库中：
在绞尽脑汁想了几天之后，我终于找到了一种至少能填满 "损坏 "文件列表的方法。这个方法基于命令
git ls-files --format='%(eolinfo:index) %(path)'
显示"-text"：
但该命令只查看索引（已修改和未跟踪的文件会被忽略）。我没有理会 eolinfo 的特殊性，决定愚蠢地将所有文件添加到新版本库的索引中。因此，我做了一个工具，可以在文件变砖之前检查它们是否 "坏了"：https://forge.mql5.io/boyvlad/mql-check-binary-surprises。
使用逻辑：在提交之前，将所有项目文件（.git 文件夹和 gitignore 文件除外）复制到一个单独的文件夹，然后运行其中的脚本（链接见上文）。在初始化新的 git 仓库并将所有文件添加到索引后，脚本会列出损坏的文件。脚本首先会确保 .git 文件夹和 gitignore 文件不存在--以防不小心在工作目录而非其副本中启动。
使用示例
我们将逐步修复，包括在编辑器中工作
在改进过程中，我建议您尝试仅使用 MetaEditor 和 Web 界面执行一些原始分支策略的迭代。
- 创建分支 next，在那里进行几次提交
- 将 next 注入主分支，删除 next
- 用新的父提交再次创建 next，提交几次。
- ...
如果不使用外部工具，第 3 点目前是不可能实现的。因此，虽然第 2 点可以通过网站完成，但这并不会让它变得更容易，因为它是一个死胡同。
在这次讨论中，我没有说任何新东西--几个月前我已经报告过这些。现在有一篇文章即将发表，其中涵盖了第 1 和第 2 点，但恰巧第 3 点不在文章中（尽管第 3 点是逻辑上的延伸）。
没有品牌的 Git 就像没有肉汤的汤
新文章 迁移至 MQL5 Algo Forge（第 2 部分）：使用多个存储库已发布：
在第一篇文章中，我们开始从 MetaEditor 中内置的基于 SVN 的 MQL5 存储过渡到基于 Git 版本控制系统的更灵活、更现代的解决方案：MQL5 Algo Forge 。采取这一步骤的主要原因是，在处理多个项目或单个项目中的不同功能时，需要充分利用存储库分支。
转换始于在 MQL5 Algo Forge 中创建一个新的存储库，并使用 Visual Studio Code 设置本地开发环境，以及必要的 MQL5 和 Git 扩展和支持工具。然后，我们将 .gitignore 文件添加到存储库中，以从版本控制中排除标准和临时文件。所有现有项目都上传到专用 archive 分支，作为所有以前编写的代码的档案存储。main 分支留空，准备组织新的项目分支。通过这种方式，我们为在存储库的不同分支中分发不同的项目代码奠定了基础。
作者：Yuriy Bykov