迁移至 MQL5 Algo Forge（第 2 部分）：使用多个存储库·综合运用
◍ 在 Algo Forge 里用 PR 收口单次改动
MQL5 Algo Forge 的拉取请求机制和 GitHub、GitLab 那套思路一致：它并非 Git 原生功能，而是在版本控制之上加的一层协作壳，核心作用是把『分支改完了，请并入主线的』这个动作标准化。对多数独自写 EA/指标的 MQL5 作者来说，PR 最实在的用处不是等别人审，而是给自己做一次合并前的可视化自检。 典型单机流程可以这样走：先拉平本地 develop，从它切出带明确任务名的分支（例如 article-17698-forge2），改完并提交；到网页端『拉取请求』页点红色大按钮，选好目标分支、填描述、指定审阅者为自己，便生成 PR。由于没人跟你 pair，审阅讨论阶段直接跳过。 合并时通常有三种选法：合并提交会保留整条分支历史；压缩并合并把零碎提交压成单笔，避免『改错别字』之类噪音；重新定基则把提交重放到目标分支上形成线性记录。我们选第一种，因为想留全提交轨迹，随后勾掉临时分支——历史里仍看得到它存在过，但仓库分支列表不会被废弃线搞脏。 哪怕你一个人维护仓库，开 PR 再合并也是值得养成的纪律。合并前那页差异视图常能揪出提交时漏掉的散文件、废注释或非最优编辑；顺带把『分支—自审—并入』的肌肉记忆练熟，以后真进团队不至于懵。外汇与贵金属算法交易本身高风险，工程习惯的严谨度直接影响策略迭代的可靠性。
单人仓库里也该走 PR 流程
在 MQL5 策略仓库只有你一个人的时候，向自己提交 Pull Request 并不是多此一举。对于一次改几行指标的快速修复，直接 git merge 进主分支没问题；但凡是涉及 EA 逻辑重构、参数体系调整这类较大改动，开 PR 再合并能逼你二次审视代码，降低把错误信号逻辑带进实盘的概率。 实际经验里，单人项目走 PR 后，回看提交记录能更清楚哪次改动引入了滑点异常或重算 bug。这种纪律性在外汇、贵金属这类高杠杆、高波动品种上尤其值钱，一次未察觉的逻辑回退可能让策略在极端行情中连续错单。 所以别把 PR 当成团队协作的专利。本地分支改完推上去，自己 review 一遍再合，相当于给 MT5 上的策略上了道自检闸。
「跨仓库复用只是起点」
个人存储库到项目库的克隆与改进路径已经跑通：同一用户持有项目和库时，把外部仓库当库引用、改完再提交，下一步开发就能直接复用。这套流程在 MT5 的 Algo Forge 环境里已经具备基础条件。 但只覆盖了自己同时管两个库的场景。若项目方想引别人的社区仓库做库，权限与依赖处理并不简单——而这恰恰是新仓库系统鼓励协作的既定目标之一。 基础已经铺好，剩下跨所有者复用的坑留到后续。外汇与贵金属自动化涉及高杠杆高风险，任何仓库工作流改动都先在模拟环境验证再上实盘。