文章 "MQL5 Algo Forge 入门" - 页 2

[Yuriy Bykov]

Fernando Carreiro #:

不！"分叉 "和 "克隆 "不是一回事。请不要混淆这两个概念

它们是不同的概念，但我仍然认为你没有完全理解所提议的机制的可能性，即获得使用他人版本库的能力。但我现在还不能确定，因为我想先在实践中测试一下。

[Fernando Carreiro]

@Yuriy Bykov #:  它们是不同的概念，但我仍然认为你没有完全理解所提议的机制的可能性，即获得与他人的版本库协同工作的能力。但我现在还不能确定，因为我想先在实践中测试一下。

我完全理解！

我想使用 "克隆 "而不是 "fork "的原因是 不是 而是因为我想 "跟踪 "原作品和未来的更新，并在有新的 "提交 "时得到通知，然后我就需要 "拉取 "这些 "提交"。这就是 "克隆 "功能存在的原因。

因此，MetaQuotes 不应该推广 "分叉"，然后用 "克隆 "将其拉进来。应该是 "fork"，然后是 "pull"，而不是 "clone"。他们混淆了不同的功能。

编辑：如果 MetaQuotes 坚持实施 "残缺 "的 Git 解决方案，并称其为 "功能"，那么最终结果将比之前的 SVN 方法更糟。

[Yuriy Bykov]

我的意思是，在本地机器上克隆一个仓库时，从原始仓库克隆和从一个新的分叉仓库克隆（在文件组成和提交历史上）并无区别。

Git 文档介绍了 如何将原始仓库的更新导入克隆的分叉仓库。这至少需要通过命令行界面掌握基本的仓库技能。因此， 事实上，更新本地克隆代码的功能是存在的。不过，要只使用 MetaEditor 创建本地克隆，必须在用户配置文件中创建原始版本库的 fork。只有在创建分叉后，其名称才会出现在 MetaEditor 的共享项目列表中。

一般来说，我不太喜欢这种方法。毕竟，如果我们不打算对别人的版本库进行编辑，就不需要分叉，克隆原始版本库就足够了。在这种情况下，fork 就是在我们的版本库列表中增加一个 "额外 "项目。根据我的理解，当我们计划对原始版本库中的代码进行修改时，我们就会创建一个 fork，而且我们并不指望这些修改会从我们的 fork 转移到原始版本库中（尽管通过 Pull Request 有这种可能性）。

站在 MetaQuotes 开发者的立场上，我们可以为克隆的其他版本库单独添加一个固定名称的文件夹，比如 "其他共享项目"。但这个方案也有自己的缺点，所以可能比目前的解决方案更糟糕。我现在还想不出更好的方案。也许 MetaEditor 的功能将来会得到扩展，届时我们会看到其他解决方案。

我想测试一下更新的功能。因此，我创建了您的FMIC 代码库的分叉，并将其添加到我的观察列表和收藏夹中。我会等待您的下一次提交，看看如何才能找到它，以便尝试更新 fork。

[Fernando Carreiro]

@Yuriy Bykov #:  我想测试一下更新的功能。这就是为什么我创建了您的FMIC 仓库的 fork，并将其添加到我的观察列表和收藏夹中。我会等待您的下一次提交，看看如何才能找到它，以便尝试更新 fork。

作为测试，我添加了Heikin Ashi 出版物的说明，作为 Markdown README 文件，并提交到了版本库。

请查看您是否收到了更改通知，以及您是否能够更新分叉。

[Fernando Carreiro]

@Yuriy Bykov #:  例如，我们可以设身处地地为 MetaQuotes 开发人员着想，为克隆其他版本库的项目添加一个具有固定名称的单独文件夹，如 "其他共享项目"。但这个方案也有自己的缺点，所以可能比目前的解决方案更糟糕。我现在还想不出更好的方案。也许 MetaEditor 的功能将来会得到扩展，届时我们会看到其他解决方案。

MetaEditor 也无法提交 JPG 图像文件或其他任何它认为 "无法识别 "的文件类型，但我可以使用外部 Git 客户端提交它们。

PS！AlgoForge 基于开源的ForgeJo 软件。

[Yuriy Bykov]

Fernando Carreiro #:

作为 测试，我将 Heikin Ashi 出版物的描述添加为 Markdown 格式的 README 文件，并将其提交到版本库。

请检查您是否已收到此更改的通知，以及是否可以更新 fork。

我在版本库的 Web 界面看到了这一点：

我稍后会尝试更新分叉

[Yuriy Bykov]

Fernando Carreiro #:

作为 测试，我将 Heikin Ashi 出版物的描述添加为 Markdown 格式的 README 文件，并将其提交到版本库。

请检查您是否已收到此更改的通知，以及是否可以更新 fork。

首先，我的本地 fork 克隆还没有最新的提交：

根据 Git 文档，连接原始仓库：

我进入分叉的网页界面，看到了这个：

我点击了 "同步 "按钮，然后在 MetaEditor 中做了一次 Pull：

如你所见，你的所有提交都安全地保存在分叉库中，然后在我本地电脑上的克隆分叉库中进行拉取。

在这个 文档页面上还有其他使用控制台命令同步的方法，但我还没有测试过，因为所有提交都已经同步了。

我稍后会做更多实验，看看 MetaEditor 中的提交和推送命令在分叉中的表现如何。不知道它是否也会尝试将编辑发送到原始版本库。

[Fernando Carreiro]

@Yuriy Bykov #:

首先，我的本地分叉克隆还没有最新的提交：

根据 Git 文档，连接原始仓库：

我进入分叉版的网页界面，看到如下内容：

我点击 "同步 "按钮，然后在 MetaEditor 中进行拉取：

正如你所看到的，你的所有提交都安全地保存在分叉中，然后在我本地电脑上的克隆分叉中进行拉取。

在文档的这 一页，还有其他使用控制台命令同步的方法，但我没有测试过，因为所有提交都已经同步了。

这一切都很好，但你已经证明了我的观点，即 "克隆 "和 "分叉 "是不一样的，而且 MetaQuotes 采用的方法需要在 MetaEditor 之外进行额外干预，才能同步项目。

更不用说 "分叉 "还需要 AlgoForge 服务器上的额外存储空间，而 "克隆 "则不需要额外的存储空间或额外的步骤。

，我认为 MetaQuotes 的实现太 "有缺陷"，无法有效使用，因此我将继续使用外部 Git 客户端或 VSCode（它在 AlgoForge 上运行良好，没有任何问题）。

[Vladislav Boyko]

Fernando Carreiro #:
我认为 MetaQuotes 的实现太 "有缺陷"，无法有效使用，因此将继续使用外部 Git 客户端，或使用 VSCode（它在 AlgoForge 上运行良好，没有任何问题）。

我们很高兴欢迎您加入我们的外部 Git 客户端用户社区！😁.

[Yuriy Bykov]

Fernando Carreiro #:

我发现 MetaQuotes 的实现太 "有缺陷"，无法有效使用，因此将继续使用外部 Git 客户端或 VSCode（它在 AlgoForge 上运行良好，没有任何问题）。

不幸的是，目前情况确实如此。我现在也倾向于使用外部客户端。但如果比较一下 MetaEditor 在过去 5 个月中的新增功能，就会发现进步非常明显。只是以前根本没有与新版本库协同工作的工具，而现在至少有了这样一个缩小版。