All Articles

Gitflow Branching Model

Gitflow

  • Hepimiz şirket projelerimizde ekipler halinde kod yazıyoruz ve ürün release süreçleri oldukça sancılı ilerliyor. Bu release(uygulamanızın versiyonları) süreçlerini daha görünür kılmak ve geliştirme esnasında oluşan sorunların çözümünü daha sistematik ve hızlı bir hale getirmek adına 2010 yılında GitFlow stratejisi Vincent Driessen tarafından ortaya atılıyor.
  • Geliştirmesi yapılacak her bir feature/task ayrı branch’e dallanılarak geliştirilir ve işin başarılı bir şekilde tamamlanmasının ardından ana branch’e merge edilmesi temeline dayanır.
  • Projenizin versiyonlar şeklinde yayınlanması durumunda önerilir. Eğer tek bir versiyon üzerinde çalışıyorsanız önerilmez.
  • Birden fazla birincil branch mantığı üzerine oturtulmuş bir git branching modelidir. Gitflow modeli 5 ayrı tür branch üzerine kurulur;

    • Master branch
    • Feature branch
    • Release branch
    • Hotfix branch
    • Develop branch

Master branch

  • En kararlı ve stabil olan branch’inizdir. Bitmemiş iş kesinlikle alınmayacak ve herhangi bir t anında release alınmaya uygun olacaktır. Her feature/task tamamlanmasının ardından master branch’inize merge edilecektir. (production ortama çıkışın tek yolu)
  • Genellikle release çıkılma zamanında tag ile belirtilerek görünürlük artırılır.

Feature branch

  • Geliştirmelerimizi yapmamız için oluşturacağımız branch’tir.
  • Develop branch’i üzerinden oluşturulur ve yine feature/task tamamlanmasının ardında develop branchine merge edilerek değişikliklerin develop branch’ine alınması sağlanır.

Release Branch

  • Uygulamanızın yeni bir sürümünü çıkmak için hazır olduğunuzda açılması gereken branch’tir. Release branchleri release- ön eki ile birlikte versiyon numarası şeklinde açılması önerilir. Örnek: release-v1.1
  • Bu ortamda uat testleri vs gerçekleştirilecektir. Yalnızca geliştirmelerinizin bugları ve problemleri ele alınmalıdır. Herhangi bir geliştirmenin muhatabı olmamalıdır. Bu branch yalnızca feature/task testleri ve problemlerin fix’leri hedefli olmalıdır.
  • Testler başarılı ise release branch’i master’a merge edilerek geliştirmeler bir üst kararlı ortam olan master’a alınmalıdır. Bu merge işlemini develop branch’ine de yaparak develop branch’inin de güncel tutulması sağlanır.
  • Merge işlemleri ardından release üzerindeki tüm düzenlemeler daha kararlı olan master ortamına merge edildiği için ilgili uygulama versiyonu özelinde hazırlanan bu release branch’i silinir.

Hotfix Branch

  • Master branchinizde ani bir sorunla karşılaştığınızda hızlıca bir yama işlemi için hotfix branchi oluşturarak bu işlemi yapabilirsiniz.
  • Master branch üzerinden oluşturulur.
  • Bu branchler ön ek olarak hotfix- ile başlaması önerilir.
  • Bir hotfix branch ile sorunu çözmenizin ardından bu branch’i master ve develop branchlerine(sorunun orada da fix edilebilmesi için) merge etmeniz gerekir.
  • Master ortama merge işlemi ardından bu branchler silinebilir. Tek kullanımlık branchlerdir.

Develop Branch

  • Geliştirmenin ana hattı olacak branch’tir. Geliştirme için açılacak olan feature branchler bu branch üzerinden dallanır ve tamamlanmasının ardından yine bu branch’e merge edilir.
  • Develop branch’i master üzerinden oluşturulmalıdır.
  • Release ortamda testi gerçekleştirilen bir feature’da çıkan olası hata tekrardan develop branch’ine de merge edilmelidir.

Örnek Senaryo

  • Süleyman dahil olduğu projede ABC-123 taskına bağlı bir feature geliştirmeye başlayacak. Gitflow mantığında adım adım nasıl ilerleyeceğini ele alalım.

    1. Süleyman ilk olarak geliştireceği feature için develop branch’i üzerinden lokalinde bir feature branch olarak ABC-123 branch’ini oluşturacak. create branch

    1. Lokalde oluşturduğu ABC-123 branchi üzerinde tüm geliştirmesini tamamlayacak ve feature’un tamamlanmasının ardından develop branch’ine ABC-123 branch’ini merge edecek. merge branch

    1. Ardından uat testlerinin yapılması için oluşturulmuş olan(release-v1.1 olsun) branch’e develop branch’ini merge edecek. merge branch

    1. Release üzerinde yapılan testlerde Süleyman’ın geliştirmesinde bir bulgu görüldü ve bunu fix etmesini istediler. Süleyman ABC-123 branchinde düzeltmesini gerçekleştirip develop ve release branchlerine merge edecek. merge branch

    1. Tüm testlerden başarıyla geçen feature’un master ortama aktarılmasına onay verilir ve Süleyman ilgili feature’u master ortama merge ederek feature geliştirmesini tamamlamış olur. merge branch

    1. Süleyman’ın geliştirmesinin master ortama merge edilmesinin ardından prod ortama çıkılan feature’da bir bulgu görülüyor ve acil bir şekilde Süleyman’ın düzeltmesi isteniyor. Süleyman bu hatayı düzeltmek için master ortamdan bir hotfix branch’i ile geliştrmesini tamamlayarak master ve develop branchlerine gönderecek. merge branch

Sonuç

Bu yazıda git perspektifinde Gitflow branching modelleme ile alakalı temel gereksinimleri ve mimariyi ele alarak canlı bir örnek üzerinde şematize etmeye çalıştım. Yazımı burada sonlandırıyorum, umarım faydalı olur. :)

Referans