文章 "迁移至 MQL5 Algo Forge（第 2 部分）：使用多个存储库" - 页 2

新评论
 
Vladislav Boyko #:

我建议你在改进过程中，仅使用 MetaEditor 和 Web 界面尝试执行一些原始分支策略的迭代。

  1. 创建分支 next，在那里进行几次提交
  2. 将 next 注入主分支，删除 next
  3. 用新的父提交再次创建 next，并提交了几次。
  4. ...

如果不使用外部工具，第 3 项目前是不可能实现的。因此，尽管第 2 项可以通过网站完成，但这并不会让它变得更容易，因为它是一个死胡同。

在这次讨论中，我并没有说什么新东西--几个月前我已经报告过这些。现在有一篇文章描述了第 1 和第 2 点，但不知何故，第 3 点恰好不在文章中（尽管第 3 点是逻辑上的延续）。

之所以没有第 3 点，是因为我更喜欢不同特征的分支有不同的名称，而不总是相同的名称（下一个）。按照你的方法，我不明白为什么要删除 next？它的含义似乎与主/开发捆绑包中的开发分支类似，在按顺序添加功能时用于开发每个新功能。

 
Vladislav Boyko #:

经过几天的头脑风暴，我终于找到了一种方法，至少可以填满 "损坏 "的文件列表。

是的，我还曾一度尝试用脚本清除公共资源库中的所有编译文件，但事实证明，这样做很快就没有必要了。由于我不使用网络接口来处理文件差异，所以他们不在那里显示内容对我来说并不重要。因此，找出 "损坏 "文件的列表是可能的，但为什么呢？如果已经知道它们都是由 ME 创建的文件（UTF-16 LE 编码），那就是除了 README.md、.gitignore 和其他几个文件之外的所有版本库文件。

 
Yuriy Bykov #:

雷纳特，你能告诉我将所有源代码转换为UTF-8是否合理，还是 ME 将继续只面向 UTF-16 LE？我想在新版本的分支或其他地方有提到过要过渡到UTF-8，但也许看起来是这样？

哦，我刚刚在 ME 中创建了一个新文件（New Class），所以它是立即以 UTF-8 格式创建的。

 
Yuriy Bykov #:
我不明白你为什么要删除下一个分支？

我总是在一个分支完全合并到一个稳定性更高的分支后立即删除它。这是一种习惯，而且我确信这是一种非常有用的习惯。

从纯粹的技术层面来说，重建一个分支往往会以父级提交（下一次提交的父级提交）的形式带来明显的不同。有时这并不重要，只会影响提交图的可用性，而有时不重建就不行。

编辑

总的来说，我觉得有必要从本地仓库删除分支的说法很奇怪。鉴于 Git 的分支模型是其杀手锏，而且 Git 鼓励频繁创建、删除和合并分支。

 
Yuriy Bykov #:
由于我不使用网络接口来处理文件差异，他们不在那里显示内容对我来说并不重要。

我也很少使用网页界面。我也不使用 MetaEditor 中的任何 Git 按钮。我用 Windows 版的 Git Bash 在终端上查看，这对我来说已经足够方便了。

Yuriy Bykov#:
所以你可以找到 "损坏 "文件的列表，但为什么呢？

了解损坏文件列表是为了修复它们。要修复它们，才能查看 diff。

diff 有什么用？[删除一个不重要的句子，它给自动翻译带来了麻烦]。

 
Yuriy Bykov #:
如果已经知道这些都是由 ME 创建的文件（采用 UTF-16 LE 编码）

几个月前我测试过这个问题。向导创建的是UTF-8（正常文件，而非损坏文件）。甚至 MT4 向导创建的文件也是正常的。在这些测试中，我从未从向导中获得过 "损坏 "文件。

我有时会在提交前用该脚本 检查文件。事实证明，这并不是白费力气--在某些情况下，正常文件会突然改变编码。也许是从剪贴板插入了什么东西之后，我也不确定。西里尔字母不太可能出现在文件中--我很久以前就放弃在注释中使用西里尔字母了。

 
Vladislav Boyko #:
西里尔字母几乎不存在--我甚至很久以前就放弃在评论中使用它了。

显然，我错了。我刚刚在 .mq5 文件中添加了UTF-8 编码：

// 西里尔文

保存后，文件编码变为 "UTF-16 LE BOM"。

看来是 MetaEditor 的错。我添加了西里尔字符，然后用 Notepad++ 保存文件，编码仍然是 UTF-8。

 
Vladislav Boyko #:

我还觉得奇怪的是，为什么要从本地仓库删除分支呢？鉴于 Git 的分支模型是它的杀手锏，而且 Git 鼓励频繁创建、删除和合并分支。

所以我也赞成在分支与主分支合并后删除它们。只是我第一次听说，在删除之后，他们会为新的剪辑创建一个同名的分支，而不是一个新的分支。

观察差异的目的是什么？

是的，这是非常必要的。我也在积极使用它，但仅限于 VS Code。奇怪的是，尽管我查看了编码 "糟糕 "的文件，但并没有出现崩溃现象。

我有时会在提交 前用 该脚本 检查文件。事实证明，这并不是无缘无故的--在某些情况下，正常的文件会突然改变编码。也许是从剪贴板插入了什么东西之后，我也不确定。

我从没遇到过这种情况。这也太出乎意料了。也许是因为同时使用不同的 ME 版本来处理相同的文件而导致正常文件损坏？我不知道...

我查看了提交历史，发现两个月前添加的文件确实已经使用了UTF-8编码，而三个月前添加的文件仍然是UTF-16 LE。很显然，在那段时间里，有一次改用了 UTF-8 编码。

 
Vladislav Boyko #:

我想我错了。我刚刚在 .mq5 文件中添加了UTF-8 编码：

并在保存后将文件编码更改为 "UTF-16 LE BOM"。

看来是 MetaEditor 的错。我添加了西里尔字符，然后用 Notepad++ 保存文件，编码仍然是 UTF-8。

我确认，添加俄文字母并保存文件后，编码从 UTF-8 变为 UTF-16 LE。如果删除所有俄文字母并保存，编码仍为 UTF-16 LE。

 
Vladislav Boyko #:
这似乎是 MetaEditor 的错。

这里有一个证明，可以让 UTF-8、西里尔文和 Git 兼容：

https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea

只需要求 MetaEditor 不要更改文件编码即可。

123
新评论