Git Branch Stratejileri Part-II

GitHub Flow Nasıl Çalışır?

1-) Akış main (master) branch üzerinde başlar.

Main branch ana branch’tir ve proje buradan takip edilir. Yeni bir feature branch’i açıldıktan sonra ve gerekli çalışmalar yapıldıktan sonra nihai olarak main branch ile birleştirilmelidir.

2-) Yeni branch oluşturulur.

Dallanma Git’teki anahtar kavramdır ve main branch’in her zaman dağıtılabilir (distributable) olması kuralı etrafında çalışır.

Yeni bir şey denemek veya deney yapmak istiyorsanız, yeni bir branch oluşturursunuz (yukarıdaki akışta feature branch’i). Dallanma size main branch’i etkilemeden değişiklik yapabileceğiniz bir ortam sağlar.

Yeni branch’iniz hazır olduğunda gözden geçirilebilir, tartışılabilir ve hazır olduğunda main branch ile birleştirilebilir.

Yeni bir branch oluşturduğunuzda, (neredeyse her zaman) bunu main branch’ten yaparsınız.

3-) Değişiklik yapıp commit atılır.

Yeni branch oluşturulduktan sonra işe koyulma zamanı gelmiştir. Dosya ekleyerek, düzenleyerek ve silerek değişiklikler yapın. Küçük bir kilometre taşına(milestone) ulaştığınızda, değişiklikleri commit ederek branch’inize ekleyin.

Commit eklemek çalışmanızın kaydını tutar. Her işlemin neyin neden değiştiğini açıklayan bir mesajı olmalıdır. Her commit, branch’in geçmişinin bir parçası ve gerektiğinde geri dönebileceğiniz bir nokta haline gelir.

4-) Pull request isteği yapılır.

Pull request istekleri GitHub’ın önemli bir parçasıdır. Bir pull request (çekme isteği), değişiklikleri değerlendirmeleri veya incelemeleri için hazırladığınızı ilgili kişilere bildirir.

Başkalarından değişikliklerinizi gözden geçirmelerini isteyebilir veya çalışmanızı çekip kendi branch’leriyle birleştirebilirsiniz.

5-) Commit’ler incelenir ve tekrar gözden geçirilir.

Bir pull request yapıldığında, branch’e uygun erişimi olan herkes tarafından incelenebilir. Tartışmaların ve değişikliklerin gözden geçirilmesinin gerçekleştiği yer burasıdır.

Pull Request, insanların kolayca birlikte çalışmasını ve birlikte daha iyi sonuçlar üretmesini sağlamak için tasarlanmıştır!

Geri bildirim alırsanız ve değişikliklerinizi geliştirmeye devam ederseniz, değişikliklerinizi yeni commitlerle pushlayarak daha fazla incelemeyi mümkün kılabilirsiniz.

6-) Deploy gerçekleşir.

Pull Request gözden geçirildiğinde ve her şey iyi göründüğünde, son testin zamanı gelmiştir. Git Hub Flow , main branch ile birleştirmeden önce production için son test için bir branch’ten deploy yapmanıza olanak tanır.

7-) Merge işlemi yapılır.

Kapsamlı testlerden sonra kodu main branch ile birleştirebilirsiniz!

Pull Request kodunuzdaki değişikliklerin kaydını tutar ve değişiklikleri iyi bir şekilde yorumlayıp adlandırdıysanız, geriye dönüp değişikliklerin ve kararların neden alındığını anlayabilirsiniz.

GitHub Flow Kimler İçin?

Geliştirme ekiplerimizin küçük bir Agile ekip olduğunu ve her repo için ürünümüzün tek bir sürüm versiyonuna sahip olduğumuzu varsayalım. Yukarıda bahsettiğimiz özelliklerde bir ekibe ve ürüne sahipseniz kazanan GitHub Flow’dur.

GitHub Flow, sürekli dağıtım ve yayınlamayı desteklemenin oldukça basit ve etkili bir yoludur. Ekibi yeni özellikler ve hataların düzeltilmesi için açıkça tanımlanmış bir süreç etrafında hizalamanın bir yolunu sunarken, aynı zamanda olabildiğince akıcı ve teslimat odaklı tutar.

3-) GitLab Flow

GitLab Flow nedir?

GitLab Flow, Git Flow’a göre daha basit bir alternatiftir ve feature odaklı development ile feature branch’lerini issue tracking (sorun takibi) ile birleştirir. GitLab Flow ile, tüm feature ve hotfix’ler main branch’e giderken, production (üretim) ve stable (kararlı) branch’ler etkinleştirilir. GitLab Flow, yazılım geliştirme ekiplerinin özellikleri işbirliği içinde çalışması için sorunsuz bir süreç izlemelerini sağlamak için bir dizi en iyi uygulama ve yönerge içerir.

GitLab Flow nasıl çalışır?

Git Flow ile geliştiriciler bir develop branch’i oluşturup bunu varsayılan hale getirirken, GitLab Flow hemen ‘main’ branch ile çalışır. GitLab Flow, değişiklikleri üretime geçmeden önce main branch’le merge etmeden önce hotfixes ( hata düzeltmeleri) yapmak için bir production öncesi branch içerir. Ekipler gerektiği kadar production öncesi branch ekleyebilir. Örneğin, main branch’ten teste, testten acceptance’e (kabule) ve kabulden production’a.

Esasen, ekipler feature branch’lerini uygularken aynı zamanda ayrı bir production branch’inide korurlar. ‘main’ branch dağıtılmaya hazır olduğunda, kullanıcılar bunu production branch’iyle birleştirir ve yayınlar. GitLab Flow genellikle production branch’leriyle birlikte kullanılır. Genel bir API’ye ihtiyaç duyan ekiplerin farklı sürümleri korumaları gerekebilir. GitLab Flow’u kullanarak ekipler, ayrı ayrı sürdürülebilen bir v1 branch’i ve bir v2 branch’i oluşturabilir; bu, ekip kod incelemeleri sırasında v1'e kadar uzanan bir hata tespit ederse yararlı olabilir.

Ekibiniz için En İyi Branch Stratejisini Nasıl Seçersiniz?

Başlardayken işleri basit tutmak en iyisidir ve bu nedenle başlangıçta GitHub Flow en iyi sonucu verebilir. Ayrıca, bir release’in yalnızca tek bir release tarafından korunmasını gerektiren daha küçük ekipler için de idealdir.

GitFlow, değişikliklere sıkı erişim kontrolü gerektiren açık kaynaklı projeler için mükemmeldir. Açık kaynaklı projeler herkesin katkıda bulunmasına izin verdiği için bu özellikle önemlidir ve bu nedenle Git Flow ile kaynak koduna neyin eklendiğini kontrol edebilirsiniz.

Ancak GitFlow, bir DevOps ortamı uygulamak istediğinizde uygun değildir. Bu durumda, tartışılan diğer stratejiler Agile DevOps süreci için ve CI/CD hattınızı desteklemek için daha uygundur. Aşağıda hangi stratejiyi hangi durumlarda kullanılması gerektiğini gösteren tabloyu okuyup şirketiniz için en uygun olanı seçebilirsiniz.