Hotfix Branch: Mobil geliştirmede oluşturma ve uygulama

Hotfix Branch Nedir?

Hotfix Branch, aktif bir production ortamındaki kritik kusurları hızlıca düzeltmek için oluşturulan geçici bir Git branch'idir. Develop'tan ayrılan ve günler veya haftalar süren feature branch'lerinin aksine, hotfix main/master'dan oluşturulur ve hatayı düzeltmek için gereken süre kadar var olur.

Hotfix'in ana amacı, kritik bir hatanın keşfedilmesi ile production'da düzeltilmesi arasındaki süreyi en aza indirmektir. Ekip, mevcut sprint veya sürüm döngüsünün bitmesini beklemez, hemen bir yama yayınlar. Bu, kritik bir hatanın kullanıcıları engelleyebileceği ve kayba yol açabileceği mobil uygulamalar için özellikle önemlidir.

Google Play Console'a göre, Google Play'de güncelleme inceleme süresi ortalama 2 ila 24 saattir. App Store için hızlı inceleme 1 ila 4 saat sürebilir. Hotfix branch'leri, inceleme tamamlanmadan önce düzeltmeyi hazırlamaya ve onaydan hemen sonra yayınlamaya olanak tanır.

Hotfix Nasıl Çalışır

Hotfix süreci üç adımdan oluşur: main'den branch oluşturma, düzeltmeyi yapma ve main ile develop'a geri birleştirme. Normal bir düzeltmeden temel fark, hotfix'in her zaman her iki branch'e de birleştirilmesidir, böylece düzeltme sonraki sürümde kaybolmaz.

Ekip, hotfix'e yeni işlevsellik veya yeniden düzenleme eklememelidir. Yalnızca kritik sorunu çözmek için minimum düzeyde gerekli olan hedefli düzeltme. Bu kuraldan herhangi bir sapma, gerileme riskini artırır ve yama yayınını geciktirir.

Hotfix Ne Zaman Gereklidir

Hotfix üç senaryoda gereklidir: kritik bir hata kullanıcıları engelliyorsa (çökme, veri kaybı), bir güvenlik açığı acil kapatılmayı gerektiriyorsa veya kritik iş mantığı bozulmuşsa (ödeme, kimlik doğrulama). Hata kritik değilse, normal sürüm döngüsü içinde develop üzerinden düzeltilebilir.

Mobil uygulamalar için, mimari uzaktan özellik değiştirmeye (feature flags) izin veriyorsa hotfix, sunucu tarafı değişikliklerini de içerebilir. Bu durumda, düzeltme sunucu tarafında yapılabiliyorsa hotfix branch'i minimum düzeyde olabilir veya hiç gerekmeyebilir.

Branch Modelleri ve Hotfix'in Yeri

Tüm branch modelleri hotfix branch'lerini desteklemez. Geleneksel Git Flow, hotfix'i tam teşekküllü bir branch türü olarak içerirken, daha modern yaklaşımlar (GitHub Flow, Trunk-based) acil düzeltmeleri farklı şekilde ele alır.

Git Flow ve Hotfix

Git Flow, hotfix'in feature ve release ile birlikte yerleşik bir branch türü olduğu tek modeldir. Git Flow'da hotfix main'den oluşturulur ve tamamlandığında hem main'e (bir sürüm etiketiyle) hem de develop'a birleştirilir. Bu, düzeltmenin sonraki sürümde kaybolmamasını sağlar.

GitHub Flow ve Trunk-based

GitHub Flow, hotfix için ayrı bir branch türü kullanmaz. Bunun yerine, geliştirici main'den normal bir feature branch'i oluşturur, düzeltmeyi yapar ve bir Pull Request açar. İnceleme ve CI kontrollerinden sonra branch main'e birleştirilir ve hemen dağıtılır. Avantajı basitliktir, dezavantajı acil düzeltmeler için özel bir kanalın olmamasıdır.

Trunk-based geliştirme, hotfix'i (kritik durumlar için) doğrudan main'e commit'lerle ve zorunlu sonradan incelemeyle ele alır. Bu yaklaşım, yüksek ekip disiplini ve güvenilir otomatik testler gerektirir, çünkü değişiklikler anında production'a gider.

Hotfix Branch Nasıl Oluşturulur

Hotfix oluşturma, ana branch'e geçip hotfix/ önekiyle yeni bir branch oluşturarak başlar. Bir mobil uygulamadaki kritik hatayı düzeltme örneğiyle adım adım süreci inceleyelim.

main'den branch oluşturma

İlk adım — main'e geçin ve branch'in güncel olduğundan emin olun. Ardından, düzeltmenin doğasını yansıtan net bir adla hotfix branch'i oluşturun.

# main'e geç ve en son değişiklikleri al
git checkout main
git pull origin main

# Bir hotfix branch'i oluştur
git checkout -b hotfix/crash-on-login

Branch'i oluşturduktan sonra düzeltmeyi yapabilirsiniz. Unutmamak önemlidir: hotfix minimum sayıda değişiklik içermelidir. Kodu yeniden düzenlemeyin veya yeni özellikler eklemeyin — yalnızca sorunu çözen hedefli düzeltme.

Düzeltmeyi commit'leme

Hotfix'teki commit, sorunu ve çözümünü açıkça tanımlayan bilgilendirici bir mesaja sahip olmalıdır. Biçim: tür(alan): kısa açıklama + tracker'daki görev bağlantısı.

# Değiştirilen dosyaları ekle
git add src/ui/login/LoginActivity.kt

# Açıklamayla bir commit oluştur
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

Commit mesajı bir sorun açıklaması ve görev bağlantısı içermelidir. Bu, geçmişte aramayı kolaylaştırır ve meslektaşların neyin neden düzeltildiğini anlamasına yardımcı olur. Mobil projeler için, hatanın bulunduğu uygulama sürümünü de eklemek yaygındır.

main ve develop'a birleştirme

Son adım, hotfix'i main'e (yeni bir yama sürüm etiketiyle) ve develop'a (düzeltmenin sonraki sürümde korunması için) geri birleştirmektir. Önce main'e etiketle birleştirin, ardından develop'a birleştirin.

# main'de birleştir ve bir etiket oluştur
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# develop'da birleştir
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Değişiklikleri sunucuya gönder
git push origin main --tags
git push origin develop

--no-ff bayrağı, hotfix fast-forward ile uygulanabilse bile bir birleştirme commit'inin oluşturulmasını sağlar. Bu, acil bir düzeltme yapıldığı bilgisini korur ve gelecekte geçmiş analizini basitleştirir.

Hotfix, Feature ve Release Branch'leri Arasındaki Fark

Hotfix, amaç, ömür ve birleştirme kuralları açısından feature ve release branch'lerinden temel olarak farklıdır. Bu farklılıkları anlamak, ekipte Git süreçlerini doğru şekilde organize etmek için kritiktir.

Feature branch'i yeni işlevsellik içindir. Birkaç günden birkaç haftaya kadar yaşar, develop'tan oluşturulur ve develop'a geri birleştirilir. Feature, daha sonra squash veya rebase ile sıkıştırılan deneysel olanlar dahil birçok commit içerebilir.

Release branch'i sürümü dağıtıma hazırlar. Develop'tan oluşturulur, stabilizasyon sırasında bulunan hatalar düzeltilir ve yeni işlevsellik kabul etmez. Tamamlandıktan sonra release, main'e (etikette) ve develop'a birleştirilir.

Hotfix ise, develop'ı atlayarak doğrudan main ile oluşturulur ve birleştirilir (ancak düzeltmeden sonra develop ile de senkronize edilir). Minimum sayıda değişiklik içerir ve minimum süre boyunca var olur. Feature veya release branch'leri sonraki döngüye ertelenebilirken, hotfix ertelenemez.

Mobil geliştirme için bu ayrım özellikle önemlidir: App Store ve Google Play, yama sürümlerinin ana sürümlerden ayrı olarak yayınlanmasına izin verir. Hotfix branch'i, bir yama sürümünün tamamlanmamış özelliklerle karışmamasını sağlar.

Hotfix ile Çalışırken Sık Yapılan Hatalar

Hotfix ile çalışırken yapılan hatalar, acil düzeltmenin avantajlarını geçersiz kılabilir. Git Flow kullanan ekiplerde ortaya çıkan en yaygın beş soruna bakalım.

• Hotfix'i develop'tan oluşturma — hotfix develop'tan oluşturulursa, tamamlanmamış özellikler yamaya girebilir. Hotfix yalnızca main'den oluşturulmalıdır, böylece düzeltmeye yalnızca kararlı kod dahil edilir.
• Tek hotfix'te birden çok düzeltme — her düzeltme kendi hotfix branch'inde olmalıdır. Birden çok hatayı tek bir branch'te karıştırmak kod incelemesini karmaşıklaştırır, gerileme riskini artırır ve gerektiğinde geri almayı zorlaştırır.
• Develop'a birleştirmeyi atlama — hotfix develop'a birleştirilmezse, düzeltme sonraki sürümde kaybolur. Ekip aynı hatanın tekrar ortaya çıktığını görecek ve yeniden düzeltmek zorunda kalacaktır.
• Yanlış sürüm etiketi — hotfix bir yama artışı almalıdır (v2.3.0 → v2.3.1), alt (v2.4.0) veya ana (v3.0.0) artış değil. Anlamsal sürümlemeyi ihlal etmek derleme sistemini bozar ve kullanıcıların kafasını karıştırır.
• CI kontrollerinin eksikliği — acil hotfix bile otomatik testlerden geçmelidir. CI'yı atlamak yeni bir hata ekleme riskini artırır. Hızlandırılmış kontrollerle hotfix branch'leri için ayrı bir pipeline olması önerilir.

Bu hataların her biri, yama yayınında gecikmeye veya production'da yeni sorunların ortaya çıkmasına yol açar. Ekipler, hotfix ile çalışma kurallarını CONTRIBUTING.md'de belgelemeli ve CI/CD kontrolleri aracılığıyla otomatikleştirmelidir.