Git İş Akışları: Git Flow, GitHub Flow ve Trunk-Based

Git İş Akışları: Git Flow, GitHub Flow ve Trunk-Based Development

Git; branch’ler, commit’ler, merge işlemleri, tag’ler, remote’lar ve geçmişi yeniden yazma araçları sunar. Ancak bir ekibin bunları nasıl bir araya getireceğine karar vermez. Bu karar projenin iş akışına aittir.

Git iş akışı, bir çalışmanın fikirden production ortamına nasıl taşınacağını tanımlar. Şu sorulara yanıt verir: Geliştirici branch’i nereden oluşturur? Bu branch ne kadar süre açık kalabilir? Hangi testlerin geçmesi gerekir? Değişikliği kim inceler? Nasıl merge edilir? Sürümler nerede hazırlanır? Acil production düzeltmeleri nasıl yayınlanır? Hangi branch’ler korunur?

Doğru iş akışı en fazla branch’e veya en ünlü diyagrama sahip olan değildir. Ürünün teslimat sıklığını, sürüm yükümlülüklerini, ekip büyüklüğünü, test olgunluğunu, uyumluluk gereksinimlerini ve bakım sorumluluklarını destekleyen en basit modeldir.

Bu rehber; feature branch’ler, GitHub Flow, Git Flow, GitLab tarzı branch stratejileri, trunk-based development ve forking workflow dahil başlıca iş akışı ailelerini açıklar. Ayrıca merge yöntemlerinin, CI/CD’nin, feature flag’lerin, release branch’lerinin ve branch korumalarının gerçek sonucu nasıl etkilediğini gösterir.

Neler Öğreneceksiniz?

Bir Git iş akışının neyi kontrol ettiğini ve Git’in kendi başına neyi kontrol etmediğini.
Branch stratejisi ile tam bir teslimat iş akışı arasındaki farkı.
Centralized ve Feature Branch iş akışlarının nasıl çalıştığını.
GitHub Flow’un hafif, pull request tabanlı iş birliğini nasıl desteklediğini.
Git Flow’un geliştirme, sürüm ve hotfix süreçlerini nasıl düzenlediğini.
Git Flow’un sürekli teslim edilen web uygulamaları için neden otomatik olarak uygun olmadığını.
Trunk-based development’ın entegrasyonu nasıl sık tuttuğunu ve branch’leri nasıl kısa ömürlü hale getirdiğini.
Release branch’lerinin uzun süreli geliştirme branch’lerine dönüşmeden nasıl kullanılabileceğini.
Forking Workflow’un dış katkıcıları nasıl desteklediğini.
Merge commit, squash merge ve rebase işlemlerinin geçmişi nasıl değiştirdiğini.
Branch koruması, otomatik testler, kod incelemesi ve deployment kontrollerinin iş akışını nasıl uyguladığını.
Gerçek bir proje için iş akışının nasıl seçilip belgeleneceğini.

Git İş Akışı Nedir?

Git iş akışı; bir Git deposundaki değişiklikleri oluşturmak, incelemek, entegre etmek, yayınlamak ve bakımını yapmak için tekrarlanabilir bir anlaşmadır.

Şunları tanımlayabilir:

Varsa uzun ömürlü branch’leri.
Yeni çalışmanın nereden başlayacağını.
Feature ve bug-fix branch’lerinin nasıl adlandırılacağını.
Geliştiricilerin main branch’e doğrudan push edip edemeyeceğini.
Pull request veya merge request’in ne zaman zorunlu olduğunu.
Hangi otomatik kontrollerin geçmesi gerektiğini.
Onayların nasıl toplandığını.
Hangi merge yöntemine izin verildiğini.
Sürümlerin nerede oluşturulduğunu.
Version tag’lerinin nasıl uygulandığını.
Hotfix ve backport işlemlerinin nasıl yönetildiğini.
Tamamlanan branch’lerin ne zaman silineceğini.

Bu nedenle iş akışı bir branch diyagramından daha geniştir. Diyagram main, develop, feature ve release branch’lerini gösterebilir; ancak testlerin zorunlu olup olmadığını, incelemelerin asenkron yürütülüp yürütülmediğini, veritabanı migration’larının nasıl deploy edildiğini veya tamamlanmamış özelliklerin nasıl gizlendiğini söylemez.

Git İş Akışı ile GitHub Actions Workflow Arasındaki Fark

Workflow sözcüğü birbiriyle ilişkili ama farklı iki anlamda kullanılır.

Git iş akışı: Branch’leri, commit’leri, incelemeleri, entegrasyonu ve sürümleri düzenleyen insan ve teknik süreç.
GitHub Actions workflow: YAML dosyasında tanımlanan ve depo olayları tarafından tetiklenen otomatik süreç.

Git iş akışı; otomatik bir GitHub Actions, GitLab CI/CD, Jenkins veya başka bir pipeline gerektirebilir. Pipeline daha geniş geliştirme sürecinin bir bölümünü uygular, ancak branch stratejisinin tamamı değildir.

Evrensel Olarak En İyi İş Akışı Yoktur

Günde birkaç kez sürüm yayınlayan küçük bir web ekibinin ihtiyaçları, üç bakım sürümünü destekleyen masaüstü uygulamasından farklıdır. Açık kaynaklı bir kütüphane, özel şirket deposundan farklı izin gereksinimlerine sahiptir. Regülasyona tabi bir ürün, kişisel projede gereksiz olan resmî onaylara ihtiyaç duyabilir.

İş akışı şu soruları yansıtmalıdır:

Ürün ne sıklıkla yayınlanıyor?
Production sürekli değişiklik alabilir mi?
Birden fazla yayınlanmış sürüm aynı anda destekleniyor mu?
Test paketi ne kadar güvenilir ve hızlı?
Tamamlanmamış işlevler feature flag ile gizlenebilir mi?
Kaç geliştirici katkıda bulunuyor?
Katkıcıların yazma erişimine güveniliyor mu?
Organizasyon görev ayrılığı gerektiriyor mu?
Başarısız deployment hızlıca fix-forward ile düzeltilebilir mi?
Sürümlerin sertifikasyondan veya stabilizasyon döneminden geçmesi gerekiyor mu?

Karmaşıklık gerçek bir kısıtı çözmelidir. Her ek kalıcı branch, senkronizasyon, politika, otomasyon ve bakım işi oluşturur.

Çoğu İş Akışının Ortak Yapı Taşları

İş akışı adları farklı olsa da modern Git süreçlerinin çoğu aynı yapı taşlarını kullanır.

Kararlı Bir Varsayılan Branch

Varsayılan branch genellikle main olarak adlandırılır. Ekipler çoğu zaman bunun korumalı ve deploy edilebilir, yayınlanabilir veya en azından entegre edilip test edilmiş bilinen bir durumda olmasını bekler.

Kısa ve Odaklı Commit’ler

Commit’ler anlaşılır mantıksal değişiklikleri temsil etmelidir. Odaklı commit’ler inceleme, rollback, hata ayıklama, cherry-pick ve tarihsel analiz süreçlerini iyileştirir.

İzole Çalışma İçin Branch’ler

Branch ayrı bir geliştirme hattı sağlar. İş akışındaki önemli soru branch’in var olup olmadığı değil, ne kadar yaşadığı ve nereye merge edildiğidir.

Kod İncelemesi

Pull request ve merge request’ler değişiklikleri tartışmak, diff’leri incelemek, iyileştirme istemek ve onayı kaydetmek için bir alan sağlar.

Otomatik Doğrulama

Testler, linting, güvenlik analizi, type checking, build işlemleri, migration kontrolleri ve deployment preview’ları bozuk değişiklikleri entegre etme riskini azaltır.

Sürüm Tanımlama

Tag’ler, release kayıtları, build kimlikleri ve deployment meta verileri kaynak geçmişini teslim edilen artifact’lere bağlar.

Branch Koruması

Hosting platformu doğrudan push işlemlerini engelleyebilir, onay ve başarılı kontroller isteyebilir, force push’u kısıtlayabilir ve kimlerin merge yapabileceğini belirleyebilir.

İş Akışı 1: Centralized Workflow

Centralized Workflow, Git kullanırken geleneksel merkezi depo modelini taklit eder.

Tüm geliştiriciler ortak bir depoyu clone eder ve değişiklikleri tek bir ana branch’e entegre eder:

A---B---C---D  main

Geliştiriciler yerelde commit oluşturabilir, remote ile senkronize olabilir, ayrışmayı çözebilir ve ortak branch’e push edebilir.

Temel Süreç

Ortak depoyu clone edin.
Yerel main branch’ini güncelleyin.
Değişiklikleri yerelde yapıp commit edin.
Gerektiğinde yeni remote değişiklikleri entegre edin.
Ortak branch’e push edin.

Avantajlar

Çok az branch yönetimi yükü.
Tek geliştirici veya çok küçük ve güvenilir ekip için kolaylık.
Basit ve doğrusal zihinsel model.
Değişikliklerin nadiren çakıştığı depolarda kullanılabilir.

Riskler

Doğrudan push işlemleri incelemeyi atlayabilir.
Bozuk bir commit hemen herkesi etkileyebilir.
Eş zamanlı çalışma push conflict’leri ve hızlı entegrasyon baskısı oluşturur.
Tamamlanmamış değişiklikler için çok az izolasyon sunar.
Ek inceleme katmanı olmadan onayları denetlemek zordur.

Ne Zaman Uygundur?

Bu model kişisel depolar, küçük dokümantasyon projeleri, geçici prototipler veya güçlü otomatik doğrulamaya sahip çok küçük ekipler için çalışabilir.

Çoğu ekip yazılım projesinde feature branch veya trunk-based review iş akışı daha iyi kontrol sağlar.

İş Akışı 2: Feature Branch Workflow

Feature Branch Workflow; her mantıksal özellik, hata düzeltmesi, refactoring veya dokümantasyon değişikliği için ayrı branch oluşturur.

          C---D  feature/task-search
         /
A---B---E---F    main

Feature branch incelenir ve daha sonra main içine entegre edilir.

Temel Süreç

git switch main
git pull --ff-only
git switch -c feature/task-search

# Dosyaları düzenleyin
git add -p
git commit -m "Görev anahtar kelime eşlemesini ekle"

git push -u origin feature/task-search

Geliştirici pull request veya merge request açar. İnceleme ve başarılı kontrollerden sonra branch merge edilir ve silinir.

Avantajlar

Tamamlanmamış çalışma varsayılan branch’ten izole kalır.
Her branch inceleyenler için odaklı bir tartışma birimi sağlar.
Entegrasyondan önce otomatik kontroller çalıştırılabilir.
Birden fazla geliştirici bağımsız çalışabilir.
Varsayılan branch doğrudan push işlemlerini reddedebilir.

Riskler

Uzun ömürlü feature branch’ler ayrışma biriktirir.
Büyük pull request’leri incelemek zordur.
Geç entegrasyon conflict ve mimari uyumsuzlukları ortaya çıkarır.
Branch’ler resmî olmayan kalıcı ortamlara dönüşebilir.
Ekipler “branch var” durumunu “özellik güvenle ilerliyor” ile karıştırabilir.

En İyi Uygulama

Feature branch’leri küçük ve kısa ömürlü tutun. Branch üç aylık projenin tamamını değil, incelenebilir tek bir değişikliği temsil etmelidir.

İş Akışı 3: GitHub Flow

GitHub Flow, korumalı varsayılan branch ve pull request’ler etrafında şekillenen hafif bir branch iş akışıdır.

Yaygın sıralaması şöyledir:

Varsayılan branch’ten yeni branch oluşturun.
Odaklı commit’ler oluşturun.
Branch’i push edin.
Gerekirse draft olarak pull request açın.
Değişikliği tartışıp inceleyin.
Otomatik kontrolleri çalıştırın.
Onaydan sonra merge edin.
Merge edilmiş sonucu proje sürecine göre deploy edin.
Tamamlanan branch’i silin.

Bu model kalıcı bir develop branch gerektirmez.

             feature/a
            /         \
A---B---C---D-----------E---F  main

Pratik GitHub Flow Komutları

git switch main
git fetch origin
git merge --ff-only origin/main

git switch -c fix/invoice-rounding

# Değişikliği yapın
git add -p
git commit -m "Fatura vergi yuvarlamasını düzelt"

git push -u origin fix/invoice-rounding

Pull request merge edildikten sonra:

git switch main
git pull --ff-only
git branch -d fix/invoice-rounding

Neden Popülerdir?

Az sayıda kalıcı branch.
Değişiklik, inceleme ve otomatik kontroller arasında kolay bağlantı.
Sık deployment için uygunluk.
Küçük ve orta ekipler için yeterince basit olması.
Draft pull request’lerin erken geri bildirim sağlaması.

Neler Gerektirir?

GitHub Flow yapısal olarak basittir, ancak disiplin ve otomasyona dayanır:

Varsayılan branch yayınlanabilir veya hızlıca onarılabilir kalmalıdır.
Branch’ler uzun süre açık kalmamalıdır.
Pull request’ler doğru biçimde incelenebilecek kadar küçük olmalıdır.
CI hızlı ve güvenilir geri bildirim sağlamalıdır.
Tamamlanmamış özellikler feature flag gerektirebilir.
Deployment ve rollback süreçleri güvenilir olmalıdır.

Ne Zaman Uygundur?

GitHub Flow; web servisleri, API’ler, SaaS ürünleri, dokümantasyon ve tek bir ana entegrasyon branch’inden düzenli deploy edilebilen uygulamalar için uygundur.

GitHub Flow Yalnızca GitHub İçin Değildir

İş akışı kavramları GitLab, Bitbucket, Azure DevOps veya başka bir hosting hizmetinde uygulanabilir. Platforma özgü inceleme nesnesi pull request veya merge request olarak adlandırılabilir, ancak branch modeli benzerdir.

Bu ad, GitHub tarafından yaygınlaştırılan iş akışını ifade eder; version control sistemine gömülü bir Git komutu değildir.

İş Akışı 4: GitLab Tarzı Basit Branch Stratejisi

GitLab’in güncel branch rehberi, birçok ekibin basit bir strateji kullanabileceğini vurgular:

Bir feature branch oluşturun.
Merge request açın.
Değişikliği doğrulayıp inceleyin.
Doğrudan main branch’ine merge edin.

Bu yapı GitHub Flow’a benzer.

GitLab ayrıca tarihsel sürümleri destekleyen, farklı müşteri release hatlarına hizmet veren veya sertifikasyon ve deployment gereksinimleri bulunan ürünler için daha karmaşık stratejileri de belgeler.

Ortam Branch’i Varyasyonu

Bazı ekipler ortamlara karşılık gelen branch’ler oluşturur:

main
staging
production

Kod, bu branch’ler üzerinden merge edilerek terfi ettirilir.

Bu yaklaşım açık bir görsel yol sağlayabilir, ancak riskleri vardır:

Ortam branch’i gerçekten deploy edilmiş durumdan ayrışabilir.
Hotfix’ler yanlış yönde ilerleyebilir.
Merge commit’ler yazılım geliştirme yerine deployment mekaniğini anlatabilir.
Birden fazla branch birbirinden hafifçe farklı kodlar içerebilir.

Modern teslimat sistemleri çoğu zaman kaynak tek bir commit ile ilişkilendirilirken immutable build artifact’lerinin ortamlar arasında terfi ettirilmesini tercih eder. Ortam branch’lerini yalnızca operasyonel model gerçekten gerektiriyorsa kullanın.

Release Branch Varyasyonu

Bakımı yapılan bir üründe şu branch’ler bulunabilir:

main
release/3.0
release/2.5

Yeni geliştirme main üzerinde devam ederken onaylanan düzeltmeler desteklenen release branch’lerine backport edilir.

Bu yaklaşım, kullanıcıların kullandığı birden fazla yayınlanmış sürüm aynı anda desteklenmek zorundaysa uygundur.

İş Akışı 5: Git Flow

Git Flow, açıkça version’lanmış sürümler etrafında tasarlanmış yapılandırılmış bir branch modelidir.

Geleneksel olarak iki uzun ömürlü branch kullanır:

main veya tarihsel adıyla master: Production’a hazır release geçmişi.
develop: Bir sonraki sürüm için entegrasyon branch’i.

Ayrıca geçici destek branch’leri kullanır:

feature/*: develop üzerinden oluşturulan yeni çalışmalar.
release/*: develop üzerinden oluşturulan release stabilizasyonu.
hotfix/*: main üzerinden oluşturulan acil production düzeltmeleri.

                feature/a
               /         \
------develop--C-----------D------R------
     /                               \   \
main-A-----------------------------------M---H
                                      hotfix

Tam grafik değişebilir, ancak önemli fikir branch türlerinin tanımlı başlangıç ve merge hedeflerine sahip olmasıdır.

Git Flow Bir Git Özelliği Değil, Bir Kuraldır

Git, develop adlı branch’in özel olduğunu bilmez. Git Flow, sıradan branch, merge ve tag işlemleriyle uygulanan ekip kuralıdır.

git-flow adlı isteğe bağlı komut satırı eklentileri branch oluşturma ve tamamlama adımlarını otomatikleştirebilir, ancak model bunları gerektirmez. Ekipler wrapper komutlarına körü körüne güvenmek yerine alttaki Git işlemlerini anlamalıdır.

Git Flow Feature İş Akışı

Uzun ömürlü development branch’ini bir kez oluşturun:

git switch main
git switch -c develop
git push -u origin develop

develop üzerinden feature oluşturun:

git switch develop
git pull --ff-only
git switch -c feature/task-search

# Çalışın ve commit oluşturun
git add -p
git commit -m "Görev anahtar kelime eşlemesini ekle"

Feature’ı tamamlayın:

git switch develop
git merge --no-ff feature/task-search
git branch -d feature/task-search

Feature normalde doğrudan main içine merge edilmez.

Git Flow Release İş Akışı

develop, sürüm için planlanan özellikleri içerdiğinde:

git switch develop
git switch -c release/2.0.0

Release branch şu stabilizasyon görevlerine odaklanmalıdır:

Hata düzeltmeleri.
Version güncellemeleri.
Release note’ları.
Packaging ayarları.
Son uyumluluk testleri.

Büyük yeni özellikler normalde sonraki sürümü beklemelidir.

Hazır olduğunda:

git switch main
git merge --no-ff release/2.0.0
git tag -a v2.0.0 -m "2.0.0 sürümünü yayınla"

git switch develop
git merge --no-ff release/2.0.0

git branch -d release/2.0.0

Release düzeltmeleri daha sonraki sürümlerde kaybolmaması için develop branch’ine geri dönmelidir.

Git Flow Hotfix İş Akışı

Acil production düzeltmesi main üzerinden başlar:

git switch main
git switch -c hotfix/2.0.1

Düzeltmeyi uygulayıp test edin:

git add -p
git commit -m "Yinelenen ödeme callback’lerini reddet"

Production geçmişine merge edip tag ekleyin:

git switch main
git merge --no-ff hotfix/2.0.1
git tag -a v2.0.1 -m "2.0.1 sürümünü yayınla"

Ardından düzeltmeyi develop branch’ine veya proje politikası gerektiriyorsa aktif release branch’ine merge edin:

git switch develop
git merge --no-ff hotfix/2.0.1

git branch -d hotfix/2.0.1

Git Flow’un Avantajları

Production ile bir sonraki sürüm geliştirmesi arasında açık ayrım.
Özel release stabilizasyon branch’leri.
Production’dan başlayan net hotfix yolu.
Resmî version’lara ve planlı sürümlere sahip ürünler için kullanışlılık.
Farklı zamanlarda güncelleme yapan müşterilere dağıtılan yazılımları destekleyebilmesi.
Branch amaçları için ortak bir terminoloji sağlaması.

Git Flow’un Maliyetleri

Birden fazla branch’in senkronize tutulması gerekir.
Özellikler production’a ulaşmadan önce daha uzun süre bekleyebilir.
Uzun süre çalışan develop entegrasyonu release riskini gizleyebilir.
Hotfix ve release düzeltmeleri birden fazla hedefe merge edilmelidir.
Geçmiş grafiği karmaşıklaşabilir.
Production ana entegrasyon hattından doğrudan gelmediğinde continuous delivery zorlaşır.
Ekipler ürün artık gerektirmese bile diyagramı mekanik biçimde uygulayabilir.

Git Flow Ne Zaman Uygundur?

Git Flow şu özelliklere sahip projelere uygun olabilir:

Açıkça version’lanmış yazılımlar yayınlamak.
Planlı release trenlerine sahip olmak.
Stabilizasyon dönemine ihtiyaç duymak.
Müşterilerin kullandığı birden fazla sürümü desteklemek.
Kabul edilen her değişikliği hemen deploy edememek.
Özel hotfix ve release koordinasyonuna ihtiyaç duymak.

Örnekler arasında masaüstü uygulamaları, mağaza incelemesine bağlı mobil sürümler, kurulan kurumsal ürünler, firmware veya bakım release hatlarına sahip kütüphaneler bulunabilir.

Git Flow Genellikle Ne Zaman Fazla Ağırdır?

Modelin asıl yazarı daha sonra sürekli teslim edilen web uygulamalarının GitHub Flow gibi daha basit bir iş akışından yararlanabileceğini açıklamıştır. Git Flow evrensel standart olarak görülmemelidir.

Şu durumlarda gereksiz olabilir:

Ekip main üzerinden günde birçok kez deploy ediyorsa.
Yalnızca bir production sürümü aktifse.
Değişiklikler feature flag ile gizlenebiliyorsa.
Otomatik test ve deployment olgunsa.
Fix-forward normal operasyon stratejisiyse.
Kalıcı develop branch gerçek release kısıtı çözmeden yalnızca gecikme ekliyorsa.

İş Akışı 6: Trunk-Based Development

Trunk-based development, çalışmayı çoğu zaman main veya trunk adı verilen tek ana entegrasyon branch’i etrafında düzenler.

Geliştiriciler:

Çok küçük ve yüksek disiplinli ekiplerde doğrudan trunk’a commit edebilir.
Hızlıca trunk’a merge edilen çok kısa ömürlü feature branch’ler kullanabilir.

       a
      / \
A---B---C---D---E---F  main
          \ /
           b

Branch’ler kasıtlı olarak kısa ömürlüdür. Belirleyici özellik branch’in hiç olmaması değil, sık entegrasyondur.

Trunk-Based Development “Herkes Main’e Her Şeyi Push Eder” Değildir

Başarılı trunk-based iş akışı güçlü mühendislik kontrolleri gerektirir:

Hızlı otomatik testler.
Küçük değişiklikler.
Continuous integration.
Sık senkronizasyon.
Uzun gecikme oluşturmayan kod incelemesi.
Tamamlanmamış kullanıcı özellikleri için feature flag’ler.
Büyük yapısal değişiklikler için branch by abstraction.
Güvenilir deployment ve monitoring.
Trunk sağlıksız olduğunda hızlı onarım.

Bu uygulamalar olmadan doğrudan trunk’a çalışma olgun trunk-based development değildir; yalnızca kontrolsüz entegrasyondur.

Kısa Ömürlü Branch Varyasyonu

Yaygın, ölçeklenebilir iş akışı şöyledir:

git switch main
git pull --ff-only
git switch -c change/add-search-index

# Küçük bir artışı tamamlayın
git add -p
git commit -m "Görev arama indeksini ekle"

git push -u origin change/add-search-index

Pull request kontrolleri çalıştırır ve hızlı inceleme alır. Haftalar değil, saatler veya birkaç gün içinde merge edilir.

Sonraki büyük özellik artışı güncellenmiş trunk üzerinden yeni bir küçük değişiklik olarak başlar.

Trunk-Based Development’ta Feature Flag’ler

Feature flag kod entegrasyonunu özellik aktivasyonundan ayırır.

Örnek:

if (FeatureFlags::enabled('task_search_v2')) {
    return $newSearchService->search($query);
}

return $legacySearchService->search($query);

Tamamlanmamış uygulama main içine girebilir, ancak normal kullanıcılar için devre dışı kalır.

Flag’ler şunları destekleyebilir:

Kademeli teslimat.
Dahili test.
Yüzde tabanlı rollout.
Müşteriye özel aktivasyon.
Hızlı operasyonel devre dışı bırakma.

Flag’ler ayrıca bakım işi oluşturur. Rollout kararları tamamlandıktan sonra eski flag’ler kaldırılmalıdır.

Branch by Abstraction

Büyük mimari çalışma tek bir küçük commit’e sığmayabilir. Branch by abstraction, eski ve yeni uygulamaların kararlı bir interface arkasında birlikte bulunmasını sağlar.

Basitleştirilmiş süreç şöyledir:

Mevcut davranışın çevresine abstraction ekleyin.
Eski davranışı abstraction arkasına taşıyın.
Yeni uygulamayı kademeli olarak ekleyin.
Davranışı configuration veya feature flag ile seçin.
Çağıran kodları ve verileri güvenle migrate edin.
Uygun olduğunda eski uygulamayı ve geçici abstraction’ı kaldırın.

Bu yaklaşım uzun ömürlü yeniden yazım branch’i gerektirmeden sık entegrasyon sağlar.

Trunk-Based Development’ta Release

İki yaygın yaklaşım vardır:

Doğrudan Trunk’tan Release

Kabul edilen her trunk commit potansiyel release candidate olmalıdır. Deployment otomasyonu test edilmiş commit’i seçer veya sürekli deploy eder.

Tam Zamanında Release Branch Oluşturma

Release branch, release zamanına yakın oluşturulur:

git switch main
git switch -c release/3.2

Yeni geliştirme main üzerinde devam eder. Release branch yalnızca release açısından kritik düzeltmeleri kabul eder; bunlar çoğu zaman önce trunk üzerinde geliştirilip sonra backport edilir.

Bu, tüm feature çalışmalarının aylarca biriktiği uzun ömürlü release-development branch kullanmaktan farklıdır.

Trunk-Based Development’ın Avantajları

Entegrasyon sona yakın değil, sürekli gerçekleşir.
Ayrışma sınırlı olduğu için conflict’ler genellikle küçüktür.
Güncel geliştirme için tek ana doğruluk kaynağı vardır.
Continuous delivery ve hızlı geri bildirimi destekler.
Büyük entegrasyon olayları önlenir.
Ekipler uyumsuz değişiklikleri daha erken keşfeder.

Riskler ve Gereksinimler

Zayıf otomatik testler sık bozulmaya yol açabilir.
Yavaş incelemeler kısa ömürlü branch’leri uzun ömürlü hale getirir.
Büyük değişiklikler feature flag veya abstraction teknikleri gerektirir.
Geliştiriciler çalışmayı küçük artışlara bölmelidir.
Bozuk trunk hemen ele alınmalıdır.
Kötü flag yönetimi gizli karmaşıklık oluşturabilir.

İş Akışı 7: Forking Workflow

Forking Workflow, açık kaynak projelerinde ve katkıcıların doğrudan yazma erişimi almaması gereken depolarda yaygındır.

Her katkıcıda şunlar bulunur:

Yerel clone.
Kişisel sunucu tarafı fork.
Resmî depoya remote bağlantısı.

Yaygın remote kuralı şöyledir:

origin: Katkıcının fork’u.
upstream: Resmî depo.

İlk Kurulum

git clone git@github.com:contributor/project.git
cd project

git remote add upstream git@github.com:organization/project.git
git remote -v

Resmî Depodan Güncelleme

git fetch upstream
git switch main
git merge --ff-only upstream/main
git push origin main

Katkı Oluşturup Yayınlama

git switch -c fix/date-parser

# Değişiklikleri yapıp commit edin
git add -p
git commit -m "Geçersiz takvim tarihlerini reddet"

git push -u origin fix/date-parser

Katkıcı, fork branch’inden resmî depoya pull request açar.

Avantajlar

Dış katkıcıların resmî depoya yazma erişimine ihtiyacı yoktur.
Maintainer’lar entegrasyonu kontrol eder.
Katkıcılar kendi branch’lerini yayınlayıp test edebilir.
Açık topluluklara ölçeklenebilir.

Maliyetler

Katkıcıların iki remote yönetmesi gerekir.
Fork branch’leri güncelliğini kaybedebilir.
Güvenilmeyen fork build’lerinde CI secret ve izinleri kısıtlanabilir.
Maintainer’ların açık katkı ve inceleme politikalarına ihtiyacı vardır.

Merge Yöntemleri İş Akışının Bir Parçasıdır

Pull request birkaç farklı yöntemle entegre edilebilir. Seçilen yöntem depo geçmişini değiştirir.

Merge Commit

git switch main
git merge --no-ff feature/task-search

Özellikleri:

Feature branch’in tekil commit’lerini korur.
Açık bir entegrasyon commit’i oluşturur.
Branch topolojisini korur.
Branch sayısı yüksek olduğunda görsel olarak karmaşık geçmiş oluşturabilir.

Squash Merge

Hosting platformu veya yerel iş akışı feature diff’ini hedef branch üzerinde tek yeni commit halinde birleştirir.

A---B---S  main
     \
      C---D---E  feature

Özellikleri:

Her pull request için tek commit üretir.
Dağınık branch commit’lerinin main üzerinde korunmamasına izin verir.
Hedef geçmiş ile feature commit’leri arasındaki orijinal parent ilişkisini kaldırır.
Pull request düzeyinde geri almayı kolaylaştırabilir.
Feature branch’in ayrıntılı geçmişini ana hattan kaldırır.

Rebase and Merge

Feature commit’leri hedef branch üzerine yeniden uygulanır ve merge commit olmadan eklenir:

A---B---C'---D'---E'  main

Özellikleri:

Doğrusal geçmiş oluşturur.
Temiz olduklarında tekil mantıksal commit’leri korur.
Yerine geçen yeni commit kimlikleri oluşturur.
Orijinal branch geçmişi paylaşılmışsa dikkat gerektirir.
Açık merge commit oluşturmaz.

Merge Yöntemi Nasıl Seçilir?

Yöntem	En Uygun Olduğu Durum	Ana Ödünleşim
Merge commit	Branch topolojisi ve entegrasyon olayları önemliyse	Daha karmaşık grafik
Squash merge	İncelenen değişiklik tek bir mainline commit olmalıysa	Feature commit ayrıntıları ana geçmişten kaldırılır
Rebase and merge	Feature commit’leri temizse ve doğrusal geçmiş isteniyorsa	Commit’ler yeniden yazılır ve merge sınırı kalmaz

Ekip bir veya az sayıda izin verilen yöntem seçmeli ve her birinin ne zaman kullanılacağını belgelemelidir. Tutarsız merge davranışı geçmişi yorumlamayı zorlaştırır.

Pull Request Bir İş Birliği Katmanıdır, Git Nesnesi Değildir

Git; commit, branch, tag, merge ve remote kavramlarını anlar. Pull request veya merge request hosting platformu tarafından sağlanır.

Şunları ekler:

Tartışma.
Satır içi yorumlar.
İnceleme durumu.
Otomatik kontrol özetleri.
Bağlı issue’lar.
Onay kayıtları.
Merge kontrolleri.
Deployment preview’ları.

Son Git geçmişi seçilen entegrasyon yöntemine göre merge commit, squash commit veya rebase edilmiş commit’ler içerebilir.

Draft Pull Request ve Erken İnceleme

Draft pull request, çalışma merge edilmeye hazır olmadan önce görünür hale getirilebilir.

Şu durumlarda kullanışlıdır:

Geliştirici erken mimari geri bildirim istediğinde.
Değişiklik birkaç ekibi etkilediğinde.
Uygulama tamamlanmadan CI çalışmalıysa.
Özel çalışma yerine görünür tartışma tercih edildiğinde.
Branch kısa ömürlü kalmalı ama iş birliği gerektirdiğinde.

Draft, branch’i süresiz açık tutmak için bahane olmamalıdır. Büyük çalışmayı bağımsız olarak entegre edilebilen artışlara bölün.

Branch Koruması ve Kurallar

Yazılı iş akışı, depo ayarları kritik kuralları uyguladığında güvenilir hale gelir.

Yaygın korumalar şunlardır:

main branch’ine doğrudan push’u engellemek.
Pull request veya merge request zorunlu kılmak.
Bir veya daha fazla onay istemek.
Önemli yeni commit’lerden sonra onayları geçersiz kılmak.
Tartışmaların çözülmesini zorunlu kılmak.
Seçilen status check’lerin geçmesini istemek.
Branch’in hedefle güncel olmasını istemek.
Uygun olduğunda signed commit veya tag zorunlu kılmak.
Kimlerin merge veya release oluşturabileceğini kısıtlamak.
Branch silme veya force push işlemlerini engellemek.

Mevcut tüm kuralları otomatik olarak etkinleştirmeyin. Her zorunlu kontrol teslimat yolunun parçası olur ve güvenilir kalmalıdır.

İş Akışının Geri Bildirim Sistemi Olarak CI/CD

Hızlı doğrulama olmadan iş akışı çoğu zaman uzun bekleme süreleri ve büyük, riskli merge işlemleri üretir.

Pull request pipeline’ı şunları çalıştırabilir:

Dependency kurulumu.
Formatting ve lint kontrolleri.
Statik analiz.
Unit testler.
Integration testleri.
Güvenlik ve secret taraması.
Veritabanı migration doğrulaması.
Uygulama build’i.
Container build’i.
Preview ortamına deployment.

Merge sonrası pipeline şunları yapabilir:

Immutable artifact oluşturmak.
Staging ortamına deploy etmek.
Smoke testleri çalıştırmak.
Aynı artifact’i production’a terfi ettirmek.
Release kaydı oluşturmak.
Deploy edilen commit ve tag’i kaydetmek.

Main Branch’i Green Tutun

Green main branch, en son entegre edilmiş durumun gerekli doğrulamaları geçtiği anlamına gelir.

Red olduğunda:

Gerektiğinde ilgisiz değişiklikleri eklemeyi durdurun.
Sorumlu entegrasyonu hızlıca belirleyin.
Ekip politikasına göre revert veya fix-forward uygulayın.
Normal teslimata devam etmeden önce branch’i düzeltin.
Hatanın geçmesine izin veren eksik test veya doğrulamayı geliştirin.

Günlerce bozuk kalan main branch iş akışına olan güveni yok eder.

Release Branch’leri: Uzun Ömürlü ve Tam Zamanında

release/* adı birbirinden çok farklı iki stratejiyi tanımlayabilir.

Uzun Ömürlü Desteklenen Release Branch

main
release/3.x
release/2.x

Bu branch’ler birden fazla yayınlanmış sürüm desteklenmeye devam ettiği için vardır.

Geçici Stabilizasyon Branch’i

release/4.0.0

Bu branch yalnızca tek bir sürüm tamamlanırken vardır; daha sonra merge edilir veya emekliye ayrılır.

Trunk’tan Tam Zamanında Branch

Branch release zamanına yakın oluşturulur, yalnızca release açısından kritik değişiklikleri alır ve destek yükümlülükleri sona erdiğinde silinir.

İş akışı belgesi hangi anlamın geçerli olduğunu açıkça belirtmelidir.

Hotfix ve Backport

Hotfix aktif production’ı düzeltir. Backport ise düzeltmeyi desteklenen daha eski release hattına uygular.

Güvenli ilke, gerektiğinde düzeltmeyi ilgili en eski kod hattında geliştirmek ve sonra yeni hatlara taşımak veya proje politikası destekliyorsa trunk üzerinde geliştirip geriye cherry-pick etmektir.

Backport örneği:

# Düzeltme main üzerinde abc1234 olarak bulunuyor
git switch release/2.5
git cherry-pick -x abc1234

-x seçeneği, cherry-pick conflict olmadan tamamlandığında orijinal commit kimliğini yeni commit mesajına kaydeder ve backport izlenebilirliğine yardımcı olur.

Backport sonrasında:

Eski release için testleri çalıştırın.
Eski dependency ve şemalarla uyumluluğu doğrulayın.
Uygun patch release tag’ini oluşturun.
Düzeltmenin daha yeni bakım hatlarında da bulunduğunu doğrulayın.

Feature Flag ve Feature Branch Karşılaştırması

Feature branch kaynak geçmişini izole eder. Feature flag runtime davranışını kontrol eder.

Feature Branch	Feature Flag
Entegrasyon öncesi commit’leri ayırır	Deployment’ı aktivasyondan ayırır
Merge ayrışması biriktirebilir	Runtime karmaşıklığı biriktirebilir
İnceleme ve izolasyon için kullanışlıdır	Kademeli rollout ve gizli çalışma için kullanışlıdır
Merge sonrasında kaldırılır	Rollout kararlarından sonra kaldırılmalıdır

Olgun ekipler çoğu zaman ikisini birlikte kullanır: inceleme için kısa ömürlü branch ve entegrasyondan sonra tamamlanmamış özelliği devre dışı tutmak için flag.

Uygulamalı Çalışma: Hafif Pull Request İş Akışı

1. Main Branch’i Hazırlayın

git switch main
git fetch origin
git merge --ff-only origin/main
git status

2. Odaklı Bir Branch Oluşturun

git switch -c feature/task-search

3. Mantıksal Commit’ler Oluşturun

git add src/SearchService.php
git commit -m "Görev anahtar kelime eşlemesini ekle"

git add tests/SearchServiceTest.php
git commit -m "Görev anahtar kelime eşlemesini test et"

4. Branch’i İnceleyin

git log --oneline main..HEAD
git diff --stat main...HEAD
git diff main...HEAD

5. Yayınlayın

git push -u origin feature/task-search

6. Pull Request Kontrolleri

Otomatik testler geçer.
Diff tek bir mantıksal özellik içerir.
Secret veya üretilmiş dosya yoktur.
İnceleme yorumları çözülmüştür.
Politika gerektiriyorsa branch günceldir.

7. Merge Edin ve Temizleyin

git switch main
git pull --ff-only
git branch -d feature/task-search

Uygulamalı Çalışma: Git Flow Release

İlk Uzun Ömürlü Branch’ler

A---B---C  main
         \
          D---E---F  develop

Release Branch Oluşturun

git switch develop
git switch -c release/2.0.0

Stabilizasyon

git add CHANGELOG.md
git commit -m "2.0.0 release notlarını hazırla"

git add src/Version.php
git commit -m "Uygulama version’ını 2.0.0 olarak ayarla"

Main’e Merge Edip Tag Ekleyin

git switch main
git merge --no-ff release/2.0.0
git tag -a v2.0.0 -m "2.0.0 sürümünü yayınla"

Release Düzeltmelerini Develop’a Geri Taşıyın

git switch develop
git merge --no-ff release/2.0.0
git branch -d release/2.0.0

Doğrulayın

git log --oneline --graph --decorate --all
git show v2.0.0

Uygulamalı Çalışma: Flag Arkasında Trunk-Based Artış

1. Kısa Ömürlü Branch Oluşturun

git switch main
git pull --ff-only
git switch -c change/search-routing

2. Devre Dışı Flag Yolu Ekleyin

if (FeatureFlags::enabled('new_task_search')) {
    return $newSearch->execute($query);
}

return $oldSearch->execute($query);

3. Küçük ve Güvenli Artışı Commit Edin

git add -p
git commit -m "Görev aramasını feature flag üzerinden yönlendir"

4. Hızlıca Doğrulayıp Merge Edin

git diff main...HEAD
git push -u origin change/search-routing

İnceleme ve CI sonrasında branch’i merge edin. Yeni yol devre dışı kalır.

5. Yeni Küçük Branch’lerle Devam Edin

Yeni arama uygulamasını ekleyin.
Karşılaştırma metrikleri ekleyin.
Dahili kullanıcılar için etkinleştirin.
Kademeli rollout yapın.
Eski uygulamayı kaldırın.
Flag’i kaldırın.

Büyük özellik, uzun ömürlü tek branch yerine birkaç güvenli ve entegre artışla production’a ulaşır.

İş Akışı Karşılaştırması

İş Akışı	Uzun Ömürlü Branch’ler	Entegrasyon Sıklığı	Release Tarzı	Tipik Kullanım
Centralized	Genellikle bir tane	Doğrudan ve sık	Projeye özel	Tek geliştirici veya çok küçük güvenilir ekipler
Feature Branch	Genellikle main	Tamamlanan branch başına	Esnek	Genel ekip iş birliği
GitHub Flow	Main	Sık pull request’ler	Main’den sık deployment	Web, SaaS, API ve dokümantasyon
Git Flow	Main ve develop	Feature ve release aşamaları	Version’lanmış planlı sürümler	Resmî release döngülerine sahip ürünler
Trunk-Based	Main/trunk	Çok sık	Trunk’tan veya tam zamanında release branch’inden	Continuous integration ve delivery
Forking	Upstream projeye bağlı	Dış pull request’ler aracılığıyla	Maintainer kontrollü	Açık kaynak ve kısıtlı katkıcılar

İş Akışı Nasıl Seçilir?

Şu Durumlarda Hafif Main ve Feature Branch Modeli Seçin:

Ekip düzenli release yapıyorsa.
Tek bir güncel production sürümü varsa.
Pull request ve CI yeterli kontrol sağlıyorsa.
Kalıcı integration branch az değer katacaksa.

Şu Durumlarda Git Flow veya Release Odaklı Model Seçin:

Sürümler açıkça version’lanıp planlanıyorsa.
Resmî stabilizasyon branch’i gerekiyorsa.
Birden fazla sürüm bakım gerektirebiliyorsa.
Hotfix’lerin tanımlı bir release sürecini izlemesi gerekiyorsa.
Kabul edilen her değişiklikten sonra deployment yapılamıyorsa.

Şu Durumlarda Trunk-Based Development Seçin:

Otomatik doğrulama hızlı ve güvenilir olduğunda.
Ekip çalışmayı küçük artışlara bölebildiğinde.
Entegrasyon ve deployment sık olduğunda.
Feature flag ve branch-by-abstraction teknikleri kullanılabildiğinde.
Ekip bozuk trunk’a hemen müdahale ettiğinde.

Şu Durumlarda Forking Workflow Seçin:

Katkıcıların yazma erişimi almaması gerektiğinde.
Proje herkese açık olduğunda veya dış katkı kabul ettiğinde.
Maintainer’ların resmî depo entegrasyonunu kontrol etmesi gerektiğinde.
Hosting platformu fork’lar arasında pull request’i desteklediğinde.

Pratik Karar Matrisi

Proje Koşulu	Muhtemel Yön
Günde birkaç kez deploy	GitHub Flow veya trunk-based development
Tek küçük ekip, güçlü CI, kısa incelemeler	Main çevresinde kısa ömürlü branch’ler
Aylık paketlenmiş sürümler	Release branch’leri veya Git Flow
Birden fazla müşteri sürümünü destekleme	Bakımı yapılan release branch’leri
Büyük açık kaynak katkıcı tabanı	Forking workflow ve maintainer incelemesi
Zayıf veya yavaş otomatik testler	Entegrasyon hızını artırmadan önce doğrulamayı geliştirin
Özelliklerin geliştirilmesi aylar sürüyor	Artışlara bölme, feature flag ve branch by abstraction
Resmî onay ve denetim gereksinimleri	Zorunlu inceleme ve kontrollere sahip korumalı branch’ler

İş Akışı Anti-Pattern’leri

Uzun Ömürlü Feature Branch’ler

Entegrasyonu erteler ve büyük, riskli merge olayları oluşturur.

Release Gereksinimi Olmadan Kalıcı Develop Branch

Kabul edilen her değişiklik sonunda main üzerinden deploy edilecekse ek integration branch yalnızca senkronizasyon gecikmesi yaratabilir.

Deployment’larla Eşleşmeyen Ortam Branch’leri

Branch adı bir ortamda hangi kodun çalıştığının kanıtı değildir. Deploy edilen commit ve artifact’leri açık biçimde kaydedin.

Çok Büyük Pull Request’ler

Boyut ve karmaşıklık arttıkça inceleme kalitesi düşer.

Kişi Adlarıyla Branch Oluşturmak

adnan-work gibi adlar amacı değil sahipliği açıklar ve ilgisiz değişiklikleri biriktirebilir.

Paylaşılan Branch’leri Körü Körüne Rebase Etmek

Yayınlanmış commit’leri yeniden yazmak iş arkadaşlarını ve otomatik referansları bozar.

Cherry-Pick’i Varsayılan Entegrasyon Yöntemi Olarak Kullanmak

Cherry-pick tekil değişiklikleri kopyalar, ancak branch düzeyinde entegrasyon ilişkisi göstermez. Backport ve seçili commit’ler için bilinçli kullanın.

Main Branch’i Güvenilmez Kontrollerle Korumak

Flaky zorunlu test tüm geliştiricileri engelleyebilir ve ekibe otomasyona güvenmemeyi öğretebilir.

Ölü Branch’leri Sonsuza Kadar Tutmak

Eski branch’ler depo durumunu anlamayı zorlaştırır.

Bir Araçta Düğmesi Var Diye İş Akışı Seçmek

Süreci hosting platformunun özellik listesi değil, ürünün release ve bakım kısıtları belirlemelidir.

İş Akışı İçin En İyi Uygulamalar

Gerçek sorunu çözen en az sayıda kalıcı branch kullanın.
Mümkün olduğunda branch’leri kısa ömürlü tutun.
İlgisiz değişiklikleri ayırın.
Yalnızca tekil commit’leri değil, branch diff’ini inceleyin.
Hızlı ve ilgili otomatik kontroller zorunlu kılın.
Varsayılan branch’i sağlıklı tutun.
Tamamlanan geçici branch’leri silin.
Teslim edilen sürümleri tanımlamak için release tag’leri kullanın.
Hotfix ve backport yollarını belgeleyin.
İzin verilen merge yöntemlerini tanımlayın.
Entegre edilmiş ama tamamlanmamış işlevler için feature flag kullanın.
Eski feature flag’leri kaldırın.
Her ortama hangi commit ve artifact’in ulaştığını kaydedin.
Teslimat gereksinimleri değiştiğinde iş akışını yeniden değerlendirin.

İş Akışını Depo İçinde Belgeleyin

Pratik iş akışı belgesi şu soruları yanıtlamalıdır:

Varsayılan branch nedir?
Birisi doğrudan push edebilir mi?
Feature branch’ler nereden başlamalıdır?
Branch’ler nasıl adlandırılır?
Pull request’ler ne kadar küçük olmalıdır?
Hangi kontroller ve onaylar zorunludur?
Hangi merge yöntemlerine izin verilir?
Release tag’lerini kim oluşturabilir?
Sürümler nasıl oluşturulur?
Production hotfix’leri nasıl yönetilir?
Düzeltmeler nasıl backport edilir?
Branch’ler ne zaman silinmelidir?
Main branch bozulduğunda ne olur?

Politikayı görünür bir dosyada saklayın:

CONTRIBUTING.md
docs/development-workflow.md
docs/release-process.md

Belge yalnızca komutları listelemek yerine kararları açıklamalıdır.

Örnek Hafif Ekip Politikası

Varsayılan branch: main

Branch adları:
- feature/<kısa-açıklama>
- fix/<kısa-açıklama>
- docs/<kısa-açıklama>

Kurallar:
1. Main branch’e doğrudan push engellenir.
2. Her değişiklik pull request kullanır.
3. En az bir onay gerekir.
4. Unit testler, statik analiz ve build kontrolleri geçmelidir.
5. Pull request’ler tek bir mantıksal değişiklik içermelidir.
6. Normal feature branch’ler için squash merge kullanılır.
7. Release tag’leri annotated olur ve release pipeline tarafından oluşturulur.
8. Tamamlanan branch’ler otomatik olarak silinir.
9. Bozuk main branch hemen düzeltilir veya revert edilir.

Örnek Release Odaklı Ekip Politikası

Uzun ömürlü branch’ler:
- main: yayınlanmış production sürümleri
- develop: planlanan sonraki sürüm

Destek branch’leri:
- feature/* develop üzerinden
- release/* develop üzerinden
- hotfix/* main üzerinden

Kurallar:
1. Feature branch’ler develop içine merge edilir.
2. Release branch’ler yalnızca stabilizasyon değişikliklerini kabul eder.
3. Tamamlanan sürümler main ve develop içine merge edilir.
4. Main üzerindeki release commit’leri annotated version tag alır.
5. Hotfix’ler main ve develop içine merge edilir.
6. Desteklenen release branch’ler onaylı backport’ları alır.
7. Korumalı branch’lerde force push’a izin verilmez.

Git Flow’dan Daha Basit İş Akışına Geçiş

Artık resmî release branch’lerine ihtiyaç duymayan ekip aşamalı olarak sadeleşebilir.

develop branch’inin bugün neden var olduğunu belirleyin.
main branch’inin ana entegrasyon branch’i olabileceğini doğrulayın.
CI ve deployment otomasyonunu geliştirin.
Feature branch ömrünü kısaltın.
Release hazırlığını otomasyona veya tam zamanında branch’lere taşıyın.
Gerekli develop geçmişini main içine merge edin.
Branch korumalarını ve pipeline tetikleyicilerini güncelleyin.
Dokümantasyonu ve geliştirici araçlarını güncelleyin.
Aktif çalışma hesaba katıldıktan sonra develop branch’ini emekliye ayırın.

Benzersiz commit’leri, açık pull request’leri ve pipeline bağımlılıklarını belirlemeden uzun ömürlü branch’i silmeyin.

Trunk-Based Development’a Geçiş

Trunk-based development yalnızca branch adını değiştirmek değil, mühendislik yeteneğidir.

Gerçekçi geçiş şunları içerebilir:

Pull request boyutunu azaltın.
Test güvenilirliğini ve çalışma süresini iyileştirin.
Formatting ve statik kontrolleri otomatikleştirin.
Feature flag’leri tanıtın.
Branch by abstraction öğretin.
Beklenen en yüksek branch ömrünü belirleyin.
Hızlı inceleme sahipliği sağlayın.
Değişikliklerin entegrasyon öncesi ne kadar beklediğini ölçün.
Observability ile deployment rollback veya fix-forward prosedürlerini güçlendirin.
Gereksiz kalıcı branch’leri kaldırın.

İş Akışı Sorunlarını Gösteren Metrikler

Yararlı göstergeler:

Medyan branch ömrü.
Pull request bekleme süresi.
İnceleme dönüş süresi.
Pull request boyutu.
Merge conflict sıklığı.
CI süresi ve başarısızlık oranı.
Varsayılan branch’in bozuk kaldığı süre.
Deployment sıklığı.
İlk commit’ten production’a kadar geçen süre.
Değişiklik başarısızlık ve kurtarma oranları.
Eski branch’lerin sayısı ve yaşı.
Eski feature flag’lerin sayısı ve yaşı.

Metrikler iyileştirmeye yön vermelidir; geliştiricilerin manipüle ettiği hedeflere dönüşmemelidir.

Git İş Akışı Kontrol Listesi

İş akışı benimsenmeden önce:

Release sıklığı anlaşılmıştır.
Desteklenen version politikası belgelenmiştir.
Varsayılan branch’in beklenen durumu tanımlanmıştır.
Gerekli kalıcı branch’lerin gerçek amacı vardır.
İnceleme ve onay modeli açıktır.
CI pipeline zorunlu kontrolleri uygulayacak kadar güvenilirdir.
Merge yöntemi bilinçli seçilmiştir.
Hotfix ve backport süreci tanımlanmıştır.
Release tag’leri ve artifact provenance tanımlanmıştır.
Branch korumaları yazılı politikayla eşleşir.

Günlük çalışmada:

Doğru ve güncel base üzerinden başlayın.
Her mantıksal değişiklik için tek branch oluşturun.
Commit’leri anlaşılır tutun.
İş birliği veya yedekleme gerektiğinde düzenli push edin.
Riskli çalışma için incelemeyi erken açın.
Branch’i kısa ömürlü tutun.
CI ve inceleme geri bildirimlerine hızlı yanıt verin.
Entegrasyondan sonra branch’i silin.

Sık Sorulan Sorular

Git Flow Git’in İçinde Hazır mı Gelir?

Hayır. Sıradan Git komutlarıyla uygulanan bir branch kuralıdır. İsteğe bağlı eklentiler bazı bölümlerini otomatikleştirebilir.

GitHub Flow Yalnızca GitHub İçin mi?

Hayır. Kısa ömürlü branch ve inceleme modeli diğer hosting platformlarında da kullanılabilir.

Trunk-Based Development Branch Kullanmayı Yasaklar mı?

Hayır. Daha büyük ekipler inceleme ve otomatik doğrulama için yaygın olarak çok kısa ömürlü branch’ler kullanır.

Her Projede Develop Branch Olmalı mı?

Hayır. Yalnızca main branch’in karşılayamadığı gerçek bir entegrasyon veya release aşamasını temsil ediyorsa ekleyin.

Laravel veya Web Uygulamaları İçin En İyi İş Akışı Hangisidir?

Düzenli deploy edilen web uygulamasında, kısa ömürlü feature branch’lere, pull request’lere, CI’a ve feature flag’lere sahip korumalı main branch çoğu zaman tam Git Flow’dan daha basittir. Son seçimi yine projenin deployment ve destek kısıtları belirler.

GitHub Flow ile Trunk-Based Development Arasındaki Fark Nedir?

Benzer görünebilirler. İkisi de tek main branch ve kısa ömürlü branch’ler kullanabilir. Trunk-based development çok sık entegrasyonu, en kısa branch ömrünü ve feature flag gibi teknikleri vurgular. GitHub Flow ise pull request tabanlı iş birliği sırasını ve varsayılan branch’ten deployment’ı vurgular.

Git Flow Ne Zaman Kullanılmalı?

Resmî version’lanmış sürümler, stabilizasyon branch’leri, production hotfix yolları ve yayınlanmış sürümlerin desteği ek branch yapısını haklı çıkarıyorsa kullanın.

Main Her Zaman Deploy Edilebilir Olmalı mı?

Bu iş akışına bağlıdır; ancak GitHub Flow ve trunk-based modeller genellikle main yayınlanabilir olduğunda veya hızlıca geri yüklenebildiğinde en iyi şekilde çalışır.

Her Pull Request Squash Edilmeli mi?

Otomatik olarak değil. Pull request tek bir mantıksal mainline commit’e dönüşmeli olduğunda squash faydalıdır. Tekil commit’ler bağımsız ve değerli geçmiş taşıyorsa onları koruyun.

Geliştiriciler Pull Request Açmadan Önce Rebase Yapmalı mı?

Yalnızca ekip geçmiş politikası gerektiriyorsa ve branch güvenle yeniden yazılabiliyorsa. Paylaşılan çalışmayı gelişigüzel rebase etmeyin.

Release Branch’leri Trunk-Based Development ile Uyumsuz mu?

Hayır. Gerektiğinde trunk üzerinden tam zamanında release branch oluşturulabilir. Temel fark, feature geliştirmenin uzun ömürlü release branch’lerinde birikmek yerine trunk üzerinden devam etmesidir.

Feature Branch Ne Kadar Yaşamalı?

Mümkün olduğunca kısa. Hafif inceleme iş akışı birkaç günü tolere edebilirken trunk-based ekipler saatleri veya çok kısa süreleri hedefler. Haftalar süren branch, çalışmanın bölünmesi gerektiğine işarettir.

CI Kod İncelemesinin Yerini Alabilir mi?

Hayır. Otomasyon tanımlanmış özellikleri kontrol eder. İnsan incelemesi tasarımı, amacı, sürdürülebilirliği, ürün davranışını ve testlerde tam ifade edilmeyen riskleri değerlendirir.

Kod İncelemesi CI’ın Yerini Alabilir mi?

Hayır. İnsanlar tekrarlanabilir otomatik doğrulamanın iyi bir alternatifi değildir.

Acil Production Düzeltmesi Nasıl Yönetilmeli?

Düzeltmeyi production’ın doğruluk kaynağından oluşturun, doğrulayın, yayınlayın ve düzeltmenin daha yeni tüm aktif development veya release hatlarına ulaştığından emin olun.

Sonuç

Git iş akışı, değişikliklerin güvenilir yazılıma nasıl dönüştüğüne ilişkin bir anlaşmadır. Branch adları ve diyagramlar yalnızca görünür yapıdır. Gerçek iş akışı incelemeleri, otomatik testleri, merge yöntemlerini, branch korumasını, release tanımlamasını, deployment’ı ve bakımı da içerir.

Birçok modern ekip için küçük, kısa ömürlü branch’lere ve pull request’lere sahip korumalı main branch en iyi başlangıç noktasıdır. GitHub Flow bu modeli açık biçimde ifade eder. Trunk-based development sık entegrasyonu daha ileri taşır ve güçlü otomasyona, küçük artışlara, feature flag’lere ve hızlı incelemeye dayanır.

Git Flow; ürünün resmî version’lanmış sürümleri, stabilizasyon dönemleri, production hotfix’leri ve kullanımda birden fazla sürümü olduğunda yararlı olmaya devam eder. Ek branch’leri yalnızca model tanıdık olduğu için değil, gerçek kısıtları çözdüğü için kullanılmalıdır.

Forking Workflow farklı bir sorunu çözer: resmî depoya yazma erişimi vermeden katkı kabul etmek.

En önemli kural kazara oluşan karmaşıklıktan kaçınmaktır. Varsayılan branch’i koruyan ve incelemeyi destekleyen en basit iş akışıyla başlayın. Release branch’lerini, hotfix yollarını, onay katmanlarını veya bakımı yapılan sürümleri yalnızca ürün gerektiriyorsa ekleyin. Teslimat yetenekleri ve iş gereksinimleri değiştikçe süreci yeniden değerlendirin.

Bir sonraki makale; temiz commit’ler ve ekip iş birliği için Git en iyi uygulamalarına odaklanacak; branch adlandırma, commit tasarımı, inceleme kalitesi, güvenlik, depo bakımı ve güvenli geçmiş yönetimini bir araya getirecektir.

Resmî Kaynaklar ve Ek Okumalar