MQL5 Algo Forge'a Geçiş (Bölüm 2): Birden Fazla Depo ile Çalışma

Giriş

İ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.

Ancak, ilk makalenin yayınlanmasından bu yana, MetaEditor yeni depo sistemi için desteğini önemli ölçüde genişletti. Bu değişiklikler bizi daha önce çerçevesini çizdiğimiz yaklaşımı yeniden gözden geçirmeye teşvik ediyor. Bu nedenle, bu makalede orijinal plandan biraz sapacağız ve diğer herkese açık projeleri bileşen olarak entegre eden bir herkese açık projenin nasıl oluşturulacağını inceleyeceğiz. Oluşturulacak proje, “çok dövizli bir Uzman Danışman geliştirme” konusuna adanacaktır. Bu proje için kod geliştirme ve modifikasyon yaklaşımlarını açıklayan birkaç makale zaten yayınlandı. Şimdi, geliştirme sürecini düzenlemek ve kolaylaştırmak için Git sürüm kontrolünden tam olarak yararlanacağız.

Yol haritasını çizme

İnanması zor ama bir önceki makalenin yazıldığı tarihte MetaEditor, MQL5 Algo Forge depolarıyla çalışmak için henüz Git içerik menüsü komutlarına sahip değildi. Sonuç olarak, Visual Studio Code gibi harici araçlar kullanarak iş akışlarını yapılandırmak için önemli ölçüde çaba sarf etmek gerekiyordu. MetaEditor'ın nihayetinde depo desteğini nasıl uygulayacağını bilmediğimiz için o sırada mevcut olan araçları kullanmak zorundaydık.

MetaEditor’ın yeni sürümleri artık MQL5 Algo Forge için yerleşik destek sunuyor. MetaQuotes ayrıca, temel bilgileri açıklayan ve ana özellikleri gösteren "MQL5 Algo Forge'u Kullanmaya Başlama" adlı yeni bir makale yayınladı. Ancak, bize göre en önemli gelişme, MetaEditor'da paylaşılan projelerin (Shared Projects) uygulanmasıdır.

Bu neden önemli? Öncesinde, MQL5 klasörünün MQL5 Algo Forge'un Git sunucularında barındırılan bir depo görevi göreceğini biliyorduk. Görünüşe göre, bu deponun sabit adı mql5 olacaktır. Bu, her kullanıcının Algo Forge'da mql5 adında bir depoya sahip olacağı anlamına geliyor. Bu depo daha sonra yeni bir terminal kurduktan, Toplulukta oturum açtıktan ve depoyu bağladıktan sonra MQL5 klasörüne klonlanacaktır. Aynı zamanda, MQL5 Algo Forge her zaman ek depoların oluşturulmasına izin vermiştir. Daha doğrusu, ek değil, mql5 deposuyla ilgili olmayan ayrı depolar. Doğal olarak şu soruyu ortaya çıkıyor: MetaEditor bu diğer depoları nasıl yönetecek? 

Kullanıcılar terminalin her kurulumunda hangi deponun kullanılacağını seçebilecekler mi? Yoksa seçemeyecekler mi? Yalnızca mql5 deposu desteklenecek ve kullanıcılar çalışmalarını farklı projeler için dallara ayırmaya mı zorlanacak? Başlangıçta bu en kötü senaryo için hazırlandık. Tek bir depoda dallar arasında birden fazla projeyi yönetmek pek de uygun değildir. Neyse ki endişelerimizin yersiz olduğu ortaya çıktı.

MetaQuotes, iki sorunu aynı anda etkili bir şekilde çözen daha zarif bir çözüm sundu. Bir yanda mql5 adlı ana depomuz var. Bu, MQL5 Storage’a zaten alışkın olanlar için uygundur. Artık arka planda hangi sürüm kontrol sisteminin çalıştığı konusunda endişelenmeden sürüm kontrolünü kullanmaya devam edebilirler.

Öte yandan, diğer tüm kullanıcı depoları artık Shared Projects içinde klasörler şeklinde mevcuttur. Bu, kullanıcının ek depolarından gelen kodu saklamak için mevcut klasörlerin (MQL5, MQL5/Experts, MQL5/Include vb. gibi) yanı sıra yeni bir standart kök klasör sağlar.

Bir örnek üzerinde düşünelim. MQL5 Algo Forge'da, ikisi de varsayılan mql5 olmayan iki ayrı depomuz olduğunu varsayalım. İlk depo (Adwizard) yalnızca kütüphane kodunu içerir, yani yalnızca *.mqh dosyaları içerir, bir Uzman Danışman veya göstergeye derlenebilecek herhangi bir *.mq5 dosyası içermez. İkinci depo (Simple Candles), ilk depodaki include dosyalarını kullanan *.mq5 dosyalarını içerir. Basit olması için ilk depoya kütüphane deposu, ikincisine ise proje deposu diyeceğiz.

Amacımız, proje deposunda geliştirme yaparken kütüphane deposundaki kodun nasıl kullanılacağını belirlemektir. Bu senaryo, örneğin mql5.com Kod Tabanında paylaşılan kodun, yazarları tarafından MQL5 Algo Forge'da halka açık depolar olarak yansıtılması durumunda giderek daha yaygın hale gelebilir. Bu gibi durumlarda, bir veya daha fazla depoyu bir projeye harici kütüphaneler olarak bağlamak, bu makalede keşfetmek üzere olduğumuz şekilde ele alınabilir.

Başlangıç

Öncelikle duruma her iki deponun da sahibi olan geliştiricinin bakış açısından bakalım. Bu, “Pull talebi” mekanizması aracılığıyla bir inceleme ve onay beklemeden her iki depodaki kod üzerinde özgürce değişiklik yapabileceğimiz anlamına gelir. Temiz bir terminal klasörü oluşturarak ve MetaTrader 5'in önceden yüklenmiş herhangi bir kopyasından iki dosya kopyalayarak başlıyoruz:

Terminalin çalışma klasörünü dosya sisteminin derinliklerinde aramaktan kaçınmak için terminali portable modda çalıştırmanızı öneririm. Windows'ta bunu yapmanın bir yolu, terminalin çalıştırılabilir dosyasına bir kısayol oluşturmak ve kısayol özelliklerindeki hedef alanına /portable bayrağını eklemektir. 

Terminali başlattıktan sonra, her ihtimale karşı yeni bir demo hesap açalım, en son sürüme güncelleyelim, Toplulukta oturum açalım ve ardından F4 tuşuna basarak MetaEditor'ı başlatalım. Henüz otomatik olarak bağlanmadıysa MQL5 Algo Forge'u bağlayalım.

Kılavuzda, daha önce web arayüzü aracılığıyla oluşturduğumuz depoları listeleyen 'Shared Projects' klasörünü görürüz. Ancak, bu klasörü Dosya Gezgininde açtığımızda hala boş olduğunu fark ederiz. Bu, depo dosyalarının henüz bilgisayarımıza indirilmediği anlamına gelir.

Bunları klonlamak için, gerekli depoların her birine sağ tıklayalım ve içerik menüsünden "Git Clone"u seçelim. Günlük, hem Adwizard hem de Simple Candles'ın başarılı bir şekilde klonlandığını onaylıyor. Klonlanmış depoların bulunduğu klasörler artık Dosya Gezgininde görünüyor:

Bu noktada, her iki projenin kodu da yerel olarak mevcuttur ve kullanıma hazırdır.

İlk sorun

SimpleCandles.mq5 dosyasını açalım ve derlemeyi deneyelim:

Beklendiği gibi, derleme hataları meydana geliyor. Nedenlerini anlamaya çalışalım. Kodun daha önce başarıyla derlendiğini bildiğimiz için bunlar kritik değildir. Değişen tek şey kütüphane ve proje dosyalarının göreceli yerleşimi. İlk iki hata, derleyicinin kütüphane dosyalarını beklediği yerde bulamamasından kaynaklanır. Bölüm 28'de, kütüphane ve proje parçalarını depolamak için aşağıdaki klasör yapısını kullanmayı kararlaştırmıştık:

Yani, kütüphane deposunu proje deposunun bir alt klasöründe saklıyoruz. Bu bize kütüphane dosyalarını bulmak için öngörülebilir bir yapı sağladı. Ancak bu sefer bunu değiştireceğiz. Proje içinde zorunlu bir Include alt klasörü kullanmak yerine, MQL5/Shared Projects klasörünü kullanacağız. İdeal olarak, bu klasör sabit kalacak ve gelecekteki MetaEditor sürümlerinde aynı amaca hizmet etmeye devam edecektir.

Sorunu çözmek için iki dosyadaki #include yönergelerini güncelleyeceğiz. Ancak herhangi bir kod değişikliği yapmadan önce, iyi geliştirme uygulamalarını takip edelim ve bu izole görev için ayrı bir dal oluşturalım. Düzeltmeler test edildikten sonra, dalı tekrar ana geliştirme dalıyla birleştirebiliriz.

Proje deposunda halihazırda hangi dallara sahip olduğumuzu görelim. Bu birkaç şekilde yapılabilir:

• MetaEditor'da depo klasörünün içerik menüsü aracılığıyla: 

• Deponun dallar sayfasındaki web arayüzü aracılığıyla:

• Visual Studio Code gibi harici bir Git aracı kullanarak. Depo adının yanında, geçerli dalın adı olan main'i görüyoruz. Üzerine tıklandığında mevcut dalların bir listesi (ve yeni dallar oluşturmak için menü öğeleri) gösterilir:

Şu anda deponun dört dalı bulunmaktadır:

• main - ana dal. Depo ile birlikte oluşturulur. En basit durumda, herhangi bir ek dal oluşturmadan tüm çalışma burada yapılabilir. Daha karmaşık durumlarda bu dal, kodun kararlı sürümlerini sağlayan dosyaların durumlarını saklamak için kullanılır. Henüz tamamlanmamış ve test edilmemiş devam eden değişiklikler diğer dallarda yapılır.
• develop - geliştirme dalı. Basit durumlarda, değişiklik eklemek ve yeni özellikler uygulamak için tek dal olarak kullanılabilir. Yeni özellikler sırayla uygulanıyorsa bu seçenek yeterlidir. Yani, önceki özellikleri ekledikten sonra proje tamamen işlevsel ve kararlı bir duruma gelene kadar yeni işlevleri uygulamaya başlamıyoruz. Yeni bir özellik üzerinde çalışmaya başlamadan önce dallar birleştirilir: develop dalında yapılan düzenlemeler main dalıyla birleştirilir. Aynı anda birden fazla özellik geliştiriliyorsa, tek bir geliştirme dalında çalışmak sakıncalı hale gelir. Bu gibi durumlarda, ek özellik dalları oluşturulabilir.
• Örnekler veya bu tür dallar article-17608-close-manager ve article-17607'dir. İlki, kar/zarar eşiklerine dayalı pozisyon kapatma mantığı için bir özellik dalıdır. Bu dal halihazırda develop ile birleştirilmiştir ve develop daha sonra main ile birleştirilmiştir. İkinci özellik dalı, otomatik optimizasyona yönelik geliştirmeler için kullanılmaktadır. Hala devam ediyor, henüz develop veya main ile birleştirilmemiştir.

Git'in herhangi bir özel dal kullanım kuralı uygulamadığını vurgulamak önemlidir. Böylece, bizim için en uygun olan seçeneği seçebiliriz. Bazı geliştiricilerin yararlı bulduğu ve başkalarıyla paylaştığı belirli iş akışları vardır. En iyi yöntemler bu şekilde ortaya çıkar. Projenize uygun olan dallanma modelini benimsemekte veya uyarlamakta özgürsünüz. Örnek olarak, bu makalede açıklanan önerilen dallanma ilkelerinden birine göz atabilirsiniz.

Şimdi depomuza geri dönelim.

Soru işareti yaratabilecek bir ayrıntı origin/ (veya MetaEditor'da gösterildiği gibi refs/remotes/origin/) önekidir. Bu önek, dalın yalnızca yerel olarak değil, uzak depoda da bulunduğunu gösterir. Genellikle yerel ve uzak dalları senkronize tutarız. MetaEditor'da bir Commit komutu çalıştırmak otomatik olarak bir Push komutunu tetikler ve böylece commit uzak depoya gönderilir.

MetaEditor dışında commit yapılırsa, push etmeden yerel olarak commit yapmak mümkündür. Bu gibi durumlarda, aynı ada sahip yerel ve uzak dallar farklı olabilir. origin/ öneki bunların birbirinden ayırt edilmesine yardımcı olur. Bu önekle, uzak bir depodaki bir dalı kastediyoruz; aksi takdirde, yerel bir daldır.

Yeni dal oluşturma

Planlanan düzenlemeler yalnızca kütüphane kısmının yerleşimi değiştikten sonra kodun doğru şekilde derlenmesini sağladığından, develop'tan oluşturulan yeni bir dalı temel alacağız. Önce origin/develop'a geçiyoruz, sonrasında listede yerel bir develop dalı olarak görünür.

Ardından yeni bir dal oluşturuyoruz (Yeni komutunu çalıştıralım) ve istediğimiz adı giriyoruz. Bizim geleneksel yaklaşımımıza göre, makale ile ilgili dallar article- artı makalenin benzersiz tanımlayıcısı ile başlar. Bunu isteğe bağlı olarak makalenin konusunu açıklayan kısa bir sonek takip edebilir. Bu yüzden yeni dal "article-17698-forge2" olarak adlandırılmıştır.

Başka şekillerde de dal oluşturabiliriz: web arayüzünü, Visual Studio Code arayüzünü veya komut satırı arayüzünü kullanarak. Deponun kök klasöründeki komut satırından çalıştırabiliriz:

git checkout -b article-17698-forge2 develop

Bu, Git'e develop dalını temel alarak article-17698-forge2 adlı yeni bir dala (-b) geçmesini (checkout) söyler.

Web arayüzü dışında bir dal oluşturulursa, uzak depoya ilk push yapılana kadar yalnızca yerel makinemizde var olacaktır. Bunun tersi de doğrudur: web arayüzü aracılığıyla uzak depoda bir dal oluşturulursa, uzak depodan ilk pull yapılana kadar yerel makinemizde görünmeyecektir.

Değişiklikleri şu şekilde gönderebiliriz:

ya da şöyle:

Push işlemi için konsol komutu, yeni bir dal oluşturulmasını içerdiğinde, dalın uzak depoda oluşturulmasını gerçekten istediğimizi doğrulayan ek parametreler içermelidir:

git push --set-upstream origin article-17698-forge2

Bundan sonra, dal hem deponun yerel kopyasında hem de MQL5 Algo Forge'da barındırılan uzak depoda bulunur. Bu noktada, diğer dalların işlevselliğini bozma korkusu olmadan düzenlemeler yapmaya başlayabiliriz.

Değişiklikler yapma

Gerekli değişiklikler çok basittir. SimpleCandles.mq5 dosyasında, Adwizard kütüphanesinden bir dosya içeren satırı güncelliyoruz. Simple Candles ve Adwizard depolarının kök klasörleri artık Shared Projects klasörünün içinde aynı seviyede bulunduğundan, Expert.mqh yolu kütüphane deposunun alt klasörlerine inmeden önce bir seviye yukarı (../) çıkmalıdır:

#include "Include/Adwizard/Experts/Expert.mqh"
#include "../Adwizard/Experts/Expert.mqh"

Strategies/SimpleCandlesStrategy.mqh dosyasında da benzer bir ayarlama yapılması gerekmektedir:

#include "../Include/Adwizard/Virtual/VirtualStrategy.mqh"
#include "../../Adwizard/Virtual/VirtualStrategy.mqh"

Bu değişikliklerden sonra SimpleCandles.mq5 tekrar başarıyla derlenir. Artık değişiklikleri depoya işleyebiliriz:

Daha önce de belirtildiği gibi, MetaEditor arayüzü üzerinden commit yaparken, Push komutu otomatik olarak yürütülür ve değişiklikleri MQL5 Algo Forge'daki uzak depoya gönderir.

Konsol komutları ile çalışırken aynı sonucu şu şekilde elde edebiliriz. Mevcut dosyaları düzenlemenin yanı sıra yenilerini de oluşturduysak, önce bunları depo indeksine eklememiz gerekir:

git add .

Bu komut depo klasöründe bulunan tüm yeni dosyaları ekler. Yalnızca belirli dosyaları eklemek için nokta (.) işaretini dosyaların adlarıyla değiştirin. Sonrasında, değişiklikleri belirli bir yorumla commit ediyor ve uzak depoya gönderiyoruz:

git commit -m "Fix relative paths to include files from Adwizard"
git push

Bu noktada, article-17698-forge2 dalındaki değişiklikler tamamlanmıştır. develop dalıyla birleştirilebilir ve ardından kapatılabilir.

İkinci sorun

Burada tatsız bir sürprizle karşılaşıyoruz. MetaEditor şu anda dalları birleştirmek için araçlardan yoksundur. Başka bir deyişle, artık yeni dallar oluşturabiliyoruz, ancak değişiklikleri bir daldan diğerine aktaramıyoruz! Bu işlevselliğin yakın gelecekte ekleneceğini umuyorum. Şimdilik, depo işlemlerini gerçekleştirmek için bir kez daha alternatif araçlara yönelmeliyiz.

Dalları birleştirmenin iki ana yolu vardır. Birincisi, Visual Studio Code'daki birleştirme arayüzünü veya standart konsol komutlarını kullanmaktır. Bizim durumumuz için aşağıdaki komutlar kullanılabilir:

git checkout develop
git pull
git merge --no-ff article-17698-forge2

İlk olarak, develop dalına geçiyoruz. Ardından, önlem olarak onu güncelliyoruz (henüz yerel makinemize ulaşmamış değişiklikler yapılmış olma ihtimaline karşı). Son komut ile birleştirme işlemini gerçekleştiriyoruz. Birleştirme çakışmaları mümkündür, ancak bizim senaryomuzda, hala proje üzerinde çalışan tek bir geliştiricinin durumunu düşündüğümüz için olası değildir. Birden fazla konumdan çalışırken bile, depoları düzenli olarak en son duruma güncellediğimiz sürece, çakışmalar ortaya çıkmamalıdır.

Ancak, bu yöntemin nüansları üzerinde durmayalım. Bunun yerine, ikinci yaklaşıma daha yakından bakacağız. Burada MQL5 Algo Forge web arayüzünü kullanıyoruz.

Birleştirme için Pull talebi kullanma

Diğer Git tabanlı platformlar (GitHub, GitLab veya Bitbucket) gibi, MQL5 Algo Forge da Pull talebi (Pull Request, PR) adı verilen bir mekanizma içerir.

Pull talebi, bir geliştiricinin bir depoda birleştirilmek üzere bir dalda yapılan değişiklikleri önermesine olanak tanır. Başka bir deyişle, PR oluşturmak depo sahibini ve diğer katkıda bulunanları bilgilendirmenin bir yoludur: "Kendi dalımdaki çalışmayı tamamladım, lütfen bu değişiklikleri gözden geçirin ve ana dalla (main/master/develop) birleştirin."

PR, Git'in bir özelliği değil, Git'in üzerine inşa edilen ek bir katmandır. Değişiklikler ana dalla birleştirilmeden önce kod inceleme ve tartışma sürecini düzenler.

Pull talepleri ayrıca modern geliştirmedeki diğer bazı kritik görevleri de çözer: otomatik testlerle sürekli entegrasyon (Continuous Integration, CI), diğer geliştiriciler tarafından kalite kontrolü ve belirli değişikliklerin neden yapıldığını açıklayan PR yorumları şeklinde değişikliklerin dokümantasyonu. Ancak, bu faaliyetler en çok ekip tabanlı projeler için geçerlidir, MQL5 projeleri ise genellikle bireysel projelerdir. Gelecekte işbirliğine dayalı projeler arttıkça iş akışı daha önemli hale gelebilir.

Bununla birlikte, PR'leri kullanarak yeni işlevler veya düzeltmeler eklemek için tipik bir iş akışının başlangıcını halihazırda oluşturduk:

1. En son değişiklikleri çek. Çalışmaya başlamadan önce yerel develop dalını güncelledik.

2. Görev için yeni bir dal oluştur. Güncellenen develop dalından article-17698-forge2 adında bir dal oluşturduk.

3. Yeni dalda değişiklikler yap. Birkaç dosyayı değiştirdik ve test ettik, ardından değişiklikleri commit ettik.

Sonraki adımlar aşağıdaki gibidir.

4. Bir Pull talebi oluştur. MQL5 Algo Forge web arayüzünde, 'Pull talepleri' sekmesine gidelim ve büyük kırmızı 'Yeni pull talebi' düğmesine tıklayalım.

Bu, dal seçme sayfasını açar. Bu aşamada PR henüz oluşturulmamıştır; öncelikle değişikliklerin nerede birleştirileceğini tanımlamamız gerekir. Dallar seçildikten sonra değişiklik listesini inceleyebiliriz. Ardından, tekrar 'Yeni pull talebi' düğmesine tıklarız.

Değişikliklerin ayrıntılı bir açıklamasını sunabileceğimiz yeni bir sayfa açılır. Burada gözden geçirenleri de atayabiliriz. Varsayılan olarak, talep kendimize yönlendirilir, bu durumda tam olarak ihtiyacımız olan şey de budur.

5. Gözden geçirme ve tartışma. Yalnız çalıştığımız için bu adımı atlayabiliriz. Normalde bu aşama şunları içerir:

   • Gözden geçirenlerin kodu incelemesi ve yorum bırakması (genel veya belirli satırlara özel),

   • PR yazarının yorumlara yanıt vermesi ve aynı dalda düzeltmeler yapması,

   • ve tüm yeni pushlar otomatik olarak mevcut PR'ye eklenir.

6. Birleştirme. Gözden geçirenler onayladıktan (varsa) ve CI geçtikten (yapılandırılmışsa) sonra PR birleştirilebilir. Tipik olarak, birkaç birleştirme seçeneği vardır:

• Merge commit: Dal geçmişini koruyarak ayrı bir birleştirme commiti oluşturur.

• Squash and merge: Tüm PR commitlerini hedef dala eklenen tek bir commitle birleştirir. Geçmişi "yazım hatası düzeltildi" gibi küçük commitlerle karmaşık hale getirmekten kaçınmak için kullanışlıdır.

• Rebase and merge: PR commitlerini hedef dalın (bizim durumumuzda develop) üzerine yeniden uygular. Bu, temiz ve doğrusal bir geçmiş oluşturur.

Bizim amaçlarımız doğrultusunda, tüm commit geçmişini korumak istediğimiz için ilk seçeneği seçeceğiz. Bu yüzden, 'Merge commit oluştur' seçeneğine tıklayalım.

Şimdi Pull talebi işlemlerinin son sayfası geldik. Burada geçici geliştirme dalını kapatmak için '... dalını sil' seçeneğini işaretliyoruz. Commit geçmişi, dalın var olduğunu yansıtmaya devam edecektir. Ancak amacımıza ulaştığımız için açık tutmanın bir anlamı yok. Diğer görevleri çözen gelecekteki değişiklikler için yeni dallar oluşturacağız. Bu şekilde, deponun dal listesi her zaman devam etmekte olan paralel çalışmaların net bir görüntüsünü sağlar.

Geri kalan ayarları olduğu gibi bırakalım ve 'Merge commit oluştur' seçeneğine tıklayalım.

İşlem artık tamamlandı: article-17698-forge2 dalı develop ile birleştirildi ve silindi:

Genel olarak, kendi deponuzda Pull talebi kullanmak, proje üzerinde tek başınıza çalışıyor olsanız bile iyi ve doğru bir uygulamadır. Birleştirmeden önce, tüm değişiklikleri görsel olarak inceleyebilir ve genellikle commitler sırasında gözden kaçan şeyleri yakalayabilirsiniz: gereksiz yorumlar, başıboş dosyalar veya ideal olmayan düzenlemeler. Esasen bu bir tür öz disiplindir. Dahası, bu iş akışını benimsemek iyi alışkanlıklar (dallar oluşturma, kodu gözden geçirme vb.) oluşturur. Dolayısıyla, daha sonra bir geliştirme ekibine katılırsanız, bu süreç size zaten tanıdık gelecektir.

Yani evet - PR'leri kendinize göndermek sadece mümkün olmakla kalmaz, aynı zamanda herhangi bir ciddi proje için de tavsiye edilir. Kod kalitesini artırır ve disiplini güçlendirir. Elbette, bir veya iki committen oluşan hızlı düzeltmeler için, doğrudan Git Merge ile birleştirmenizi engelleyen hiçbir şey yoktur. Ancak daha büyük değişiklikler için PR daha iyi bir yaklaşımdır.

Sonuç

Genel olarak, kişisel depolarla iş akışı artık iyi bir şekilde oluşturulmuştur. Depoları klonlamaktan, değişikliklerin kodu işlevsel ve daha fazla geliştirmeye hazır hale getirdiği bir süreci rafine etmeye kadar olan yolu ele aldık. Proje deposu artık başka bir depodaki (veya birkaç depodaki) kodu kütüphane olarak anlamlı bir şekilde kullanabilir.

Ancak, yalnızca bir senaryoyu ele aldık: aynı kullanıcı hem proje hem de kütüphane depolarına sahip olduğunda. Diğer senaryo ise proje sahibinin başkasının depolarını kütüphane olarak kullanmak istemesidir. Bu senaryo o kadar basit değildir. Topluluğun kodlarının aktif olarak yeniden kullanımı ve işbirliği ile bu tür bir iş akışı, yeni depo sistemine geçmenin arkasındaki belirtilen hedeflerden biriydi. Ve temelleri atıldı.

Şimdilik burada duracağız. Bir sonraki bölümde görüşmek üzere!