GitFlow ve GithubFlow
Selamlar Herkese,
Uzunca zamandır üzerine mesai harcadığım git branch/dallanma yapısını dilim döndüğünce sizlere anlatmaya çalışacağım. Developer takımları
şirket içinde nasıl bir git branch yapısı seçmekte zorlanıyor işte bu yazı aslında bu zorlananlar için. Şimdi ilk önce birkaç kavramı baştan yazayım.
Bugfix: Kod teste gider ve testçinin bulduğu hataya denir.
Hotfix: Kod test ekibinden çıkar ve müşteriye gider, müşterinin bulduğu hatadır.
Pr: Pull Request Developer’ların ilgili branchlere mergelenmek üzere gönderdiği koddur.
Review: PR açılınca kodu kontrol eden kişi/kişilerdir. (En az iki tane olmalı bence)Feature: Yeni bir istek ya da planlı bir iş sonucu çıkan kodlar
Şimdi ilk olarak iki yapıyı tanıyalım sonra karşılaştıralım, avantaj dezavantaj yapalım.
GithubFlow
Aslında küçük ölçekli şirketler ve arkadaş grubu olarak kod geliştiryorsanız işte bu aradığınız git branch yapısı.
Neden mi çünkü testçi yok :) Neden mi kodu doğrudan son kullanıcıya gönderiyorum? Ben dünyanın en iyi yazılımcısıyım, yaşasın! Ne gerek var testçiye değil mi? İşin şakası tabii. Aşağıda bu yapıdan kısaca bahsetmeye çalışayım.
Bir master/main branchimiz var ve bu branchi ilk çıkış branchi olarak düşünebiliriz. Yani T0 halindeki hali. Haydi şimdi T0'dan ilerleyelim ve kodumuzu geliştirelim, ne yapacağız ilk olarak master branchden bir feature branche alacağız ismini de önerim “feature/nick_name_tarih” yaptık , sonra feature canlıya gidecek geliştirmeyi localimizde tamamladık. Tamam artık hazırız kodu master/main ile mergelemeye, “feature/nick_name_tarih” to merge master…İşte bu kadar, artık hazırız :)
Özetle: Master/Main branchden al geliştirmeni yap ve geri master/main branche gönder.
GitFlow
Kurumsal yapıda kod geliştirenler için bulunmaz bir yapı aslında. Test desen var, bugfix desen var, hotfix desen var. Tamam da nedir bu GitFlow ?
GitFlow yine githubflow gibi master/main branchden başlar, sonrasında developer arkadaşlar kodu geliştirir ve developmen branchine pr açarlar (HER PR REVİEW KONTROLÜNDEN GEÇMELİ: RULE IS RULE ) sonrasında bu kod bir test ortamına atılarak testçi tarafından test edilir, testçi hata bulursa bugfixler developerlar tarafından çözülür ve bir paket numarasıyla müşteri ortamına gönderilir. Müşteri test ortamları genelde preprod ya da uat olarak adlandırılır. Devam ediyoruz :) uat ya da preprod ortamındayız. Uat/Preprod ortamlarında müşteri hata bulursa hotfixler developer arkadaşlar tarafından çözülür ve en son çıkış noktamız master/main branche pushlanır.
Kısaca: Müşteriye en az hata ile kodu göndermek , kulağa hoş geliyor değil mi?
Sonuç: Avantajlar ve Dezavantajlar
Okuduğunuz için teşekkürler.
