Git Branch Stratejileri Part-I
Branch Stratejileri şirketlerin büyümesi ve daha karmaşık kompleks projelere başlaması nedeni ile versiyonların kontrolü, geriye dönük takip, ve iş geliştirme süreçlerinin takibinin zorlaşmasından doğmuştur.
Bazı yazılım geliştiriciler ve şirketler tarafından geliştirilen ve temel olarak kabul ettiğimiz 3 adet branch stratejisi mevcuttur. Bu yazımızda stratejilerin ne olduğuna, nasıl çalıştıklarına, avantajlarına ve dezavantajlarına bakacağız. Agile proje yönetimi ve DevOps süreçleri için olmazsa olmaz olan bu 3 branch stratejimizi tanıyalım.
1-) Git Flow
2-) Github Flow
3-) Gitlab Flow
1-) Git Flow
Git Flow, Vincent Driessen tarafından Git için oluşturulmuş bir branch modelidir. Git Flow sürekli yazılım geliştirmeye ve DevOps uygulamalarını hayata geçirmeye yardımcı olan bir git iş akışıdır. Yazılım geliştirme ekibinin işi ölçeklendirebilmesi için çok uygun olması nedeni ile büyük ilgi görmüştür.
Daha büyük projeleri yönetmek için sağlam bir çatı sağlar. Sürümleri hazırlamak, sürdürmek ve kaydetmek için ayrı branch’ler kullanır.
Temel Faydalar
- Parallel Development (Paralel Geliştirme)
Git Flow’un en güzel yanlarından biri olan parallel development avantajı, yeni geliştirmeleri bitmiş işlerden izole ederek parallel development’ı çok kolay hale getirir.
2. Collaboration (İşbirliği)
Fature branchleri aynı zamanda iki veya daha fazla geliştiricinin aynı özellik üzerinde işbirliği yapmasını kolaylaştırır, çünkü her feature branch, yalnızca yeni özelliğin çalışması için gerekli değişikliklerin yapıldığı sanal bir alandır.
3. Release Staging Area (Serbest Bırakma Hazırlama Alanı)
Yeni geliştirmeler oldukça henüz yayımlanmamış olan tüm tamamlanmış özellikler için bir hazırlama alanı olan develop branch ile birleştirilir. Böylece bir sonraki sürüm develop branch’inden ayrıldığında otomatik olarak tamamlanan tüm yeni geliştirmeleri içerecektir.
4. Support For Emergency Fixes (Acil Durum Düzeltmeleri İçin Destek)
Git Flow, taglenmiş olan bir sürümden oluşturulan branchler olan hotfix branchini destekler. Bunları düzeltmenin (hotfix’in) yalnızca acil olan düzeltmenizi (hotfix’inizi) içerdiğini bilerek acil bir değişiklik yapmak için kullanabilirsiniz. Aynı anda yanlışlıkla yeni geliştirmeyi birleştirme riskiniz yoktur.
Git Flow’un ne olduğunu ve temel faydalarını öğrendikten sonra esas konu olan ve git flow’u daha yakından tanımamızı ve anlamamızı sağlayacak olan branchler konusu, destekleyici görseller ile anlamayı kolaylaştırıcı hale getirdim.
Nasıl Çalışır ?
Bu iş akışı, projenin geçmişini kaydetmek için tek bir ana branch yerine iki branch kullanır. Temel olarak main ve develop olmak üzere sonsuz ömürlü iki ana branch dayanır.
- Main Branch : Main Branch üretim kodunu içerir ve resmi sürüm geçmişini saklar.
- Develop Branch : Develop branch, üretim öncesi kodu içerir ve özellikler için bir entegrasyon branch’i olarak hizmet eder.
Bir main branch ile repo kurulumumuz olduğunu varsayalım. İlk adım, varsayılan main branch bir development branch’i ile tamamlamaktır. Bunu yapmanın basit bir yolu, bir geliştiricinin yerel olarak boş bir develop branch’i oluşturması ve bunu sunucuya pushlamasıdır. Bu branch projenin tüm geçmişini içerecektir. Diğer geliştiriciler şimdi merkezi depoyu klonlamalı ve geliştirme için bir izleme branch’i oluşturmalıdır. Merkezi depolar her zaman boş olmalıdır buna göre yaratılmalıdır.
Nasıl çalıştığını anlamakta biraz zorlanmak normal çünkü diğer stratejilere göre biraz daha komplike. Daha iyi anlamak için git flow branchlerinin ne olduğunu ve neden bu branchleri yarattığımızı anlatmamız gerek. Branchlerin neden yarattığımızı ve hangi durumlarda kullanıldığını anladığınızda kafanızda git flowa dair hiçbir soru işareti kalmayacak.
GitFlow Genel akışı
- Main Branch’ten bir Develop branch’i oluşturulur.
- Feature branch’leri develop yapmadan önce oluşturulur.
- Bir özellik (feature) tamamlandığında develop branch’iyle birleştirilir.
- Develop’tan bir release branch’i oluşturulur.
- Release branch’i tamamlandığında develop ve main branchleri ile birleştirilir.
- Main’de bir sorun tespit edilirse main’den bir hotfix branch’i oluşturulur.
- Düzeltme tamamlandığında hem develop hem de main ile birleştirilir.
Git Flow Branch’leri
1-) Main ve Develop Branch (Ana Branch ve Geliştirme Branch’i)
Main ve Develop branchleri iki ana branch olduklarından ikisini bir arada ele almak istedim. Main Branch resmi yayın geçmişini saklar ve develop branch özellikler için bir entegrasyon branch’i olarak hizmet eder. Main branchteki tüm commitleri bir sürüm numarasıyla etiketlemek de uygundur.
İlk adım, varsayılan main branch’i bir develop branch’i ile tamamlamaktır. Bunu yapmanın basit bir yolu, bir geliştiricinin yerel olarak boş bir develop branch’i oluşturması ve bunu sunucuya göndermesidir.
2-) Feature Branch (Özellik Branch’i)
Feature Branch İş Akışının arkasındaki temel fikir, tüm feature geliştirmenin main branch yerine özel bir branch’te gerçekleştirilmesidir. Bu kapsülleme, birden fazla geliştiricinin ana kod tabanını bozmadan belirli bir özellik üzerinde çalışmasını kolaylaştırır. Ayrıca main branch’inin asla bozuk kod içermemesi gerektiği anlamına gelir ki bu da, sürekli entegrasyon ortamları için büyük bir avantajdır.
Bir feature tamamlandığında, develop branch ile geri birleştirilir. Feature branch asla main ile doğrudan etkileşime girmemelidir.
3-) Hotfix Branch (Düzeltme Branch’i)
Bakım veya “hotfix” branch’leri, üretim sürümlerine hızlı bir şekilde yama yapmak için kullanılır. Hotfix branch’leri , main’in istenmeyen bir durumu üzerine hemen harekete geçmek için gereklidir. Hotfix branch’leri , develop branch’i yerine main’i temel almaları dışında release ve feature branch’lerine çok benzer. Bu, doğrudan main’den çatallanması gereken tek branch’tir. Düzeltme tamamlanır tamamlanmaz hem main hem de develop (veya mevcut release branchi) ile birleştirilmeli ve main güncellenmiş bir sürüm numarası ile etiketlenmelidir.
4-) Release Branch (Sürüm Branch’i)
Develop branch’i bir sürüm için yeterli özellik edindiğinde (veya önceden belirlenmiş bir sürüm tarihi yaklaştığında), develop’dan bir release branch’i çatallandırırsınız. Bu branch’i oluşturmak bir sonraki sürüm döngüsünü başlatır, bu nedenle bu noktadan sonra yeni özellikler eklenemez. Yalnızca hata düzeltmeleri, belge oluşturma ve diğer sürüm odaklı görevler bu branch’e gitmelidir.
Release branch’leri yeni bir üretim sürümünün hazırlanmasını destekler. Birçok küçük hatanın düzeltilmesine ve bir sürüm için meta verilerin hazırlanmasına izin verirler. Develop branch’ten dallanabilir ve main ve develop branch ile birleştirilmelidir.
Gitflow’u kimler kullanmalı (ve kullanmamalı) ?
Kuruluşunuz aylık veya üç aylık bir sürüm döngüsündeyse ve paralel olarak birden fazla sürüm üzerinde çalışan bir ekipse, Git Flow sizin için iyi bir seçim olabilir. Ekibiniz bir startup veya internete dönük bir web sitesi veya web uygulamasıysa, bir günde birden fazla sürümünüz olabilir; Git Flow sizin için iyi değildir. Ekibiniz küçükse, git flow işinize çok fazla karmaşıklık ve ek yük getirir.
Öte yandan, ekipleriniz paralel sürümler üzerinde çalışan 20'den fazla kişiden oluşuyorsa, gitflow işleri karıştırmamanızı sağlamak için yeterli düzeni sunar.
Avantajları
- Projenin yaşam döngüsünün herhangi bir anında branch’in temiz bir durumda olmasını sağlar.
- Branch’lerin adlandırılması, anlaşılmasını kolaylaştıran sistematik bir model izler.
- En çok kullanılan git araçlarında uzantılara ve desteğe sahiptir
- Üretimde birden fazla versiyon olması gerektiğinde idealdir.
Dezavantajları
- Git history okunamaz hale gelir.
- Main/develop ayrımı gereksiz olarak kabul edilir ve sürekli teslimat ve sürekli entegrasyonu zorlaştırır.
- Üretimde tek bir versiyonun korunması gerektiğinde önerilmez.
2-) GitHub Flow
GitHub flow, Git ve GitHub ile iyi çalışmak üzere tasarlanmış bir iş akışıdır. Dallanmaya odaklanır ve ekiplerin özgürce denemeler yapmasını ve düzenli olarak deployment yapmasını mümkün kılar. GitHub flow şu şekilde çalışır: Yeni bir branch oluşturun. Değişiklikler yapın ve Commits ekleyin.
GitHub Flow, kodu hızlı bir şekilde yayınlayabilmek isteyen küçük bir ekip için en iyi sonucu verir. Kodu sürekli olarak deployment ve publish yeteneği istediğinizde etkili bir şekilde çalışır. Git Flow ile karşılaştırıldığında basit tasarım yapısı sayesinde agile bir dallanma stratejisidir.
Github Flow Akışı
Git Flow’un aksine Github Flow’da release branchleri yoktur. Github Flow’un fikirlerine göre, bir sürüm kullanıma hazır olduğunda dağıtılabilir. Benzer şekilde GitHub Flow, hotfix’lerin küçük feature değişiklikleriyle aynı olduğuna ve işleme yöntemlerinin benzer olması gerektiğine inanmaktadır.
- Main branch’teki tüm kod, dağıtılabilecek en son çalışma sürümüdür.
- Yeni bir görevi gerçekleştirmek için main branch’ten yeni bir branch oluşturulur ve amacını ortaya koymak için açıkça adlandırılır, örneğin yeni bir zamanlama stratejisi.
- Kod değişiklikleri yerel branch’e mümkün olduğunca sık merge edilmelidir. Bu arada, değişiklikler sunucuda aynı branch adına sahip branch’e mümkün olduğunca sık senkronize edilmelidir.
- Yeni kodu main branch ile birleştirmek istiyorsanız, kod incelemesi talep etmek için bir pull request başlatmalısınız.
- Kod incelemesi geçtikten sonra veya kod incelemesi devam ederken, branch’in doğrulama için test ortamına dağıtılması gerekir.
- İnceleme ve doğrulama geçilirse, kod main branch ile birleştirilmelidir. Böylece main branch her zaman dağıtılabilir olur.
- En son feature paketi, main branch’teki en son koddan oluşturulur.
Hotfix işlemi aşağıdaki gibidir:
- Bir release’den sonra bir kusur bulunursa, main branch’ten bir hotfix branch’i oluşturulur (prod ortamına dağıtılan özel bir commit sürümünde).
- Hata düzeltilir ve ardından hotfix branch’inde doğrulanır.
- Hotfix branch main branch ile birleştirilir.
- Hotfix branch silinir.
