Git'te Feature Branch: nedir, dal nasıl oluşturulur ve bunlarla çalışılır

Git'te Feature Branch Nedir

Feature Branch (özellik dalı), belirli bir işlevselliği geliştirmek için develop'dan oluşturulan geçici bir Git dalıdır. Uzun ömürlü main ve develop dallarının aksine, feature dalları sınırlı bir süre — birkaç saatten birkaç haftaya kadar — var olur.

feature branch'in temel amacı, bir görevle ilgili değişiklikleri kodun geri kalanından izole etmektir. Geliştirici kendi dalında deneyler yapabilir, birden çok commit yapabilir ve hatta kodu bozabilir, diğer ekip üyelerinin çalışmasını etkilemeden.

Geliştirme tamamlandıktan sonra, feature dalı zorunlu kod incelemesiyle birlikte bir Pull Request aracılığıyla develop'a geri birleştirilir. Birleştirmeden sonra, depoyu temiz tutmak için dal genellikle silinir.

Vincent Driessen, 2010'a göre, feature dalları ile Git Flow modeli, farklı dal türleri arasındaki net sorumluluk ayrımı sayesinde endüstri standardı haline gelmiştir.

Feature Branch ile İş Akışı

İş akışı, geliştiricinin her yeni özellik için gerçekleştirdiği adımlar dizisinden oluşur. Bu süreç, birleştirme çakışmalarını en aza indirir ve kod kalite kontrolünü sağlar.

1. Dal oluşturma develop'ın son commit'inden. Geliştirici develop'a geçer, onu günceller ve yeni bir feature dalı oluşturur.
2. Geliştirme ve commit'ler feature dalında. Geliştirici değişiklikler yapar, net açıklamalarla commit'ler atar ve düzenli olarak dalı uzak depoya iletir.
3. Develop ile senkronizasyon — geliştirme sırasında ana dal ilerleyebilir. Geliştirici, kendi feature dalına develop'ın rebase veya merge'ini gerçekleştirir.
4. Pull Request oluşturma — özellik hazır olduğunda, geliştirici kod incelemesi için bir PR açar. Ekip kodu inceler ve yorum bırakır.
5. Birleştirme ve silme — PR onayından sonra, dal develop'a birleştirilir ve hem yerel hem de uzak olarak silinir.

Develop ile düzenli senkronizasyon kritik öneme sahiptir. Bir feature dalı, develop'dan değişiklikleri birleştirmeden ne kadar uzun yaşarsa, nihai birleştirmede çakışma olasılığı o kadar yüksek olur.

Feature Dalı Senkronizasyon Sıklığı

Feature Dalları Adlandırma Kuralları

Dal adlandırma, ekip disiplininin önemli bir parçasıdır. Tek tip bir adlandırma standardı, hangi görev üzerinde çalışıldığını ve kimin yaptığını hızlıca belirlemeye olanak tanır.

• feature/ad — klasik Git Flow'ta feature/ öneki kullanılır. Örnek: feature/added-auth-module.
• feature/JIRA-123-açıklama — izleme sistemindeki görev numarasına bağlantı. Örnek: feature/PROJ-42-add-login.
• feature/tip/ad — görev türünü belirten genişletilmiş biçim. Örnek: feature/feat/analytics-dashboard.

JIRA, Trello veya başka bir sistemden görev ID'si kullanmak en iyi uygulamadır. Kodu otomatik olarak göreve bağlar ve git log aracılığıyla dal aramasını basitleştirir.

Pull Request Süreci

Pull Request (veya GitLab'da Merge Request), feature dalını develop'a birleştirme isteğidir. PR yalnızca teknik bir işlem değil, kod kalitesini artıran ve ekip içinde bilgiyi yayan bir ekip kod inceleme sürecidir.

İyi bir PR, görevin kısa bir açıklamasını içeren bir başlık, bilet bağlantısı ve değişikliklerin açıklamasını içerir. Geliştirici, tam olarak ne yapıldığını, hangi dosyaların değiştirildiğini ve projenin diğer bölümleri için potansiyel riskler olup olmadığını belirtmelidir.

Ekip, PR'daki kodu inceler, yorum bırakır, değişiklik talep eder (change requests) ve birleştirmeyi onaylar (approve). Onaydan sonra, merge veya squash merge gerçekleştirilir.

Mobil geliştirmede ortalama PR inceleme süresi 4 ila 24 saat arasındadır. Danger kütüphanesi, doğrudan PR içinde linters ve testler çalıştırarak kontrollerin bir kısmını otomatikleştirir.

İyi Bir PR Oluşturma Önerileri

• Boyut — 300-400 satırdan fazla değişiklik olmamalıdır. Büyük PR'ları incelemek zordur, inceleme kalitesi düşer.
• Bir PR — bir görev — tek bir istekte ilgisiz değişiklikleri karıştırmaktan kaçının.
• Ekran görüntüleri — arayüz değişiklikleri için öncesi ve sonrası ekran görüntüleri ekleyin.
• Testler — yeni işlevsellik için birim testler yazın ve PR'a dahil edin.

Feature Dallarını Birleştirme Stratejileri

PR onayından sonra, feature dalı develop'a farklı şekillerde birleştirilebilir. Birleştirme stratejisi seçimi, commit geçmişini ve değişiklikleri geri alma yeteneğini etkiler.

• Merge commit — feature dalının tüm commit geçmişini koruyarak bir birleştirme commit'i oluşturur. Geçmiş tam kalır, ancak dallanma grafiği daha karmaşık hale gelir.
• Squash merge — feature dalının tüm commit'lerini tek bir commit'te birleştirir ve develop'ın üzerine ekler. Geçmiş daha temiz olur, ancak ara commit'ler hakkındaki bilgiler kaybolur.
• Rebase and merge — feature dalının commit'lerini develop'ın son commit'inin üzerine yeniden yazar ve ek bir commit olmadan birleştirir. Geçmiş doğrusal kalır.

Sık sürüm yapan mobil projeler için en çok squash merge kullanılır: develop'ta temiz bir geçmiş sağlar, geliştirme detayları ise PR açıklamasında ve izleyici görevinde kalır.

Feature Branch ile Çalışırken Tipik Hatalar

Deneyimli geliştiriciler bile feature dallarıyla çalışırken hatalar yapar. Tipik sorunları bilmek, zaman ve veri kaybını önlemeye yardımcı olur.

• Dalın çok uzun yaşaması — bir feature dalı, develop ile senkronizasyon olmadan 2-3 haftadan fazla yaşar ve büyük birleştirme çakışmalarına yol açar.
• Belirsiz açıklamalı commit'ler — “fix” veya “update” gibi mesajlar neyin değiştirildiğini ve nedenini açıklamaz.
• Görevlerin karıştırılması — aynı feature dalında iki ilgisiz özellik geliştirilir, bu da seçmeli geri almayı imkansız kılar.
• Senkronizasyon eksikliği — geliştirici git fetch yapmaz ve develop'ı güncellemez, bu da nihai birleştirmede çakışmalara neden olur.

Bu sorunları önlemenin en iyi yolu, proje başlangıcında çalışma kuralları üzerinde anlaşmak ve CI/CD hattında otomatik kontroller kullanmaktır.

Feature Branch ile Çalışmak İçin Komut Örnekleri

Pratik bir senaryo düşünelim: bir geliştirici, mobil uygulamada yeni bir kimlik doğrulama özelliği başlatır. Bir feature dalı oluşturur, kod üzerinde çalışır ve görevi bir Pull Request ile tamamlar.

# Develop'ı güncelle ve feature dalı oluştur
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Özellik üzerinde çalışma: commit'ler
git add src/ui/login/
git commit -m "Add login screen layout"

# Feature dalını sunucuya gönder
git push origin feature/add-login-screen

# Develop ile senkronize et (rebase)
git fetch origin develop
git rebase origin/develop

# PR onayından sonra: yerel develop'ı güncelle ve dalı sil
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

git branch -d komutu, dalı yalnızca değişiklikleri tamamen birleştirildikten sonra siler. Dal birleştirilmemişse, Git zorla silmek için git branch -D kullanmayı önerecektir — bu bayrağı dikkatli kullanın.

Feature Dalında Kontrollerin Otomasyonu

PR oluşturmadan önce her feature dalı için CI/CD hattı çalıştırılmalıdır. Bu, kod diğer geliştiricilerin incelemesine girmeden önce sorunların erken aşamada tespit edilmesini sağlar.

# Feature dalını kontrol etmek için GitHub Actions
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Hat, kodun derlendiğini, testlerin geçtiğini ve kod stilinin ekip standartlarını karşıladığını doğrular. Tüm kontrolleri geçtikten sonra bir Pull Request oluşturulabilir.