MQL5 Algo Forge'a Geçiş (Bölüm 4): Sürümlerle Çalışma

Giriş

MQL5 Algo Forge'a geçişimiz devam ediyor. İş akışımızı kişisel depolarla kurduktan sonra, MQL5 Algo Forge'a geçmemizin ana nedenlerinden biri olan topluluk katkılı kodu kolayca kullanabilme becerisine yöneldik. Bölüm 3'te, başka bir depodaki herkese açık bir kütüphaneyi kendi projemize nasıl ekleyeceğimizi araştırdık.

SmartATR kütüphanesini SimpleCandles Uzman Danışmanına bağlama girişimi, özellikle kod değişiklik gerektirdiğinde basit klonlamanın her zaman uygun olmadığını açıkça göstermiştir. Bunun yerine, uygun iş akışını izledik: hataları düzeltmek ve değişiklikler yapmak için başka birinin deposunun kişisel kopyamız haline geldiği bir çatal oluşturduk. Gelecekte bu değişiklikleri bir “Pull talebi” aracılığıyla yazarın kullanımına sunma imkanımız da olacaktır.

MetaEditor arayüzünde karşılaştığımız bazı sınırlamalara rağmen, bunu MQL5 Algo Forge web arayüzü ile birleştirmek, klonlamadan düzenlemelerin commit edilmesine ve son olarak projenin harici bir kütüphaneyle bağlanmasına kadar tüm eylem zincirini başarıyla tamamlamamızı sağladı. Böylece, belirli bir görevi çözdük ve herhangi bir üçüncü taraf bileşeni entegre etmek için evrensel bir şablonu inceledik.

Bu makalede, ister bir projeye yeni işlevsellik eklemek ister keşfedilen bir sorunu düzeltmek olsun, eksiksiz bir çözüm oluşturan belirli bir dizi değişiklik olan depoda yapılan düzenlemelerin yayınlanması aşamasına daha yakından bakacağız. Bu, yeni bir ürün sürümünü commit etme veya yayınlama sürecidir. Bu sürecin nasıl organize edileceğini ve MQL5 Algo Forge'un bunun için hangi yetenekleri sağladığını göreceğiz.

Dal bulma

Önceki bölümlerde, belirli bir görevi yerine getiren düzenlemeler yapmak için ayrı bir depo dalı kullanmanızı önermiştim. Ancak, böyle bir dal üzerindeki çalışmayı tamamladıktan sonra, onu başka bir (ana) dalla birleştirmek ve ardından silmek en iyisidir. Aksi takdirde, depo hızla sahibinin bile kolayca kaybolabileceği bir karmaşaya dönüşebilir. Bu nedenle, eski dallar kaldırılmalıdır. Ancak bazen, kodu belirli bir dal silinmeden hemen önceki durumuna geri döndürmemiz gerekebilir. Bunu nasıl yapacağız?

Öncelikle, bir dalın basitçe kronolojik olarak düzenlenmiş bir commit serisi olduğunu belirtelim. Teknik olarak bir dal, birbirini takip eden commitler zincirinin sonuncusu olarak kabul edilen commit için bir işaretçidir. Bu nedenle, bir dalı silmek commitlerin kendisini silmez. En kötü ihtimalle, başka bir dala yeniden atanabilirler veya hatta tek bir toplu committe birleştirilebilirler; ancak her durumda, depoda var olmaya devam ederler (nadir istisnalar dışında). Bu nedenle, "bir dalı silmeden önceki" duruma geri dönmek, esasen bir dalda var olan commitlerden birine geri dönmek anlamına gelir. O zaman şu soru ortaya çıkıyor: bu commiti nasıl bulacağız?

Bölüm 3'te bahsedilen değişiklikler yapıldıktan sonra SimpleCandles deposunun durumuna bakalım:

Commitlerin geçmişini ve sol tarafta dallar arasındaki ilişkilerin renkli bir görselleştirmesini görüyoruz. Her commit, onu diğerlerinden ayıran büyük ve benzersiz bir sayı olan hash ile tanımlanır. Gösterimi kısaltmak için hash onaltılık biçimde sunulur (örneğin, b04ebd1257). 

Böyle bir commit ağacı, MQL5 Algo Forge web arayüzünün ilgili sayfasında herhangi bir depo için görüntülenebilir. Gösterilen ekran görüntüsü bir süre önce alınmıştır, bu nedenle bu sayfayı şimdi ziyaret ettiğinizde biraz farklı bir resim göreceksiniz: ağaçta yeni commitler ortaya çıkmış olacak ve ilave birleştirme commitleri nedeniyle dalların iç içe geçmesi değişmiş olacaktır.

Bazı commitlerin yanında dal adlarını da görebiliriz. Bunlar, her daldaki son commitler için görüntülenir. Ekran görüntüsünde altı farklı dal sayabiliriz: main, develop, convert-to-utf8, article-17608-close-manager, article-17607 ve article-19436-forge3. Sonuncusu Bölüm 3 yazılırken yapılan değişiklikler için kullanılan daldır. Ancak Bölüm 2 üzerinde çalışırken, planlanan değişiklikler için ayrı bir dal da oluşturmuştuk. article-17698-forge2 adındaydı ve şu anda silinmiş durumda, bu yüzden artık hiçbir commit bu dal adını taşımıyor. Peki, onu nerede bulabiliriz?

58beccf233 için tam commit mesajına bakarsak, bu dal adını içerdiğini ve bu dalın develop dalı ile birleştirildiğini görürüz.

Böylece, istenen commiti bulduk, ancak bu şekilde bulmak pek uygun değil. Dahası, dalları “Pull talebi” yerine 'git merge' gibi konsol komutlarını kullanarak manuel olarak birleştirseydik, birleştirme commiti için herhangi bir keyfi yorum yazabilirdik. Bu durumda, dal adı mesaja hiç dahil edilmemiş olabileceğinden, doğru commiti bulmak daha da zor olurdu.

Artık istediğimiz commiti bulduğumuza göre, yerel depomuzu bu committen hemen sonraki durumuna geri yükleyerek ona geçebiliriz. Bunu yapmak için, 'git checkout' komutunda commit hash'ini kullanabiliriz. Ancak burada bazı nüanslar söz konusudur. MetaEditor'da bu commite projenin içerik menüsündeki "Git Log" seçeneği ile açılan geçmişten seçerek geçmeye çalışırsak:

... bir hata mesajıyla karşılaşırız:

Belki de bunun bir nedeni vardır. Neler olup bittiğine daha yakından bakalım. Yeni "etiket" ve "HEAD işaretçisi" kavramlarını tanımlayarak başlayacağız.

Etiketler

Git sürüm kontrol sistemindeki bir etiket, belirli bir commite atanan ek bir addır. Bir etiketi, doğrudan belirli bir commite işaret ettiğinden, depodaki kodun belirli bir sürümüne bir işaretçi veya referans olarak da düşünebilirsiniz. Bir etiket kullanmak, istediğiniz zaman kodun etiketlenmiş commite karşılık gelen tam durumuna geri dönmenizi sağlar. Etiketler, sürüm yayınlamaları, tamamlanma aşamaları veya kararlı derlemeler gibi bir proje geliştirmedeki önemli kilometre taşlarını işaretlemek için yararlıdır. MQL5 Algo Forge web arayüzünde, seçilen bir deponun tüm etiketlerini ayrı bir sayfada görüntüleyebilirsiniz.

Git'te iki tür etiket vardır: hafif ve açıklamalı. Hafif etiketler yalnızca bir ad içerirken, açıklamalı etiketler yazar, tarih, yorumlar ve hatta imza gibi ek bilgiler içerebilir. Çoğu durumda hafif etiketler kullanılır.

Web arayüzü üzerinden bir etiket oluşturmak için herhangi bir commitin sayfasını açabilir (örneğin bu commit), 'İşlemler' düğmesine tıklayabilir ve 'Etiket oluştur'u seçebilirsiniz.

Ancak, etiket oluşturma konusuna biraz sonra döneceğiz.

Git konsol komutları aracılığıyla bir etiket oluşturmak için 'git tag' komutunu kullanırsınız. Hafif bir etiket oluşturmak için etiketin adını belirtmeniz yeterlidir:

git tag <etiket-adı>

# Örnek:
git tag v1.0

Açıklamalı bir etiket oluşturmak için bazı ekstra parametreler eklemeniz gerekir:

git tag -a <etiket-adı> -m "Etiket açıklaması"

# Örnek
git tag -a v1.0 -m "Sürüm 1.0"

Yayınlanması veya dağıtılması amaçlanan kod sürümlerini işaretlemenin yanı sıra etiketler, belirli bir etikete sahip bir commit göründüğünde önceden tanımlanmış eylemleri tetiklemek için CI/CD veri hatlarına (pipeline) sinyal vermek veya yeni bir sürüm çıkışını temsil etmese bile önemli özelliklerin tamamlanması veya kritik hataların düzeltilmesi gibi önemli geliştirme kilometre taşlarını işaretlemek için de kullanılabilir.

HEAD işaretçisi

Etiketlerden bahsettikten sonra, bir başka önemli kavram olan HEAD işaretçisinden de bahsetmek gerekir. Davranışı, mevcut checkout yapılan daldaki en son commite otomatik olarak taşınan sabit bir HEAD adına sahip bir etikete benzer. HEAD genellikle "mevcut dalın işaretçisi" veya "aktif dalın işaretçisi" olarak adlandırılır. Esasen şu soruya cevap verir: "Şu anda deponun neresindeyiz?" Ancak, teknik olarak bir etiket değildir.

Fiziksel olarak bu işaretçi depodaki .git/HEAD dosyasında saklanır. HEAD'in içeriği sembolik bir referans (bir etiket veya dal adı) veya bir commit hash'i içerebilir. Dallar arasında geçiş yaparken, HEAD işaretçisi geçerli daldaki en son commiti gösterecek şekilde otomatik olarak güncellenir. Yeni bir commit eklendiğinde, Git yalnızca commit nesnesini oluşturmakla kalmaz, aynı zamanda HEAD işaretçisini de ona taşır.

Böylece, HEAD adı Git konsol komutlarında en son commitin hash'i veya mevcut dal adı yerine kullanılabilir. ~ ve ^ özel sembollerini kullanarak, en sonuncusundan önce bulunan commitlere başvurabilirsiniz. Örneğin, HEAD~2 en son committen iki adım önceki commiti ifade eder. Şu anda bu ayrıntılara girmeyeceğiz.

Bir deponun içinde bulunabileceği iki olası durumdan da bahsetmeliyiz. 'attached HEAD' olarak adlandırılan normal durum, yeni commitlerin mevcut daldaki en son committen önce görüneceği anlamına gelir. Bu durumda, tüm düzenlemeler sırayla ve çakışma olmadan dala eklenir.

'detached HEAD' olarak bilinen diğer durum, HEAD işaretçisi herhangi bir daldaki en son commit olmayan bir commite başvurduğunda ortaya çıkar. Bu, örneğin şu durumlarda gerçekleşebilir: 

• depoyu belirli bir geçmiş commite geçirmek (örneğin, 'git checkout <commit-hash>' kullanarak),
• etiket adına göre geçiş (örneğin, 'git checkout tags/<etiket-adı>'),
• uzak depoda hala var olan ancak yerel depodan kaldırılmış bir dala geçiş (örneğin, 'git checkout origin/<dal-adı>').

Bu durumdan mümkün olduğunca kaçınılmalıdır, çünkü bu durumdaki herhangi bir dalla ilişkili olmayan değişiklikler başka bir dala geçerken kaybolabilir. Ancak, bu durumda değişiklik yapmayacaksanız, böyle olması sorun değil.

Şimdiye kadar etiket yok

Şimdi yerel depomuzu bir zamanlar silinmiş article-17698-forge2 dalındaki en son commit olan belirli bir commite geçirme girişimimize geri dönelim.

Bir depoyu geçmişteki belirli bir commite geçirmek, geliştiricilerin günlük Git iş akışlarında genellikle yaptığı bir şey değildir. Normal şartlar altında, nadiren böyle bir işlem yapmanız gerekecektir. Ancak, bunu yapmayı seçerseniz, depo "detached HEAD" olarak bilinen duruma girecektir. Bu commit zaten kendisinden sonra daha yeni commitler olan develop dalına aittir, bu nedenle artık daldaki en son commit değildir.

Yine de, bu geçişi gerçekleştirmek için Git'in komut satırı arayüzünü kullanırsak, işlem başarıyla tamamlanacaktır. Fakat Git bizi "detached HEAD" durumunda olmamız konusunda açıkça uyaracaktır:

 

Dikkatli okuyucular son ekran görüntüsünde 58beccf233 hash'li bir commite geçtiğimizi fark edebilirler, ancak Git HEAD işaretçisinin şu anda 58beccf'de olduğunu bildiriyor. Son üç karakter nereye gitti? Bir sorun yok. Ortadan kaybolmadılar. Git, depo içinde benzersiz kaldıkları sürece kısaltılmış commit hash'lerinin kullanılmasına izin verir. Arayüze bağlı olarak, hash'lerin 4 ila 10 karakter arasında kısaltıldığını görebilirsiniz.

Eğer tam commit hash'ini görmeniz gerekirse, bunu 'git log' komutunu çalıştırarak yapabilirsiniz. Her tam commit hash'i 40 karakter içerir.

Her bir hash rastgele ve benzersiz bir şekilde üretildiğinden, ilk birkaç karakterin bile bir depo içinde farklı olması neredeyse garantidir. Bu nedenle, Git'in komutlarınızda tam olarak hangi commite atıfta bulunduğunuzu anlaması için yalnızca kısa bir hash öneki sağlamak genellikle yeterlidir.

UTF-8 kodlamasını kullanma

Bir başka ilginç nokta daha var. Önceki sürümlerde MetaEditor, kaynak kod dosyalarını kaydetmek için UTF-16LE kodlamasını kullanıyordu. Ancak, bazı nedenlerden dolayı, bu kodlamada kaydedilen dosyalar Git tarafından metin dosyaları yerine ikili dosyalar olarak değerlendiriliyordu. Sonuç olarak, bir committe değiştirilen tam kod satırlarını görüntülemek imkansızdı (bu Visual Studio Code'da iyi çalışsa bile). Görüntülenen tek bilgi, commite içindeki değişikliklerden önceki ve sonraki dosya boyutlarıydı.

İşte MQL5 Algo Forge web arayüzünde nasıl göründüğü:

Artık MetaEditor'da oluşturulan yeni dosyalar UTF-8 kodlaması kullanılarak kaydediliyor ve ulusal alfabe karakterlerinin kullanımı bile UTF-16LE'ye otomatik geçişi tetiklemiyor. Bu nedenle, daha önceki projelerden yeni depoya taşınan eski dosyaları UTF-8'e dönüştürmek mantıklıdır. Böyle bir dönüştürme gerçekleştirdikten sonra, bir sonraki committen başlayarak, tam olarak hangi satırların ve karakterlerin değiştirildiğini görebileceksiniz. Örneğin, MQL5 Algo Forge web arayüzünde şöyle görünebilir:

Ama bu kısa bir ayrıntıydı. Depoda yeni bir kod sürümünün nasıl yayınlanacağı tartışmasına geri dönelim.

Ana göreve geri dönelim

Depomuzdaki dallar arasında şu ikisine dikkat edelim: article-17608-close-manager ve article-17607. Bu dallarda yapılan değişiklikler henüz develop dalıyla birleştirilmemiştir, çünkü bunlarla ilişkili görevler hala devam etmektedir. Bu dallar geliştirilmeye devam edecektir, bu nedenle bunları develop dalıyla birleştirmek için henüz çok erken. Bunlardan biri (article-17607) üzerinde çalışmaya devam edeceğiz, onu mantıklı bir tamamlanma noktasına getireceğiz ve ardından develop dalıyla birleştireceğiz. Kodun ortaya çıkan durumu bir sürüm numarası ile etiketlenecektir.

Bunu yapmak için, öncelikle seçilen dalı daha fazla düzenleme için hazırlamamız gerekir, çünkü varlığı süresince diğer dallarda da değişiklikler yapılmıştır. Bu değişiklikler zaten develop dalında birleştirildi. Bu nedenle, develop dalındaki bu güncellemelerin seçtiğimiz dala da dahil edildiğinden emin olmalıyız.

develop dalındaki değişiklikleri article-17607 dalına birleştirmenin birkaç yolu vardır. Örneğin, web arayüzü üzerinden bir “Pull talebi” oluşturabilir ve önceki bölümde açıklanan birleştirme işlemini tekrarlayabiliriz. Ancak, bu yaklaşım en çok yeni, test edilmemiş kodu kararlı, test edilmiş kod içeren bir dalla birleştirmek istediğinizde kullanılır. Bizim durumumuzda ise tam tersi bir durum söz konusu: kararlı, doğrulanmış güncellemeleri develop dalından hala yeni, kontrol edilmemiş kod içeren bir dala getirmek istiyoruz. Bu nedenle, Git konsol komutlarını kullanarak birleştirme işlemini gerçekleştirmek tamamen uygundur. Konsolu kullanacağız ve süreci Visual Studio Code'da izleyeceğiz.

İlk olarak, deponun mevcut durumunu kontrol edelim. Sürüm kontrol panelinde, dal adlarıyla birlikte commit geçmişini görebiliriz. Geçerli dal, en son değişikliklerin yapıldığı article-19436-forge3'tür. Terminalin sağ tarafında 'git status' komutunun çıktısı gösteriliyor:

Komut, depomuzun şu anda article-19436-forge3 dalında olduğunu ve durumunun uzak depodaki ilgili dal ile senkronize edildiğini onaylıyor.

Ardından, 'git checkout article-17607' komutunu kullanarak article-17607 dalına geçiyoruz:

Daha sonra 'git merge develop' kullanarak develop dalıyla birleştiriyoruz:

Harici değişiklikler, article-17607 dalında çalışırken değiştirmediğimiz kod parçalarını etkilediğinden, birleştirme sırasında herhangi bir çakışma ortaya çıkmadı. Sonuç olarak Git yeni bir birleştirme commiti oluşturdu.

Şimdi güncellenmiş bilgileri uzak depoya göndermek için 'git push' komutunu çalıştıralım:

MQL5 Algo Forge deposunu kontrol edersek, birleştirme adımlarımızın uzak depoya başarıyla yansıtıldığını göreceğiz:

Ekran görüntüsünde gösterilen son commit, develop ve article-17607 dalları arasındaki birleştirme commitidir. 

Ayrıca, henüz başka bir dala bağlı olmayan article-19436-forge3 dalının serbest ucuna da dikkat edin. Bu daldaki değişiklikler henüz develop dalıyla birleştirilmedi, çünkü buradaki çalışmalar hala devam ediyor. Şimdilik olduğu gibi bırakacağız. Zamanı geldiğinde, buna geri döneceğiz.

Bu, article-17607 dalında devam edecek geliştirme için hazırlığı tamamlıyor ve artık kodlama çalışmasına devam edebiliriz. Bu dalla ilgili görevin çözümü başka bir makalede açıklanmıştır. O yüzden burada tekrar etmeyeceğim. Bunun yerine, görevi tamamladıktan sonra kodun elde edilen durumunun nasıl sonuçlandırılacağını ve kaydedileceğini açıklamaya devam edelim.

Birleştirmeyi gerçekleştirme

Kodun belirli bir durumunu yayınlamadan önce, onu ana dalla birleştirmemiz gerekir. Ana dalımız main dalıdır. develop dalındaki tüm güncellemeler eninde sonunda ana dala akacaktır. Bireysel görev dallarındaki değişiklikler develop dalıyla birleştirilir. Şimdilik, yeni kodu main dalında birleştirmeye hazır değiliz, bu nedenle kendimizi güncellemeleri develop dalında birleştirmekle sınırlayacağız. Bu mekanizmayı göstermek için, hangi dalın ana dal olarak hizmet vereceği özellikle önemli değildir.

Seçilen görev üzerinde çalışmayı bitirdikten sonra SimpleCandles deposunun durumuna bakalım:

Gösterildiği gibi, en son commit article-17607 dalında yapılmıştır. MQL5 Algo Forge web arayüzünü kullanarak, daha önce açıklandığı gibi bu dalı develop dalıyla birleştirmek için bir “Pull talebi” oluşturuyoruz.

Her şeyin beklendiği gibi gittiğini doğrulayalım. Dal ağacı görünümü ile commit geçmişi sayfasını tekrar açıyoruz:

432d8a0fd7 hash'li commitin artık article-17607 dalında en son olarak işaretlenmediğini görebiliriz. Bunun yerine, 001d35b4a7 hash'ine sahip yeni bir commit, develop dalındaki en son commit olarak görünüyor. Bu commit iki dalın birleştirilmesini kaydettiğinden, bundan birleştirme commiti olarak bahsedeceğiz.

Ardından, birleştirme commiti sayfasını açalım ve yeni bir etiket oluşturalım. Makalenin başlarında, bunun nerede yapılacağını gösterdik; ve şimdi bunu gerçekten yapmanın zamanı geldi:

Açılan pencerede "v0.1" etiket adını girelim, çünkü bu hala son sürümden uzaktır. Projeye daha ne kadar ekleme yapılacağını henüz bilmiyoruz, ancak umarız birkaç tane olur. Bu nedenle, bu kadar küçük bir sürüm numarası, önümüzde hala çok iş olduğunu kendimize hatırlatıyor. Bu arada, web arayüzü şu anda açıklamalı etiketler oluşturmayı desteklemiyor gibi görünüyor.

Etiket şimdi başarıyla oluşturuldu ve sonucu aşağıdaki sayfada görebiliriz:

 veya deponun özel etiketler sayfasında bulabiliriz.

Yerel depomuzu 'git pull' kullanarak güncellersek, yeni oluşturulan etiket orada da görünecektir. Ancak, MetaEditor şu anda depo etiketlerini görüntülemediğinden, Visual Studio Code'da nasıl göründüklerini kontrol edelim. Fareyi commit ağacında istediğimiz commitin üzerine getirirsek, bilgi kutusunda ilgili etiket adını içeren bir renk etiketi görünür:

Artık etiket oluşturulduğuna göre, burada durabilir ve tam olarak bu kod durumuna geçmek için adını bir 'git checkout' komutunda kullanabilir veya daha ileri gidebilir ve buna dayalı bir sürüm oluşturabiliriz. 

Sürüm oluşturma

Sürüm, kullanılan programlama dilinden bağımsız olarak yazılımın belirli versiyonlarını işaretlemek ve dağıtmak için kullanılan bir mekanizmadır. Commitler ve dallar geliştirme iş akışını temsil ederken, sürümler bunun resmi sonuçları, yani yayınlamak istediğimiz versiyonlardır. Sürümleri kullanmanın temel amaçları aşağıdaki gibidir:

• Versiyonlama. Depo kodundaki kodun belirli durumlarını kararlı olarak işaretleriz, yani kritik hatalar (en azından görünür olanlar) içermezler ve doğrulanmış işlevselliğe sahiptirler. Diğer kullanıcılar bu belirli versiyonları kullanabilir.
  
  
• İkili dosyaların dağıtılması. Sürümler derlenmiş veya paketlenmiş dosyalar (.ex5, .dll veya .zip gibi) içerebilir, böylece kullanıcıların projeyi kendilerinin derlemesi gerekmez.
  
  
• Kullanıcı iletişimi. Bir sürüm, genellikle değişiklikleri, yeni özellikleri, düzeltilen hataları ve o sürümle ilgili diğer bilgileri listeleyen bir açıklama içermelidir. Bu açıklamanın temel amacı, kullanıcıların güncelleme yapıp yapmamaları gerektiğine karar vermelerine yardımcı olmaktır.

MQL5 Algo Forge dahil olmak üzere CI/CD sistemlerinin, bir dal main dalıyla birleştirildiğinde otomatik olarak sürümler oluşturabildiğini, otomatik derlemeler gerçekleştirebildiğini ve ikili dosyaları yayınlayabildiğini belirtmek gerekir. Ancak, bu tür bir otomasyon önceden kurulum ve olay işleme komut dosyalarının yapılandırılmasını gerektirir. Bunlar daha gelişmiş (ancak gerekli olmayan) yeteneklerdir, bu nedenle şimdilik bunları bir kenara bırakacağız.
Mevcut bir etiket temel alınarak bir sürüm oluşturulabilir veya sürüm oluşturma işlemi sırasında yeni bir etiket oluşturulabilir. Zaten bir etiketimiz olduğu için, onu kullanarak yeni bir sürüm oluşturacağız. Bunu yapmak için depo etiketleri sayfasına gidelim ve istediğimiz etiketin yanındaki 'Yeni sürüm' ifadesine tıklayalım:

Sürüm oluşturma formunda birkaç temel özellik belirtebiliriz:

• Sürüm adı, hedef dal ve etiket (mevcut veya yeni oluşturulacak bir etiket),
• Sürüm notları, yani nelerin yeni olduğu, nelerin düzeltildiği ve hangi bilinen sorunların ele alındığına dair bir özet,
• Ekli dosyalar, örneğin derlenmiş programlar, dokümantasyon veya harici kaynaklara linkler.

İşte MQL5 Algo Forge web arayüzünde nasıl göründüğü:

Bir sürümü taslak olarak kaydedebilir ve ayrıntılarını daha sonra güncelleyebilir veya hemen yayınlayabilirsiniz. Şimdi yayınlasanız bile daha sonra düzenleme yapabilirsiniz: örneğin, sürüm açıklamasını daha sonra da değiştirebilirsiniz. Yayınlandıktan sonra, sürüm deponun Sürümler sayfasında yer alacak ve diğer kullanıcılar tarafından görülebilecektir:

Bu kadar! Yeni sürüm artık yayında ve kullanıma hazır. Kısa bir süre sonra, sürüm adını güncelledik (etiket adıyla eşleşmesi gerekmiyor) ve uygulanan çözümü açıklayan yukarıda belirtilen makaleye bir link ekledik.

Sonuç

Bir an için duralım ve kaydettiğimiz ilerleme üzerinde düşünelim. Sürüm kontrolünün sadece teknik yönlerini keşfetmedik. Dağınık düzenlemelerden kod yönetimi için yapılandırılmış, tutarlı bir iş akışına geçerek tam bir dönüşümü tamamladık. Ulaştığımız en önemli kilometre taşı son adımdır: tamamlanan çalışmaları son kullanıcılar için resmi ürün sürümleri olarak yayınlamak. Mevcut depomuz henüz tam olarak olgunlaşmış bir projeyi temsil etmeyebilir, ancak bu seviyeye ulaşmak için tüm temelleri attık.

Bu yaklaşım, projeyi algılama şeklimizi temelden değiştiriyor. Bir zamanlar kaynak dosyaların gevşek bir koleksiyonu olan sistem, artık net bir değişiklik geçmişine ve iyi tanımlanmış kontrol noktalarına sahip organize bir sistem haline geldi. Bu sayede, istediğimiz zaman herhangi bir kararlı duruma geri dönebiliriz. Bu herkesin yararınadır: hem geliştiriciler hem de bitmiş çözümlerin kullanıcıları için.

Bu araçlarda ustalaşarak MQL5 Algo Forge deposundaki çalışmalarımızı yeni bir seviyeye taşıdık ve gelecekte daha karmaşık ve büyük ölçekli projelere kapı açtık.

İlginiz için teşekkür ederim! Görüşmek üzere!