Git'te Release Branch — nedir, amacı ve iş akışı

Git'te Release Branch Nedir

Release Branch (sürüm dalı), ekibin mevcut özellik setinin yayına hazır olduğuna karar verdiğinde develop'tan oluşturulan Git Flow'taki geçici bir daldır. Son sürüm hazırlığı ne kadar sürerse (birkaç saatten birkaç güne kadar) o kadar süre var olur.

Sürüm dalının temel amacı, sonraki sürümlerin geliştirilmesini durdurmadan belirli bir özellik setini yayın için dondurmaktır. Sürüm dalı dağıtıma hazırlanırken, diğer geliştiriciler bir sonraki sürüm için develop'a özellik dallarını birleştirmeye devam edebilir.

Sürüm dalında yeni özellikler oluşturulmaz — yalnızca hata düzeltmeleri, uygulama sürümü güncellemesi, yerelleştirme ve dokümantasyon yapılır. Tüm çalışmalar tamamlandıktan sonra, sürüm dalı main'e (sürüm olarak işaretlenir) ve develop'a (hata düzeltmelerinin gelecek sürümlere ulaşması için) birleştirilir.

Atlassian, 2024'e göre, sürüm dalları düzenli yayın döngüleri olan projeler için kritik öneme sahiptir — yayın sürecinin öngörülebilirliğini ve istikrarını sağlarlar.

Sürüm dalının yaşam döngüsü

Sürüm dalının yaşam döngüsü, oluşturulmasından silinmesine kadar birkaç aşama içerir. Her aşamayı anlamak, ekibin eylemleri senkronize etmesine ve hatalardan kaçınmasına yardımcı olur.

1. Oluşturma — develop'ın son commit'inden release/2.5.0 adında bir dal oluşturulur. develop, sonraki sürüm için özellik dallarını kabul etmeye devam eder.
2. Hazırlık — sürüm dalında build.gradle, Info.plist ve diğer yapılandırma dosyalarındaki uygulama sürümü güncellenir.
3. Hata düzeltme — son testler sırasında bulunan kritik hatalar düzeltilir. Yalnızca hatalar — yeni özellik yok.
4. Son testler — QA ekibi sürüm dalında regresyon testleri yapar. Yeni hatalar aynı dalda düzeltilmek üzere gönderilir.
5. Main'e birleştirme — sürüm dalı, --no-ff bayrağıyla main'e birleştirilir. Sürüm etiketi oluşturulur: v2.5.0.
6. Develop'a birleştirme — sürüm dalı, sürümdeki hata düzeltmelerinin mevcut geliştirmeye ulaşması için develop'a geri birleştirilir.
7. Silme — görevi tamamlandığı için sürüm dalı yerel ve uzak olarak silinir.

6. adım — develop'a geri birleştirme — sıklıkla unutulur, ancak kritik öneme sahiptir. Bu adım olmadan, sürüm dalında yapılan hata düzeltmeleri develop'a ulaşmaz ve aynı hatalar bir sonraki sürümde tekrar ortaya çıkabilir.

Sürüm dalı aşamalarının tipik süreleri

Sürüm dalının ömrü, sürümün karmaşıklığına ve develop'taki kod kalitesine bağlıdır. Ortalama olarak, orta boy bir mobil uygulama için hazırlık 2 ila 5 iş günü sürer.

Sürüm dalında neler yapılır

Sürüm dalında kesinlikle sınırlı bir görev seti yürütülür. Bu listeden herhangi bir sapma, Git Flow modelini ihlal eder ve sürüm istikrarı için risk oluşturur.

Yeni özellik yasağı kuralı, sürüm dalında en önemlisidir. Bir özellik sürüme yetişmediyse, sonraki döngüyü bekler. Tamamlanmamış bir özelliği sürüm dalına itmeye çalışmak, son teslim tarihlerinin kaçırılmasının ve üretim hatalarının başlıca nedenidir.

Mobil projede sürüm güncelleme

Sürüm dalında uygulama sürüm numarası zorunlu olarak güncellenir. Android için bunlar build.gradle'daki versionCode ve versionName alanlarıdır; iOS için — Info.plist'teki CFBundleShortVersionString.

// build.gradle (uygulama düzeyi) — sürüm dalında sürüm güncelleme
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// iOS için — Info.plist güncelleme
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Release ve hotfix arasındaki farklar

Acemi geliştiriciler genellikle release ve hotfix dallarını karıştırır, ancak amaçları temelde farklıdır. Yanlış dal türünü seçmek, kritik bir düzeltmeyi geciktirebilir veya sürüm sürecini bozabilir.

• Kaynak — release develop'tan oluşturulur, hotfix main'den oluşturulur. Bu, diğer her şeyi belirleyen ana farktır.
• Acilik — release planlıdır: ekip hazırlığa ne zaman başlayacağına karar verir. Hotfix acildir: üretimdeki bir sorun acil düzeltme gerektirir.
• İçerik — release birden fazla düzeltme ve sürüm güncellemesi içerebilir. Hotfix yalnızca bir kritik düzeltme içerir.
• Birleştirme — release main ve develop'a birleştirilir. Hotfix de main ve develop'a birleştirilir, ancak öncelikli olarak.
• Yaşam süresi — release 1 ila 7 gün yaşar. Hotfix 30 dakika ila 1 gün yaşar.

Sürüm hazırlığı sırasında (sürüm dalında) bir hata bulunursa, bu normal bir hata düzeltmesidir. Üretimde (main'de) bir hata bulunursa, bu bir hotfix'tir ve sürüm dalı zaten mevcut olsa bile main'den oluşturulur.

Sürüm dalı adlandırma kuralları

Birleşik bir sürüm dalı adlandırma standardı, depo gezinmesini basitleştirir ve CI/CD sistemlerinin bir dalın sürüm sürecine ait olduğunu otomatik olarak algılamasını sağlar.

• release/X.Y.Z — standart Git Flow biçimi, X.Y.Z sürüm numarasıdır. Örnek: release/2.5.0.
• release/ad — sürüm kod adıyla alternatif biçim. Örnek: release/merlin.
• release/tarih — sürüm tarihiyle biçim. Sürüm tarihten daha önemli olduğu için nadiren kullanılır. Örnek: release/2024-12-01.

release/X.Y.Z biçimi tercih edilir, çünkü dalı sürüme atanacak sürüm numarasına açıkça bağlar. Bu, CI/CD betikleriyle aramayı ve otomatik işlemeyi basitleştirir.

Develop'a geri birleştirme stratejisi

Sürüm dalının develop'a geri birleştirmesi (merge back), en önemli ve aynı zamanda en sık atlanan işlemlerden biridir. Bu işlem olmadan, sürüm dalında yapılan tüm hata düzeltmeleri yalnızca sürüm sürümünde kalır ve sonraki sürüm döngüsüne ulaşmaz.

Geri birleştirme işlemi, sürüm dalı main'e birleştirildikten sonra gerçekleştirilir. Önce release develop'a birleştirilir, ardından silinir. Bu, develop'ın sürüm hazırlığı sırasında yapılan tüm düzeltmeleri içermesini sağlar.

Geri birleştirmeden sonra çakışmalar meydana gelebilir — özellikle aynı dosyaları değiştiren yeni özellik dalları develop'ta zaten görünmüşse. Sürümden sorumlu geliştirici bu çakışmaları çözer ve develop'ı sunucuya iletir.

Bazı ekipler, geçmişi doğrusal tutmak için geri birleştirme için merge yerine rebase kullanır. Ancak merge, develop için daha güvenlidir çünkü diğer geliştiriciler tarafından zaten kullanılıyor olabilecek commit geçmişini yeniden yazmaz.

Release ile çalışmak için komut örnekleri

Mobil uygulama sürümü 2.5.0'ın başarılı bir şekilde yayınlanmasının ardından sürüm dalıyla çalışmanın tam döngüsüne bakalım: oluşturmadan silmeye kadar.

# 1. Develop'tan sürüm dalı oluştur
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Sürüm ve hata düzeltmelerini güncelle
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Hataları düzelt (yalnızca bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Sürüm dalını sunucuya gönder
git push origin release/2.5.0

# 5. Release'i main'e birleştir
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Develop'a geri birleştir
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Sürüm dalını sil
git branch -d release/2.5.0
git push origin --delete release/2.5.0

5 ve 6 numaralı komutlar — çift birleştirme — kritik öneme sahiptir. Önce main sürüm kodunu ve etiketi alır, ardından develop sürümdeki hata düzeltmeleriyle senkronize olur. 6. adım atlanırsa, sürümdeki düzeltmeler sonraki geliştirme döngüsüne ulaşmaz.

Sürüm sürecini otomatikleştirme

Düzenli sürümleri olan mobil projeler için, sürüm dalı oluşturma ve sürüm güncelleme süreci CI/CD betikleri aracılığıyla otomatikleştirilebilir. GitHub Actions, bir düğmeye basıldığında otomatik sürüm güncellemesiyle bir sürüm dalı oluşturan bir iş akışı oluşturmayı sağlar.

Düzenli sürümleri olan mobil projeler için, sürüm dalı oluşturma ve sürüm güncelleme süreci CI/CD betikleri aracılığıyla otomatikleştirilebilir. GitHub Actions, bir düğmeye basıldığında otomatik sürüm güncellemesiyle bir sürüm dalı oluşturan bir iş akışı oluşturmayı sağlar.

# GitHub Actions — sürüm dalı oluşturmayı otomatikleştirme
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}