記事「MQL5 Algo Forgeへの移行（第2回）：複数のリポジトリの操作」についてのディスカッション
https://www.mql5.com/ja/articles/17698
マージする前に、MQL5 Algo Forge リポジトリの便利なインターフェイスで、もう一度すべての変更を視覚的に確認することができます。 不必要なコメント、誤って追加したファイル、最適でない変更点など です。要するに、これは一種の自己鍛錬なのだ。それに、正しいプロセスに慣れることで、この方法で作業する習慣が身につく（別のブランチを作成したり、コードレビューを行ったり......）。
著者が「MQL5 Algo Forgeリポジトリの便利なインターフェイスで変更を見る」ことを実演しなかった理由を推測してみよう。それは、diffが機能しないからです。diffが機能しない理由は、Gitがソースコードファイルをバイナリとみなしているからです。記事のスクリーンショットでも、それがわかります：
https://www.mql5.com/ja/articles/17698
article-17698-forge2 ブランチは develop ブランチにマージされ、削除さ れました：
サーバーからのみ削除され、MetaEditor（ローカルリポジトリ）からは削除されません。著者が誤って最も興味深いところで止めてしまったか、あるいは黙っていることを選んだ別の問題なのでしょう。
[ブレーキを付け忘れたスポーツカーの記事を書くようなものだ。時速300キロで走るのがいかに素晴らしいかを説明するが、壁や良い木にぶつからないと止まれないという事実は省く。作者が「MQL5 Algo Forgeリポジトリの便利なインターフェイスで変更を見る」ことを実演していない理由を推測してみよう。それは、diffが機能しないからです。diffが機能しない理由は、Gitがソースコードファイルをバイナリとみなしているからです。記事のスクリーンショットでも、それがわかります：
残念ながら、一度にすべてを行うことはできません。これは問題を隠そうとしているのではありません。簡単に修正できるとほぼ確信していたので、強調しなかったのだ。あるリポジトリファイルをUTF-8に変換してみました。MEでは、UTF-16 LEであったときと何の違いもなく開き、コンパイルすることができました。ウェブ・インターフェイスでは、違いが普通にわかるようになりました。一般的には、ソースコードファイルをバイナリとみなすGitではなく、Forgejoベースのウェブインターフェイスが、MetaEditorがデフォルトで使用していたUTF-16 LEエンコーディングのテキストファイルを扱うように設計されていないようです。
しかしMetaEditorのdiffは...。どうやら、UTF-16 LEしか使えないようです。UTF-8のファイルのロシア文字は正しく表示されず、すべての行末に違いがあるため、ファイル全体が変更されたとみなされてしまいます：
この記事を書く過程で、私はMEでdiffを使わなかった。MEにGitサポートが追加され、VS Codeをリポジトリとのすべての操作のために並行して実行し続けなければならなくなった間に、単純に使い慣れたからだ。だから記事にしなかったんだ。
MEにはまだリポジトリに関する問題が残っているからだ。しかし同時に、いずれ修正されると信じたい。それまでは、今あるものを使おう。
サーバーからのみ削除され、MetaEditor（ローカルリポジトリ）からは削除されない。作者が誤って最も興味深いところで止まってしまったか、あるいはこれは黙っておきたい別の問題なのだろう。
ご指摘ありがとうございます。確かに、リモートリポジトリからブランチを削除する場合、ローカルコンピュータ上のこのリポジトリのすべてのクローンから自動的に削除されるべきではないでしょう。ローカルリポジトリで個別に削除すべきです。これはすべてのGitベースのリポジトリに当てはまることなので、Algo Forgeの問題ではありません。
[編集] ブレーキを付け忘れたスポーツカーの記事を書くようなものです。時速300キロでいかに素晴らしい走りをするかは説明しても、壁や立派な木にぶつかったときにしか止まれないという事実は省く。
ああ、確かにそうだ！正直なところ、コーナーのたびにこんなにつまずくのは勘弁してほしい。走っているときはいいんだ。そして、ブレーキが不十分なところでは、外部ブレーキを使ってみる。
いいえ、Git自体はバイナリファイルをMetaEditorが時々保存するエンコーディングで考えます。forgejoもそのウェブインターフェイスも、これとは何の関係もありません。Git Bash for Windowsのリポジトリがその証拠です：
しかし、それにもかかわらず、UTF-16 LEエンコーディングのVS Codeでは、すべての違いが冷静に表示されます。まあ、Git自身はバイナリと呼んでいるのだが。
私たちが発見した 主な ことは、UTF-8に変換すると、Gitコンソールとウェブ・インターフェイスでは問題が解決されるということです（しかし、Diff MEでは別の問題があります）：
いいえ、Git自体はバイナリファイルをMetaEditorが時々保存するエンコーディングで考えます。forgejoもそのウェブインターフェイスも、これとは何の関係もありません。Git Bash for Windowsのリポジトリがその証拠です：
数日間頭を悩ませた結果、少なくとも「壊れた」ファイルのリストを埋める方法を見つけることができました。その方法は、コマンド
git ls-files --format='%(eolinfo:index) %(path)'
が"-text "を表示するという事実に基づいている：
しかし、このコマンドはインデックスしか見ていない（修正されたファイルや追跡されていないファイルは無視される）。私はeolinfoの特殊性を気にせず、愚かにもすべてのファイルを新しいリポジトリのインデックスに追加することにした。その結果、レンガ化される前に「壊れた」ファイルをチェックできるツールを作った。https://forge.mql5.io/boyvlad/mql-check-binary-surprises。
使用方法：コミットする前に、すべてのプロジェクトファイル（.gitフォルダとgitignoreファイルを除く）を別のフォルダにコピーし、その中でスクリプト（上にあげたリンク）を実行します。このスクリプトは、まず新しい git リポジトリを初期化してすべてのファイルをインデックスに追加すると、壊れたファイルをリストアップします。スクリプトはまず .git フォルダと gitignore ファイルが存在しないことを確認します。誤って作業ディレクトリのコピーではなく作業ディレクトリで起動してしまうことを防ぐためです。
使用例
エディターでの作業も含めて、段階的に修正していきます
改善の過程で、MetaEditorとウェブインターフェイスだけを使って、いくつかの原始的なブランチ戦略を何度か繰り返してみることをお勧めします。
- nextブランチを作成し、そこでいくつかのコミットを行う。
- nextをmainに流し、nextを削除する。
- 新しい親コミットで再度nextを作成し、数回コミット。
- ...
ポイント3は、外部ツールを使わないと今のところ不可能だ。つまり、ポイント2がサイトを通して行えるからといって、それが簡単になるわけではないのだ。
私はこの議論で新しいことは何も言っていない。私はすでに2、3ヶ月前にこのすべてを報告した。今、要点1と2をカバーする記事が出ようとしていますが、たまたま要点3はその記事にはありません（要点3は論理的な拡張ですが）。
ブランディングのないGitは、スープのないスープのようなものだ。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事「MQL5 Algo Forgeへの移行（第2回）：複数のリポジトリの操作」はパブリッシュされました:
最初の記事では、MetaEditorに内蔵されているSVNベースのMQL5 Storageから、より柔軟で現代的なソリューションであるGitバージョン管理システムに基づくMQL5 Algo Forgeへの移行を開始しました。この移行の主な理由は、複数のプロジェクトや単一プロジェクト内の異なる機能を同時に開発する際に、リポジトリのブランチ機能を十分に活用する必要があったということです。
移行作業は、新しいリポジトリをMQL5 Algo Forge上に作成することから始まりました。さらに、Visual Studio Codeを用いたローカル開発環境を準備し、必要なMQL5およびGitの拡張機能、ならびに補助ツールを導入しました。その後、標準ファイルや一時ファイルをバージョン管理から除外するために.gitignoreファイルをリポジトリに追加しました。既存のすべてのプロジェクトは専用のarchiveブランチにアップロードし、過去に作成されたコードを保存するアーカイブ領域としました。一方で、mainブランチは空のままとし、新規プロジェクト用ブランチを整理するための基盤としました。こうして、異なるプロジェクトのコードをリポジトリの複数のブランチに分散できる仕組みを整えたのです。
作者: Yuriy Bykov