GitHub flow — branch-based geliştirme döngüsü

GitHub flow, GitHub’ın resmi olarak önerdiği hafif branching stratejisidir. 6 adımdan oluşur ve GH-900’ün en çok sorgulanan konularından biridir.

GitHub flow’un 6 adımı

1. Branch oluştur

Her yeni özellik veya düzeltme için main’den (veya varsayılan branch’ten) yeni bir branch aç. Branch adı açıklayıcı olmalı:

git switch -c feature/user-authentication
git switch -c fix/login-redirect-bug

Branch adları küçük harf, tire ile ayrılmış kelimeler kullanır (GitHub convention).

2. Değişiklik yap ve commit et

Branch’te geliştirme yap. Her commit küçük ve mantıksal bir birim içermeli:

git add src/auth/login.js
git commit -m "Add JWT token validation to login endpoint"

İyi commit mesajı: imperative (emir kipi), 50 karakter altında başlık, neden değiştirildiğini açıklar.

3. Pull Request aç

Değişiklikleri GitHub’a push et ve PR aç:

git push -u origin feature/user-authentication

GitHub’da “Compare & pull request” önerir. PR açarken:

• Başlık: neyin değiştiğini özetler
• Açıklama: neden değiştiğini açıklar, test talimatları verir
• Reviewers ekle
• Labels ve milestone atayabilirsin

4. Review ve discussion

Takım üyeleri kodu inceler. GitHub’da inline yorum yapabilir, değişiklik isteyebilirler (Request changes). Yazar yeni commit’ler ekleyerek geri bildirimi karşılar. PR süresince tüm değişiklikler otomatik olarak PR’a eklenir.

5. Deploy (opsiyonel)

Merge öncesi production’a (veya staging’e) deploy edilebilir. GitHub Actions ile PR branch’ini otomatik deploy etmek yaygın pratiktir. Bu adım bazı takımlarda atlanır.

6. Merge

Review tamamlanıp onay alındıktan sonra PR merge edilir. GitHub üç strateji sunar:

• Merge commit: tüm commit’ler korunur, merge commit eklenir
• Squash and merge: branch commit’leri tek commit’e sıkıştırılır
• Rebase and merge: doğrusal geçmiş, merge commit yok

Merge sonrası branch genellikle silinir.

GitHub flow vs. Git flow

Özellik	GitHub flow	Git flow
Branch sayısı	Az (main + feature)	Fazla (main, develop, release, hotfix)
Uygunluk	Web, continuous deployment	Sürüm tabanlı yazılımlar
Karmaşıklık	Düşük	Yüksek
Release yönetimi	Branch veya tag	Ayrı release branch

GH-900 GitHub flow’u sınava girer; Git flow hakkında ayrıntılı soru gelmez.

Sınavda dikkat edilecekler

• PR açmak merge etmek demek değildir — PR bir “teklif”tir
• Branch silmek merge edilen commit’leri silmez
• Review zorunlu olmayabilir (protected branch ayarına bağlı)
• “Draft PR” — review hazır olmadan PR açmak, takıma bilgi vermek için kullanılır
• PR merge olmadan da kapatılabilir (Close without merging)

Pratik senaryo

Bir özellik geliştiren geliştirici kodunu tamamladı ancak CI testleri henüz geçmedi. Ne yapmalı?

GitHub flow perspektifinden: PR’ı Draft olarak açabilir veya “WIP” etiketiyle açabilir; CI geçene kadar merge etmemeli. Review’u erken başlatmak verimliliği artırır ama merge beklemeli.

Sırada ne var?

Sonraki derste GitHub CLI ve web arayüzü arasındaki farkları inceleyeceğiz — sınav bu konuya da dokunur.