"MQL5 Algo Forge'a Geçiş (Bölüm 2): Birden Fazla Depo ile Çalışma" makalesi için tartışma
https://www.mql5.com/tr/articles/17698
Birleştirmeden önce , MQL5 Algo Forge deposunun kullanışlı arayüzündeki tüm değişiklikleri bir kez daha görsel olarak inceleyebiliriz. Böyle amaçlı bir kontrol sırasında, bazen taahhütler sırasında kaçan şeyleri fark etmeyi başarırız: gereksiz yorumlar, yanlışlıkla eklenen dosyalar, optimal olmayan değişiklikler. Özünde, bu bir çeşit öz disiplin. Ayrıca, doğru süreçlere alışmak, bu şekilde çalışma alışkanlığını geliştirir (ayrı bir dal oluşturma, kod gözden geçirme, ...).
Yazarın neden"MQL5 Algo Forge deposunun kullanışlı arayüzünde değişiklikleri görüntü lemeyi" göstermediğini tahmin edeyim. Çünkü yazar bunu yapamaz, çünkü diff çalışmıyor. Diff'in çalışmamasının nedeni Git'in kaynak kod dosyalarını ikili olarak kabul etmesidir. Bunu makaledeki ekran görüntüsünde bile görebilirsiniz:
https://www.mql5.com/tr/articles/17698
Bu işlem birleştirme işlemini tamamlar:article-17698-forge2 dalı develop dalıyla birleştirilirve silinir:
Yalnızca sunucudan kaldırılıyor, ancak MetaEditor'den (yerel depo) kaldırılmıyor. Ya yazar yanlışlıkla en ilginç noktada durdu ya da sessiz kalmayı seçtikleri başka bir sorun.
[Frenleri eklemeyi unutmuş bir spor araba hakkında bir makale yazmak gibi. Saatte 300 km hızla ne kadar harika gittiğini anlatın, ancak sadece bir duvara ya da iyi bir ağaca çarptığınızda durabileceğiniz gerçeğini atlayın.Yazarın neden"MQL5 Algo Forge deposunun kullanışlı arayüzündeki değişiklikleri görüntülemeyi" göstermediğini tahmin edeyim. Çünkü yazar bunu yapamıyor çünkü diff çalışmıyor. Diff'in çalışmamasının nedeni Git'in kaynak kod dosyalarını ikili olarak kabul etmesidir. Bunu makaledeki ekran görüntüsünde bile görebilirsiniz:
Ne yazık ki her şeyi aynı anda yapamazsınız. Bu, sorunu gizleme çabası değildir. Kolayca düzeltilebileceğinden neredeyse emindim, bu yüzden vurgulamadım. Şimdi bir deney yaptım - bir depo dosyasını UTF-8'e dönüştürdüm. ME'de UTF-16 LE'de olduğundan herhangi bir fark olmadan açılıyor ve derleniyor. Web arayüzünde, artık farklılıkları normal olarak görebilirsiniz. Genel olarak,kaynak kod dosyalarını ikili olarak gören Git değil, daha çok Forgejo tabanlı web arayüzü, MetaEditor'un varsayılan olarak kullandığı UTF-16 LE kodlamasındaki metin dosyalarını işlemek için tasarlanmamış gibi.
Ancak MetaEditor'daki diff.... Görünüşe göre, sadece UTF-16 LE kullanabiliyor - UTF-8'deki bir dosyanın Rusça harfleri doğru görüntülenmiyor ve tüm satırların sonundaki farklılıklar nedeniyle tüm dosya değiştirilmiş olarak kabul ediliyor:
Makaleyi yazma sürecinde ME'de diff kullanmadım, çünkü... ME Git desteği eklerken kullanmaya alıştım ve VS Code'u depoyla yapılan tüm işlemler için paralel olarak çalıştırmak zorunda kaldım. Bu yüzden makaleye girmedi.
Alternatif yollar önermeye çalışmamın bir nedeni var, çünkü şu ana kadar ME'nin depolarla ilgili hala sorunları var. Ama aynı zamanda bunların zaman içinde düzeltileceğine inanmak istiyorum. Bu arada, elimizdekileri kullanalım.
Sadece sunucudan kaldırılıyor, ancak MetaEditor'den (yerel depo) kaldırılmıyor. Ya yazar yanlışlıkla en ilginç yerde durdu ya da bu da sessiz kalmayı tercih ettikleri başka bir sorun.
Açıklama için teşekkürler. Gerçekten de, uzak bir depodan bir dal silinirken, bu deponun yerel bilgisayarlardaki tüm klonlarından otomatik olarak silinmemelidir. Yerel depolarda ayrı olarak silinmelidir. Bu tüm Git tabanlı depolar için geçerlidir, bu yüzden bu bir Algo Forge sorunu değildir.
[Bu, fren eklemeyi unutmuş bir spor araba hakkında bir makale yazmak gibidir. Saatte 300 km hızla ne kadar harika gittiğini anlatın, ancak yalnızca bir duvara ya da güzel bir ağaca çarptığınızda durabileceğiniz gerçeğini atlayın.
Kesinlikle öyle! Sürüş olağanüstü) Yine de dürüst olmak gerekirse, her virajda böyle tökezlememeyi tercih ederdim. Yolda olmak güzel. Ve frenlerinin yeterli olmadığı yerlerde, harici frenler kullanmaya çalışacağız.
Genel olarak,kaynak dosyalarını ikili olarak değerlendiren Git değil, daha çok Forgejo tabanlı web arayüzünün MetaEditor tarafından kullanılan varsayılan kodlama olan UTF-16 LE kodlamasındaki metin dosyalarını işlemek için tasarlanmamış olmasıdır.
Hayır, Git'in kendisi ikili dosyaları MetaEditor'un bazen kaydettiği kodlama ile değerlendirir. Ne forgejo'nun ne de web arayüzünün bununla bir ilgisi yoktur. Kanıt, Windows için Git Bash'teki deponuzda:
Hayır, Git'in kendisi ikili dosyaları MetaEditor'un bazen kaydettiği kodlama ile değerlendirir. Ne forgejo'nun ne de web arayüzünün bununla bir ilgisi yoktur. Kanıt, Windows için Git Bash'teki deponuzda:
Ancak buna rağmen VS Code UTF-16 LE kodlamasında bile tüm farklılıkları sakince gösterir. Git'in kendisi bunlara ikili diyor.
Öğrendiğimiz en önemli şey , UTF-8'e dönüştürdükten sonra sorunun Git konsolunda ve web arayüzünde çözüldüğüdür (ancak Diff ME'de başka bir sorun var):
Hayır, Git'in kendisi ikili dosyaları MetaEditor'un bazen kaydettiği kodlama ile değerlendirir. Ne forgejo'nun ne de web arayüzünün bununla bir ilgisi yoktur. Kanıt, Windows için Git Bash'teki deponuzda:
Birkaç gün kafa patlattıktan sonra, en azından "bozuk" dosyalar listesini doldurmanın bir yolunu bulmayı başardım. Yöntem şu komuta dayanıyor
git ls-files --format='%(eolinfo:index) %(path)'
onlar için "-text" görüntüler:
Ancak bu komut yalnızca dizine bakar (değiştirilmiş ve izlenmemiş dosyalar yok sayılır). Eolinfo'nun özellikleriyle uğraşmadım ve aptalca bir şekilde tüm dosyaları yeni deponun dizinine eklemeye karar verdim. Sonuç olarak, "bozuk" dosyaları tuğlalanmadan önce kontrol etmenizi sağlayan bir araç yaptım: https: //forge.mql5.io/boyvlad/mql-check-binary-surprises.
Kullanım mantığı: işlem yapmadan önce, tüm proje dosyalarını (.git klasörü ve gitignore dosyası hariç) ayrı bir klasöre kopyalayın ve betiği (yukarıda bağlantısını verdiğim) içinde çalıştırın. Betik, önce yeni bir git deposu başlatıp tüm dosyaları dizine ekledikten sonra bozuk dosyaları listeleyecektir. Betik ilk olarak .git klasörünün ve gitignore dosyalarının mevcut olmadığından emin olacaktır - bir kopyası yerine yanlışlıkla çalışma dizininde başlatmaya karşı koruma.
Örnek kullanım:
Editörde çalışmak da dahil olmak üzere adım adım düzelteceğiz
İyileştirme sürecinde, sadece MetaEditor ve web arayüzünü kullanarak bazı ilkel dallanma stratejilerinin birkaç iterasyonunu gerçekleştirmeyi denemenizi öneririm.
- Sonra şube oluşturun, orada birkaç değişiklik yapın
- Sonraki öğeyi ana öğeye dökün, sonraki öğeyi silin
- Yeni bir üst commit ile bir sonraki tekrar oluşturuldu, birkaç commit yapıldı.
- ...
Harici araçlar kullanmadan 3. nokta şu anda imkansız. Dolayısıyla 2. noktanın site üzerinden yapılabiliyor olması bunu kolaylaştırmıyor, çünkü bu bir çıkmaz sokak.
Bu tartışmada yeni bir şey söylemedim - tüm bunları birkaç ay önce zaten bildirmiştim. Şimdi 1. ve 2. noktaları kapsayan bir makale yayınlanıyor, ancak 3. nokta makalede yer almıyor (3. nokta mantıksal bir uzantı olmasına rağmen).
Markasız Git, çorbasız et suyu gibidir
Editördeki çalışma da dahil olmak üzere adım adım düzelteceğiz
Renat, bana tüm kaynakları UTF-8'e dönüştürmenin mantıklı olup olmadığını söyleyebilir misin yoksa ME sadece UTF-16 LE'ye odaklanmaya devam edecek mi? Sanırım yeni yapıların dallarında veya başka bir yerde UTF-8'e geçişten bahsediliyordu, ama belki de öyle görünüyordu?
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Yeni makaleye göz atın: MQL5 Algo Forge'a Geçiş (Bölüm 2): Birden Fazla Depo ile Çalışma.
İlk makalede, MetaEditor'daki yerleşik SVN tabanlı MQL5 Storage’dan Git sürüm kontrol sistemine dayalı daha esnek ve modern bir çözüme geçmeye başladık: MQL5 Algo Forge. Bu adımın ana nedeni, birden fazla proje üzerinde veya tek bir proje içindeki farklı işlevler üzerinde çalışırken depo dallarından tam olarak yararlanma ihtiyacıydı.
Geçiş, MQL5 Algo Forge'da yeni bir deponun oluşturulması ve gerekli MQL5 ve Git uzantıları ve destekleyici araçlarla birlikte Visual Studio Code kullanılarak yerel bir geliştirme ortamının kurulmasıyla başladı. Daha sonra standart ve geçici dosyaları sürüm kontrolünden hariç tutmak için depoya bir .gitignore dosyası ekledik. Mevcut tüm projeler, daha önce yazılmış tüm kodların arşiv deposu olarak tahsis ettiğimiz archive dalına yüklendi. main dalı boş bırakıldı ve yeni proje dallarının düzenlenmesi için hazırlandı. Bu şekilde, farklı proje kodlarını deponun ayrı dallarına dağıtmanın temelini attık.
Yazar: Yuriy Bykov