GitLab ve GitHub Üzerinde Merge/Pull Request Yönetimi

Bir kod değişikliğinin çalışması, production ortamına güvenle alınabileceği anlamına gelmez. Kod doğru olabilir fakat test kapsamı eksik kalabilir, bir database migration beklenmeyen kilit oluşturabilir veya küçük görünen bir authorization değişikliği ciddi erişim riskine dönüşebilir. Yaklaşık 10 yıldır yazılım geliştirme ve DevOps süreçleriyle çalışırken en fazla fark yaratan uygulamalardan birinin iyi tasarlanmış Pull Request ve Merge Request akışı olduğunu gördüm. GitLab ve GitHub Üzerinde Merge/Pull Request Yönetimi bu nedenle yalnızca kodu bir branch'ten diğerine taşıyan teknik bir işlem değildir. Doğru kurulduğunda review, test, güvenlik, sorumluluk ve deployment riskini tek değişiklik akışı içinde yönetmenizi sağlar.

Bu rehberde GitLab merge request ve GitHub pull request nasıl yönetilir, merge request pull request code review süreci nasıl oluşturulur ve GitLab ve GitHub branch protection approval ve merge kuralları karşılaştırması nasıl yapılır gibi pratik sorulara production bakış açısıyla cevap vereceğiz. Pull request yönetiminde code owner CI kontrolleri ve otomatik test süreçleri için hangi kontrollerin gerçekten zorunlu olması gerektiğini de ele alacağız. Küçük ekiplerden yoğun monorepo kullanan kurumlara kadar uygulanabilecek farklı governance seviyelerini inceleyeceğiz. Kurumsal GitLab GitHub merge request ve code review süreç danışmanlığı arayan ekiplerin hangi konuları değerlendirmesi gerektiğine de değineceğiz. GitLab GitHub ve DevOps danışmanlığı yakınımda şeklinde araştırma yapan ekipler için araç kurulumundan daha önemli olan süreç tasarımı kriterlerini açıklayacağız.

Pull Request ve Merge Request Nedir?

Pull Request ve Merge Request, geliştiricinin yaptığı değişiklikleri hedef branch'e doğrudan göndermek yerine kontrollü biçimde incelemeye açmasını sağlar. Bu süreç değişikliğin amacının açıklanmasını, diff'in incelenmesini, otomatik testlerin çalışmasını ve gerekli kişilerden onay alınmasını mümkün kılar. Böylece merge işlemi tek kişinin lokal kararından ekip tarafından görülebilen bir değişiklik yönetimi sürecine dönüşür. İyi kullanıldığında repository geçmişi yalnızca kodun ne zaman değiştiğini değil, değişikliğin neden yapıldığını ve kim tarafından incelendiğini de gösterir. Bu nedenle PR ve MR mekanizması teknik iş akışının yanında bilgi paylaşımı ve denetim aracı olarak da düşünülmelidir.

GitHub Pull Request (PR) Nedir?

GitHub Pull Request, bir branch üzerinde yapılan değişikliklerin başka bir branch'e alınmasını önermek için kullanılan inceleme alanıdır. Author değişikliğin amacını açıklar, reviewer'lar diff üzerinde yorum yapar ve CI kontrolleri sonuç üretir. Repository kuralları gerekli review, status check veya CODEOWNERS onayı tamamlanmadan merge işlemini engelleyebilir. Pull Request aynı zamanda issue, deployment ve commit geçmişiyle ilişkilendirilebilen bir değişiklik kaydıdır. Bu nedenle PR'ı yalnızca Merge düğmesine ulaşmak için geçilen bir ekran olarak görmek sürecin sağladığı değeri ciddi biçimde sınırlar.

GitLab Merge Request (MR) Nedir?

GitLab Merge Request, source branch'teki değişikliklerin target branch'e alınması için oluşturulan kontrollü değişiklik talebidir. Merge Request içinde reviewer, approval, pipeline, discussion ve deployment bilgileri aynı akışta izlenebilir. Approval rules kullanıldığında farklı ekiplerin veya alan uzmanlarının onayı merge öncesinde zorunlu hale getirilebilir. Protected branch ve Code Owner kuralları ile hassas dosya yollarında daha güçlü governance uygulanabilir. Kavram olarak GitHub Pull Request ile aynı temel amaca hizmet eder ve esas değer değişikliğin görünür, test edilebilir ve gözden geçirilebilir hale gelmesidir.

PR/MR Neden Kullanılır?

PR ve MR kullanmanın ilk nedeni hataları merge öncesinde yakalayabilmektir. İkinci önemli neden kod bilgisinin tek geliştiricide kalmasını engelleyerek ekip içinde paylaşılmasıdır. Üçüncü neden CI, security scan ve policy kontrollerini değişiklik sürecinin doğal parçasına dönüştürmektir. Ayrıca değişikliğin gerekçesi, issue bağlantısı, riskleri ve rollback planı tek yerde kayıt altında tutulabilir. Bu yapı özellikle incident sonrasında hangi değişikliğin hangi kararlarla production'a girdiğini anlamayı ciddi biçimde kolaylaştırır.

Doğrudan main Branch'e Push Etmekten Farkı

Doğrudan main branch'e push edildiğinde değişiklik çoğu zaman başka bir kişi görmeden repository'nin ana hattına ulaşır. PR veya MR kullanıldığında değişiklik merge edilmeden önce insan review'u ve otomatik kontroller uygulanabilir. Protected branch direct push işlemini teknik olarak engellediğinde süreç yalnızca ekip alışkanlığı olmaktan çıkar ve repository kuralına dönüşür. Bu sayede acelesi olan bir geliştiricinin istemeden quality gate'i atlaması önlenebilir. Production repository'lerinde direct push yetkisinin mümkün olduğunca sınırlı tutulmasını bu nedenle önemli buluyorum.

PR ve MR Arasında Kavramsal Fark Var mı?

Temel kavram açısından Pull Request ile Merge Request arasında büyük bir fark yoktur. Her ikisi de bir değişikliğin hedef branch'e alınmadan önce incelenmesini, doğrulanmasını ve gerekli koşulların tamamlanmasını amaçlar. Farklar daha çok platform terminolojisi, policy seçenekleri, CI entegrasyonu ve enterprise governance yeteneklerinde ortaya çıkar. Bir ekip GitHub'dan GitLab'a veya ters yönde geçtiğinde temel review kültürünü yeniden tasarlamak zorunda değildir. Ancak platformun sunduğu branch protection, approval ve queue özelliklerinin davranışları ayrı ayrı anlaşılmalıdır.

GitHub Pull Request ve GitLab Merge Request Karşılaştırması

GitHub ve GitLab aynı temel değişiklik yönetimi problemine farklı ürün yaklaşımlarıyla çözüm sunar. İki platformda da code review, approval, branch protection, CI entegrasyonu ve otomatik merge gibi mekanizmalar bulunur. Farklılık çoğu zaman bu özelliklerin nasıl yapılandırıldığı, hangi governance seviyesine bağlandığı ve repository ile organizasyon politikalarının nasıl uygulandığı noktasında ortaya çıkar. Bu nedenle GitLab ve GitHub branch protection approval ve merge kuralları karşılaştırması yapılırken yalnızca özelliklerin var olup olmadığına bakmak yeterli değildir. Ekiplerin gerçek workflow'u, self hosted ihtiyacı, repository sayısı ve merkezi governance beklentisi de değerlendirilmelidir.

Terminoloji

GitHub değişiklik talebi için Pull Request terimini kullanırken GitLab Merge Request terimini kullanır. Günlük ekip iletişiminde PR ve MR kısaltmaları bu nedenle sık görülür. İsim farkı süreçlerin temel mantığını değiştirmez. Her iki durumda da source branch değişiklikleri target branch'e alınmadan önce görünür hale gelir. Ekip dokümantasyonunda kullanılan platforma uygun tek terminoloji seçmek özellikle yeni geliştiricilerin süreci daha hızlı anlamasını sağlar.

Code Review

Her iki platform da satır bazlı yorum, genel review ve discussion mekanizmaları sunar. Reviewer değişikliğin doğruluğunu, bakım maliyetini ve risklerini değerlendirebilir. Review yalnızca syntax hatası bulmak için kullanılmamalıdır. Architecture, backward compatibility, security ve observability gibi başlıklar da değişikliğin türüne göre incelenmelidir. İyi review kültürü kullanılan platformdan çok ekipteki yorum standardına ve review sorumluluğunun nasıl paylaşıldığına bağlıdır.

Approval

Approval bir reviewer'ın değişikliği merge açısından kabul edilebilir bulduğunu gösterir. GitHub tarafında required approving reviews branch protection veya ruleset ile zorunlu tutulabilir. GitLab tarafında approval rules üzerinden gerekli approver sayısı ve belirli onay grupları tanımlanabilir. Approval sayısını artırmak otomatik olarak kaliteyi yükseltmez, çünkü yanlış seçilmiş reviewer'lar yalnızca süreci yavaşlatabilir. Risk seviyesine ve değişen kod alanına göre approval politikası oluşturmak daha sağlıklı sonuç verir.

CODEOWNERS

CODEOWNERS belirli dosya veya klasörlerin hangi kişi ya da ekiplerin sorumluluğunda olduğunu tanımlamak için kullanılır. GitHub'da branch protection veya ruleset ile Code Owner review'u gerekli hale getirilebilir. GitLab'da da protected branch ve Code Owners birlikte kullanılarak ilgili alan sahibinin onayı zorunlu tutulabilir. CODEOWNERS dosyası özellikle security, payment, authentication ve infrastructure gibi hassas dizinlerde güçlü bir kontrol sağlar. Dosyanın kendisinin de korunması gerekir, aksi durumda değişikliği yapan kişi ownership kuralını değiştirerek kontrolü etkisiz hale getirebilir.

CI/CD

Her iki platform da PR veya MR sürecini CI/CD sonuçlarıyla ilişkilendirebilir. Build, unit test, integration test, lint, type check ve security scan gibi kontroller merge quality gate olarak kullanılabilir. Pipeline'ın yalnızca çalışması değil, doğru commit veya merge sonucunu test etmesi önemlidir. Yoğun repository'lerde stale CI sonucu nedeniyle tek başına başarılı görünen değişikliklerin birlikte merge edildiğinde main branch'i bozması mümkündür. Bu nedenle queue veya train yaklaşımı yoğun ekiplerde giderek daha değerli hale gelir.

Protected Branch

Protected branch ana veya kritik branch'lere hangi yollarla değişiklik yapılabileceğini sınırlar. Direct push, force push, deletion veya review olmadan merge gibi davranışlar engellenebilir. GitHub branch protection ve rulesets bu amaçla kullanılabilirken GitLab protected branch yetkileri push ve merge izinlerini ayrı ayrı yönetebilir. Kritik branch'in korunması yalnızca yanlışlıkla yapılan değişiklikleri değil, süreç bypass edilmesini de azaltır. Ancak admin veya maintainer istisnalarının nasıl yönetileceği ayrıca açık bir policy haline getirilmelidir.

Auto-Merge

Auto merge gerekli review ve CI kontrolleri tamamlandıktan sonra değişikliğin otomatik olarak merge edilmesini sağlar. Bu yaklaşım geliştiricinin pipeline tamamlanmasını bekleyip tekrar Merge düğmesine dönmesi ihtiyacını azaltır. GitHub auto merge gerekli review ve status kontrolleri tamamlandığında PR'ı birleştirebilir. GitLab tarafında da gerekli koşullar tamamlandıktan sonra otomatik merge akışı kullanılabilir. Otomasyon faydalıdır ancak approval sonrası yeni commit geldiğinde eski doğrulamaların geçerliliğinin nasıl korunacağı ayrıca yapılandırılmalıdır.

Merge Queue / Merge Train

GitHub Merge Queue ve GitLab Merge Train yoğun target branch'lerde değişiklikların birlikte doğrulanmasına yardımcı olur. GitHub Merge Queue sıradaki PR'ları target branch'in son durumu ve kuyruktaki önceki değişikliklerle birlikte gerekli kontrollerden geçirebilir. GitLab Merge Train ise sıradaki MR'ları önündeki merge request'lerin birleşik sonuçlarıyla test ederek main branch'in bozulma riskini azaltır. Tek başına başarılı olan iki değişiklik birlikte başarısız olabileceği için bu özellik yalnızca hız değil güvenilirlik aracıdır. Özellikle günde çok sayıda merge alan repository'lerde queue veya train kullanımı ciddi fayda sağlar.

Self-Hosted Kullanım

Self hosted ihtiyaçlarda platform sürümü, özellik erişimi, runner altyapısı ve operasyon sorumluluğu birlikte değerlendirilmelidir. Kendi ortamında repository barındıran ekipler upgrade, backup, availability ve security süreçlerini de üstlenir. Bunun karşılığında network erişimi, veri yerleşimi ve entegrasyonlarda daha fazla kontrol elde edilebilir. Merge policy tasarlanırken yalnızca SaaS arayüzündeki bir özelliğe bağlı kalmak yerine kullanılan sürümün gerçekten desteklediği mekanizmalar doğrulanmalıdır. Özellikle enterprise governance kurallarının platform sürümüyle uyumu düzenli olarak gözden geçirilmelidir.

Enterprise Governance

Enterprise governance çok sayıda repository üzerinde ortak merge politikalarının uygulanmasını hedefler. Her repository'nin farklı minimum approval, security check ve bypass davranışına sahip olması denetimi zorlaştırabilir. Merkezi ruleset, group policy veya organization seviyesindeki kontroller bu farkları azaltmaya yardımcı olur. Bunun yanında audit trail, separation of duties ve signed commit gibi ek gereksinimler devreye girebilir. Governance amacı geliştiricileri yavaşlatmak değil, yüksek riskli değişikliklerde gerekli güvenlik kontrollerini otomatik ve tutarlı hale getirmektir.

PR/MR Yaşam Döngüsü Nasıl Çalışır?

Sağlıklı bir PR veya MR süreci kod yazıldığında başlamaz, değişikliğin hangi ihtiyacı karşılayacağı belirlendiğinde başlar. Issue veya task ile amaç tanımlanır, kısa ömürlü branch açılır ve değişiklik küçük commit'ler halinde geliştirilir. Draft aşaması erken feedback için kullanılabilir, ardından human review ve CI doğrulaması devreye girer. Approval tamamlandıktan sonra merge edilir ve deployment sonucu izlenir. Son adım olarak source branch temizlenir ve gerekiyorsa issue ile deployment arasındaki izlenebilirlik korunur.

Issue veya Task

İyi değişiklik akışının başlangıcında çözülmesi gereken problem açık olmalıdır. Issue acceptance criteria, beklenen davranış ve kapsam sınırlarını yazmak için kullanılabilir. PR veya MR bu issue ile bağlandığında reviewer kodu yalnızca diff olarak değil requirement bağlamında değerlendirebilir. Incident veya müşteri talebi gibi kaynaklar da issue üzerinde ilişkilendirilebilir. Böylece değişikliğin neden yapıldığı aylar sonra bile repository geçmişinden anlaşılabilir.

Branch Oluşturma

Değişiklik için ayrı branch oluşturmak geliştirme işini main hattından izole eder. Branch ismi issue veya feature amacıyla ilişkilendirildiğinde repository içinde aranabilirlik artar. Branch mümkün olduğunca tek bir değişiklik amacına hizmet etmelidir. Aynı branch üzerinde birbirinden bağımsız üç feature geliştirmek PR'ın bölünmesini zorlaştırır. Kısa ömürlü ve dar kapsamlı branch'ler merge conflict riskini de azaltır.

Commit

Commit değişikliğin anlamlı adımlarını repository geçmişine kaydeder. Lokal geliştirme sırasında küçük ve anlaşılır commit'ler author'ın düşünce akışını düzenlemesine yardımcı olur. Her dosya değişikliğini ayrı commit yapmak gerekmez, ancak tamamen farklı işleri tek commit içinde toplamak review'u zorlaştırabilir. Commit mesajı değişikliğin ne yaptığından çok niyetini açıklayabilirse daha değerlidir. Squash merge kullanılan ekiplerde bile düzgün commit yapısı geliştirme ve rebase sürecini kolaylaştırır.

Push

Branch remote repository'ye push edildiğinde CI süreçleri ve ekip görünürlüğü başlayabilir. Push öncesinde temel testlerin lokal olarak çalıştırılması gereksiz pipeline tüketimini azaltır. Secret, debug dosyası veya kişisel configuration yanlışlıkla commit edilmemelidir. Push işleminden hemen sonra pipeline sonucunu kontrol etmek author'ın sorumluluğunda olmalıdır. CI başarısızken reviewer çağırmak ekipte gereksiz bekleme ve context switch oluşturabilir.

Draft PR/MR

Draft PR veya MR değişiklik henüz merge edilmeye hazır değilken erken görünürlük sağlar. Architecture kararı, interface tasarımı veya yaklaşım konusunda feedback almak için oldukça kullanışlıdır. Reviewer değişikliğin bitmiş olduğunu düşünmediği için küçük detaylara erken takılmadan tasarım yönünü değerlendirebilir. Draft aynı zamanda CI ve preview environment süreçlerini geliştirme devam ederken çalıştırmak için kullanılabilir. Ready durumuna geçiş için ekip tarafından açık kriterler belirlenmesi faydalıdır.

Ready for Review

Ready for Review durumu author'ın değişikliğin gerçek code review için hazır olduğunu belirtir. Bu aşamada açıklama güncel, CI mümkün olduğunca green ve gereksiz debug kodları temizlenmiş olmalıdır. Author kendi diff'ini baştan sona okumadan reviewer atamamalıdır. Test yöntemi ve bilinen riskler description içinde görünmelidir. Bu standart reviewer zamanının author tarafından kolayca yakalanabilecek hatalara harcanmasını azaltır.

Code Review

Code review yalnızca kod stiline bakmak değildir. Reviewer requirement'ın karşılandığını, edge case'lerin düşünüldüğünü ve değişikliğin mevcut architecture ile uyumlu olduğunu kontrol eder. Security, backward compatibility ve observability değişikliğin türüne göre değerlendirilmelidir. Reviewer yorumları blocking requirement ile isteğe bağlı öneriyi birbirinden ayırmalıdır. İyi review süreci hem kusur yakalar hem de kod tabanı hakkında ekip bilgisini yayar.

CI/CD Validation

CI/CD validation insan review'unun tekrar tekrar yapmaması gereken mekanik kontrolleri otomatikleştirir. Unit test, integration test, lint, type check ve build buna örnektir. Security scan ve dependency kontrolleri de riskli değişiklikleri merge öncesinde yakalayabilir. Required check olarak işaretlenen kontroller başarısızken merge yapılamaması kaliteli bir koruma sağlar. Ancak flaky test'ler bu mekanizmayı güvenilir olmaktan çıkarabileceği için ayrıca yönetilmelidir.

Approval

Approval reviewer'ın mevcut diff'i kabul edilebilir bulduğunu gösterir. Approval sonrasında yeni commit gelirse eski review'un hâlâ geçerli olup olmadığı sorgulanmalıdır. Özellikle yüksek riskli repository'lerde stale approval otomatik sıfırlanabilir. Code Owner approval değişen dosya yollarına göre ayrıca gerekli tutulabilir. Approval sayısı kadar onayı veren kişinin gerçekten ilgili alanı anlayıp anlamadığı da önemlidir.

Merge

Merge değişikliği target branch'in history'sine dahil eder. Merge commit, squash veya rebase stratejisi repository policy tarafından belirlenebilir. Yoğun repository'lerde merge queue veya train final integration doğrulaması sağlayabilir. Merge düğmesine basılması işin bittiği anlamına gelmez. Production'a giden değişikliklerde deployment ve telemetry sonuçları da takip edilmelidir.

Deployment

Merge sonrası değişiklik staging veya production ortamına taşınabilir. Deployment başarısı yalnızca pipeline job'ının tamamlanmasıyla ölçülmemelidir. Error rate, latency, log ve business metric'ler yeni sürüm sonrasında gözlenmelidir. Feature flag kullanılıyorsa deployment ile release birbirinden ayrılabilir. Problem görülürse rollback, feature disable veya fix forward seçenekleri devreye girebilir.

Branch Cleanup

Merge edilen kısa ömürlü branch'lerin repository'de kalması zamanla gereksiz kalabalık oluşturur. Otomatik source branch deletion bu bakım işini azaltabilir. Release veya uzun ömürlü protected branch'ler doğal olarak bu politikanın dışında tutulur. Stale remote branch'ler için düzenli cleanup yapılabilir. Branch silinmesi commit geçmişini kaybettirmez, çünkü merge edilen değişiklik target branch history'sinde kalır.

Feature Branch Workflow

Feature branch workflow her bağımsız değişiklik için main branch'ten ayrı çalışma alanı oluşturur. Amaç geliştiricilerin değişiklikleri birbirinden izole edebilmesi ve PR veya MR üzerinden kontrollü olarak birleştirebilmesidir. Branch'lerin uzun süre açık kalması target branch ile farkı büyüttüğü için kısa yaşam döngüsü tercih edilmelidir. Branch isimlendirmesi iş türünü gösterebilir ancak çok ayrıntılı naming convention ek operasyon yükü oluşturabilir. Temel hedef branch'in hangi iş için oluşturulduğunun ekip tarafından kolay anlaşılmasıdır.

main

main branch çoğu projede üretime en yakın veya dağıtılabilir kod hattını temsil eder. Bu nedenle direct push ve force push gibi riskli işlemler sınırlandırılmalıdır. Required review ve required CI kontrolleri main için güçlü varsayılanlardır. Main sürekli bozuk durumda kalıyorsa ekip release ve entegrasyon hızını kaybeder. Merge queue veya train gibi mekanizmalar yoğun değişiklik akışında main'i sürekli green tutmaya yardımcı olabilir.

feature/*

feature branch yeni kullanıcı veya sistem yeteneği geliştirmek için kullanılabilir. Branch tek feature veya onun küçük bir parçasını temsil etmelidir. Çok geniş feature'lar feature flag ve stacked PR yaklaşımıyla daha küçük merge parçalarına ayrılabilir. Uzun süre main'den uzak kalan feature branch entegrasyon riskini artırır. Bu nedenle mümkün olduğunca erken ve güvenli biçimde ana hatta küçük parçalar taşımak daha sağlıklıdır.

fix/*

fix branch mevcut bir hatanın düzeltilmesi için kullanılabilir. PR description içinde hatanın nasıl yeniden üretildiği ve düzeltmenin nasıl test edildiği belirtilmelidir. Regression test eklemek aynı problemin tekrar ortaya çıkmasını engellemeye yardımcı olur. Bug fix ile ilgisiz refactor aynı PR içine eklenmemelidir. Bu ayrım reviewer'ın düzeltmenin gerçek etkisini daha kolay değerlendirmesini sağlar.

hotfix/*

hotfix branch production'daki acil bir problemi düzeltmek için kullanılabilir. Aciliyet normal kontrollerin tamamen kaldırılması anlamına gelmemelidir. En az bir uygun reviewer, temel CI ve mümkünse security kontrolleri korunmalıdır. Break glass kullanılırsa olay sonrasında tam review ve audit yapılmalıdır. Hotfix süreci önceden tanımlı olduğunda incident anında hangi kuralın uygulanacağı konusunda tartışma azalır.

Kısa Ömürlü Branch Kullanımı

Kısa ömürlü branch target branch ile farkın büyümesini engeller. Merge conflict ihtimali azalır ve review edilen değişiklik daha küçük kalır. Geliştirici düzenli olarak main ile senkronize olabilir. Feature flag kullanımı tamamlanmamış özelliklerin güvenli biçimde erken merge edilmesini kolaylaştırabilir. Bu yaklaşım trunk based development pratikleriyle de uyumludur.

Uzun Ömürlü Branch'lerin Riskleri

Uzun süre açık kalan branch'ler target branch'ten uzaklaşır. Bu durum rebase ve merge conflict maliyetini yükseltir. Reviewer yüzlerce değişikliği tek seferde anlamaya çalıştığı için review kalitesi düşebilir. CI branch üzerinde başarılı olsa bile güncel main ile integration problemi oluşabilir. Büyük işi küçük ve bağımsız adımlara bölmek bu riski önemli ölçüde azaltır.

GitHub Flow ve GitLab Flow

Branch workflow seçimi ekip yapısına, release modeline ve deployment sıklığına göre yapılmalıdır. Tek bir workflow her proje için ideal değildir. Sürekli deployment yapan küçük bir SaaS ekibi ile uzun release branch kullanan kurumsal ürün aynı modele ihtiyaç duymaz. GitHub Flow sade branch ve PR yaklaşımı sunarken GitLab Flow environment veya release ihtiyaçlarıyla farklı branch ilişkilerini destekleyen bir model olarak ele alınabilir. Trunk based development ve Git Flow gibi alternatiflerin maliyet ve avantajları da birlikte değerlendirilmelidir.

GitHub Flow Nasıl Çalışır?

GitHub Flow genellikle main'den kısa ömürlü branch açılması, değişiklik yapılması, Pull Request oluşturulması ve review sonrası merge edilmesi üzerine kuruludur. Main her zaman dağıtılabilir tutulmaya çalışılır. Uzun ömürlü develop branch zorunlu değildir. Bu sadelik sürekli delivery yapan ekiplerde önemli avantaj sağlar. Ancak branch protection ve gerekli CI kontrolleri olmadan yalnızca branch açmak güvenli süreç kurmak için yeterli değildir.

GitLab Flow Nasıl Çalışır?

GitLab Flow feature branch ve Merge Request yaklaşımını environment veya release branch ihtiyaçlarıyla birleştirebilir. Production branch veya release branch kullanılan yapılarda değişiklikların hangi sırayla ilerleyeceği açıkça tanımlanabilir. Bu model özellikle farklı sürümlerin aynı anda desteklendiği ürünlerde yararlı olabilir. Ancak çok fazla uzun ömürlü branch merge conflict ve cherry pick yükü oluşturabilir. Bu nedenle yalnızca gerçek release ihtiyacı olan branch'ler kalıcı tutulmalıdır.

Trunk-Based Development

Trunk based development geliştiricilerin küçük değişiklikleri sık aralıklarla ana hatta entegre etmesini hedefler. Branch'ler varsa bile çok kısa ömürlü tutulur. Feature flag tamamlanmamış fonksiyonların kullanıcıya açılmadan merge edilmesini kolaylaştırır. Bu model güçlü CI ve hızlı code review gerektirir. Uzun review kuyrukları oluşuyorsa trunk yaklaşımının entegrasyon avantajı büyük ölçüde kaybolur.

Git Flow

Git Flow develop, feature, release ve hotfix gibi farklı branch türleri kullanır. Planlı sürüm döngüsü olan projelerde release hazırlığını düzenlemeye yardımcı olabilir. Buna karşılık sürekli deployment yapan ekiplerde branch sayısı ve merge noktaları gereksiz operasyon yükü oluşturabilir. Her release branch arasında değişiklik taşımak conflict riskini artırır. Model sırf yaygın olduğu için değil, gerçekten release yaşam döngüsüne uyduğu için seçilmelidir.

Hangi Takım İçin Hangi Workflow?

Küçük ve sık deploy yapan ekiplerde GitHub Flow veya trunk based yaklaşım genellikle daha sade çalışır. Birden fazla desteklenen release hattı bulunan projelerde release branch modeli gerekebilir. Regüle ortamlarda branch sayısından çok approval ve separation of duties politikası önem taşır. Monorepo kullanan büyük ekiplerde hızlı review, CODEOWNERS ve merge queue daha kritik hale gelir. Workflow seçiminde amaç en çok branch'e sahip olmak değil, değişiklikların güvenli biçimde en az sürtünmeyle üretime ulaşmasını sağlamaktır.

İyi Bir Pull/Merge Request Nasıl Hazırlanır?

İyi hazırlanmış PR veya MR reviewer'ın değişikliğin nedenini hızlı anlamasını sağlar. Değişiklik tek amaca odaklanır, gereksiz dosyaları içermez ve mümkün olduğunca küçük tutulur. Description içinde problem, çözüm, test yöntemi ve riskler açıkça belirtilir. Database veya production davranışını etkileyen değişikliklerde rollback planı eklenmesi büyük fayda sağlar. Author'ın reviewer'a yalnızca kod değil karar verebilmesi için gerekli bağlamı sunduğunu düşünmesi gerekir.

Tek Bir Amaca Odaklanmak

PR tek bir problem veya feature amacına hizmet ettiğinde review daha kolay yapılır. Aynı değişiklik içinde bağımsız refactor, UI düzenlemesi ve dependency upgrade bulunması reviewer'ın context değiştirmesine neden olur. Scope dar olduğunda hata görülürse revert etmek de kolaylaşır. Release note ve changelog üretimi daha anlamlı hale gelir. Büyük feature'ların küçük, sıralı PR veya MR'lara bölünmesi bu prensibi korumaya yardımcı olur.

Küçük ve Review Edilebilir Tutmak

Küçük değişiklik reviewer'ın dikkatini daha uzun süre korumasına yardımcı olur. Binlerce satırlık diff içinde kritik bir authorization hatası kolayca gözden kaçabilir. PR boyutu yalnızca lines changed ile ölçülmemeli, kavramsal yük de dikkate alınmalıdır. Generated dosyalar veya lock file değişiklikleri gerçek review boyutundan ayrılabilir. Ekipler sert satır limitinden çok bölünebilirlik ve cognitive load kriterine odaklanmalıdır.

Açık Başlık Kullanmak

PR başlığı değişikliğin niyetini birkaç kelimede anlatmalıdır. "Fix", "Update" veya "Changes" gibi genel başlıklar repository geçmişinde anlam taşımaz. İyi başlık changelog ve release note otomasyonuna da girdi olabilir. Issue numarası gerektiğinde başlığa veya description'a eklenebilir. Squash merge kullanılan repository'lerde başlık final commit mesajına dönüşebileceği için kalite daha da önemlidir.

Değişikliğin Nedenini Açıklamak

Diff kodun nasıl değiştiğini gösterir fakat neden değiştiğini her zaman açıklamaz. Description problemi ve mevcut davranışın neden yeterli olmadığını belirtmelidir. Reviewer bu bağlam sayesinde gereksiz bir çözüm veya eksik requirement olup olmadığını değerlendirebilir. Architecture kararı varsa alternatiflerin neden tercih edilmediği kısa biçimde yazılabilir. Bu açıklama aylar sonra kod geçmişini inceleyen geliştiriciler için de değerli olur.

Issue Bağlamak

Issue bağlantısı requirement ile uygulama arasındaki ilişkiyi görünür hale getirir. Acceptance criteria reviewer'ın hangi davranışları doğrulaması gerektiğini gösterir. Closing keyword veya platform entegrasyonu issue'nun merge sonrasında otomatik kapanmasını sağlayabilir. Incident kaynaklı düzeltmelerde incident kaydı da ilişkilendirilebilir. Böylece issue, PR veya MR ve deployment arasında takip edilebilir bir değişiklik zinciri oluşur.

Test Yöntemini Belirtmek

Reviewer değişikliğin nasıl doğrulandığını tahmin etmek zorunda kalmamalıdır. Unit test, integration test, manuel senaryo veya preview environment kullanıldıysa description içinde belirtilmelidir. Yeni test eklenmediyse bunun nedeni açıklanmalıdır. UI değişikliklerinde tarayıcı veya cihaz davranışı gerekiyorsa kısa bilgi eklenebilir. Test planı author'ın değişikliği gerçekten çalıştırıp kontrol ettiğini de gösterir.

Riskleri Açıklamak

Her değişiklik aynı risk seviyesinde değildir. Authentication, payment veya database migration içeren PR daha güçlü review gerektirebilir. Author bildiği riskleri açıkça yazdığında reviewer doğru alanlara odaklanabilir. Deployment sırasında gözlenmesi gereken metric veya loglar da burada belirtilebilir. Risk belirtmek değişikliğin kötü olduğu anlamına gelmez, kontrollü biçimde yönetildiği anlamına gelir.

Rollback Planı Eklemek

Rollback planı özellikle production davranışını etkileyen değişikliklerde önceden düşünülmelidir. Basit uygulama değişikliği commit revert ile geri alınabilirken database migration aynı kolaylıkta geri çevrilemeyebilir. Feature flag varsa hızlı kill switch olarak kullanılabilir. Rollback planının gerçekten uygulanabilir olup olmadığı reviewer tarafından değerlendirilmelidir. Incident anında ilk kez rollback yöntemi düşünmek müdahale süresini gereksiz yere uzatır.

PR/MR Başlığı Nasıl Yazılmalı?

PR veya MR başlığı repository geçmişinin küçük fakat önemli bir parçasıdır. İyi başlık değişikliğin niyetini belirtir ve arama sonuçlarında tek başına anlamlı kalır. Conventional Commits benzeri standardizasyon otomatik changelog ve release süreçlerini kolaylaştırabilir. Issue ID eklenmesi requirement traceability için faydalı olabilir. Ancak başlık standardı geliştiricinin ne yaptığını anlatmasını zorlaştıracak kadar ağır hale getirilmemelidir.

Değişikliğin Niyetini Belirtmek

Başlık yapılmış teknik işlemi değil mümkün olduğunca değişiklik amacını anlatmalıdır. "Update user service" yerine "Kilitlenen kullanıcıların oturum açmasını engelle" gibi niyet belirten ifade daha anlaşılır olabilir. Reviewer PR listesinde değişikliği açmadan temel amacı görebilir. Release note üretildiğinde başlık doğrudan kullanıcı veya ekip için daha anlamlı olur. Niyet odaklı başlıklar repository geçmişini okumayı da kolaylaştırır.

Conventional Commits

Conventional Commits belirli prefix'lerle değişiklik türünü ifade eden mesaj standardıdır. feat, fix veya refactor gibi sınıflar otomatik release ve changelog süreçlerinde kullanılabilir. Standardın en büyük değeri insan tarafından da kolay okunabilir kalmasıdır. Her repository için aynı ayrıntı seviyesi gerekli değildir. Prefix seçimi değişikliğin gerçek amacını gizlemeye başladığında standardın kendisi hedef haline gelmemelidir.

feat

feat kullanıcıya veya sisteme yeni bir yetenek ekleyen değişikliklerde kullanılabilir. Yeni endpoint, yeni ekran veya yeni domain davranışı buna örnektir. Küçük internal refactor'ı feat olarak işaretlemek release note kalitesini düşürebilir. Başlık yine feature'ın ne yaptığını açık biçimde anlatmalıdır. Otomatik semantic release kullanılıyorsa bu sınıflandırmanın versiyonlama etkisi ekip tarafından bilinmelidir.

fix

fix mevcut hatalı davranışı düzelten değişiklikler için kullanılabilir. Başlık hatanın hangi davranışını düzelttiğini belirtmelidir. Regression testi eklenmesi mümkünse tercih edilmelidir. Incident bağlantısı description içinde tutulabilir. Otomatik changelog kullanan ekiplerde fix girişleri sürüm notlarının anlaşılır olmasına yardımcı olur.

refactor

refactor dış davranışı değiştirmeden kod yapısını iyileştiren değişiklikler için kullanılabilir. Feature değişikliğiyle büyük refactor'ı aynı PR içinde birleştirmemek review'u kolaylaştırır. Reviewer davranışın korunup korunmadığını testlerden doğrulamalıdır. Refactor büyükse performans veya compatibility etkisi yine oluşabilir. "Davranış değişmiyor" iddiası testlerle desteklendiğinde review daha güvenli olur.

docs

docs yalnızca dokümantasyon değişikliklerinde kullanılabilir. Documentation küçük görülmemelidir, çünkü yanlış operational doküman gerçek incident sırasında problem yaratabilir. API veya deployment prosedürü değiştiyse ilgili dokümantasyon aynı akışta güncellenmelidir. Docs PR'ları gerektiğinde domain owner tarafından incelenebilir. Generated documentation varsa kaynak dosya ile generated çıktı ayrımı açık tutulmalıdır.

test

test üretim kodunu değiştirmeden test kapsamını veya test altyapısını geliştiren değişikliklerde kullanılabilir. Flaky test düzeltmeleri de bu kategoriye girebilir. Test davranışı CI süresini etkileyebileceği için büyük değişikliklerde pipeline maliyeti değerlendirilmelidir. Yanlış test de yanlış güven üretebilir. Reviewer testin yalnızca geçtiğini değil gerçekten doğru davranışı doğruladığını kontrol etmelidir.

chore

chore bakım, tooling veya doğrudan kullanıcı davranışına yansımayan işler için kullanılabilir. Dependency metadata veya development tooling güncellemeleri örnek verilebilir. Her şeyi chore altında toplamak değişiklik geçmişini anlamsızlaştırabilir. Security etkili dependency update ayrı etiket veya review politikası gerektirebilir. Başlık yine değişikliğin amacını açık biçimde anlatmalıdır.

Issue Numarası Kullanımı

Issue numarasının başlıkta kullanılması değişikliği task sistemiyle ilişkilendirebilir. Ancak başlığın yalnızca "ABC 1234" gibi bir numaraya dönüşmesi repository geçmişini okumayı zorlaştırır. Issue ID ile kısa niyet açıklaması birlikte kullanılabilir. Platform otomatik link oluşturabiliyorsa description içinde bağlantı da yeterli olabilir. Takım standardı tek ve tutarlı olmalıdır.

Otomatik Changelog için Başlık Standardı

Squash merge sonrası PR başlığı final commit mesajı olarak kullanılıyorsa changelog kalitesi doğrudan başlığa bağlı hale gelir. Conventional prefix ve anlaşılır niyet cümlesi otomasyonu kolaylaştırır. Breaking change varsa açık biçimde işaretlenmelidir. Internal bakım değişiklikleri kullanıcı release note'undan filtrelenebilir. Standardın otomasyon kadar insan okunabilirliğini de koruması gerekir.

Etkili PR/MR Description Nasıl Yazılır?

Description reviewer için değişikliğin kullanım kılavuzu değildir, karar bağlamıdır. Problem, çözüm, değişiklik özeti ve test planı çoğu PR için yeterli temel oluşturur. Database, security veya deployment etkisi varsa ek bölümler kullanılmalıdır. Screenshot veya kısa video özellikle UI davranışını hızlı değerlendirmek için faydalıdır. İyi description gereksiz uzun olmak zorunda değildir, ancak reviewer'ın "Bu neden yapılıyor ve nasıl doğrulanmış?" sorularını cevaplamalıdır.

Problem

Problem bölümü mevcut durumda neyin yanlış veya eksik olduğunu açıklar. Kullanıcı etkisi veya teknik borç varsa kısa bağlam verilebilir. Belirsiz "iyileştirme yapıldı" ifadeleri review hedefini gizler. Issue zaten ayrıntılıysa kısa özet ve bağlantı yeterlidir. Reviewer çözümün gerçekten belirtilen probleme uygun olup olmadığını bu bölüm üzerinden değerlendirir.

Çözüm

Çözüm bölümü seçilen teknik yaklaşımın temelini anlatır. Her satırı açıklamak yerine önemli architecture veya data flow kararlarına odaklanmalıdır. Alternatif yaklaşım değerlendirilmişse neden kullanılmadığı kısaca belirtilebilir. Yeni dependency veya servis etkileşimi varsa görünür hale getirilmelidir. Böylece reviewer yalnızca implementasyona değil çözüm yönüne de feedback verebilir.

Değişiklik Özeti

Değişiklik özeti PR içinde hangi ana parçaların değiştiğini birkaç cümlede anlatır. Backend endpoint, UI bileşeni ve migration gibi farklı katmanlar varsa belirtilmelidir. Bu bölüm diff'i tekrar etmek yerine reviewer'a okuma sırası sağlayabilir. Generated dosyalar veya mechanical refactor ayrıca işaretlenebilir. Büyük PR'larda değişiklik özeti review süresini ciddi biçimde azaltabilir.

Test Planı

Test planı değişikliğin hangi senaryolarda doğrulandığını gösterir. Otomatik testler yanında manuel kontrol gereken alanlar açıklanabilir. Edge case veya failure scenario test edildiyse özellikle belirtilmesi yararlıdır. Reviewer gerektiğinde aynı adımları preview environment üzerinde çalıştırabilir. Test planı boşsa değişikliğin gerçekten doğrulanıp doğrulanmadığı önemli bir soru haline gelir.

Screenshot / Video

UI değişikliklerinde screenshot diff okumaktan daha hızlı bağlam sağlar. Before ve after görünümü görsel regresyonları fark etmeyi kolaylaştırabilir. Etkileşimli davranışlarda kısa video daha faydalı olabilir. Hassas kullanıcı bilgileri görsellerde yer almamalıdır. Görsel kanıt testin yerine geçmez ancak product ve design review süresini önemli ölçüde kısaltabilir.

Database Değişiklikleri

Database değişiklikleri schema, migration, index veya backfill davranışını açıklamalıdır. Büyük tabloda lock riski veya uzun transaction ihtimali reviewer tarafından bilinmelidir. Backward compatibility uygulama sürümlerinin birlikte çalışacağı deployment döneminde kritiktir. Migration rollback her zaman güvenli olmadığı için gerçek geri dönüş planı açıkça yazılmalıdır. Database domain reviewer yüksek riskli değişikliklerde gerekli tutulabilir.

Security Etkisi

Authentication, authorization, secret, IAM veya kullanıcı girdisi işleme değişiklikleri security açısından görünür olmalıdır. Author "security etkisi yok" diyorsa bile kritik path değişikliği CODEOWNERS üzerinden uzman review'una yönlendirilebilir. SAST sonucu insan security düşüncesinin yerine geçmez. Threat boundary değişiyorsa description içinde kısa biçimde belirtilmelidir. Bu alan security reviewer'ın doğru sorulara hızlı odaklanmasını sağlar.

Deployment Planı

Deployment planı değişikliğin production'a nasıl taşınacağını açıklar. Feature flag, staged rollout veya maintenance ihtiyacı varsa belirtilmelidir. Migration ile application deploy sırası önemli olabilir. Deployment sonrasında hangi metric veya logların gözleneceği de eklenebilir. Böylece merge onayı ile operasyon riski arasında doğrudan bağlantı kurulur.

Rollback Planı

Rollback planı sorun çıktığında güvenli geri dönüş yolunu tanımlar. Revert commit her değişiklik için yeterli değildir. Database migration, external contract veya irreversible data değişikliği daha farklı recovery yaklaşımı gerektirebilir. Feature flag hızlı risk azaltma yöntemi olabilir. Reviewer rollback'in teorik değil gerçekten uygulanabilir olduğundan emin olmalıdır.

PR/MR Template Kullanımı

Template her author'ın kritik bilgileri aynı formatta düşünmesini sağlar. Özellikle test, security etkisi ve rollback gibi alanların unutulmasını azaltır. Ancak çok uzun ve her PR için anlamsız onlarca soru içeren template geliştiricilerin kutuları düşünmeden işaretlemesine yol açabilir. Farklı değişiklik türleri için ayrı template kullanmak daha iyi sonuç verir. Template bir bürokrasi formu değil, güvenli değişiklik hazırlamak için kısa bir düşünme rehberi olmalıdır.

Neden Template Kullanılmalı?

Template ekip içindeki PR kalitesini daha tutarlı hale getirir. Yeni geliştirici hangi bilgilerin beklendiğini tahmin etmek zorunda kalmaz. Reviewer her PR'da problem, test ve risk bilgisini benzer yerde bulur. Regüle ortamlarda gerekli audit bilgilerinin unutulmasını azaltabilir. Template düzenli kullanılmayan alanlar görüldükçe sadeleştirilmelidir.

Bug Fix Template

Bug fix template yeniden üretme adımlarını ve beklenen davranışı öne çıkarabilir. Root cause kısa biçimde açıklanabilir. Regression test eklenip eklenmediği belirtilmelidir. Production incident bağlantısı varsa eklenebilir. Rollback genellikle kolay olsa da veri düzeltmesi yapan bug fix'lerde ayrıca düşünülmelidir.

Feature Template

Feature template problem, acceptance criteria ve kullanıcı etkisini görünür hale getirmelidir. Feature flag kullanılıp kullanılmadığı sorulabilir. UI değişikliklerinde screenshot alanı eklenebilir. Yeni dependency veya API contract varsa belirtilmelidir. Deployment ile release birbirinden ayrılıyorsa rollout planı açıkça yazılmalıdır.

Hotfix Template

Hotfix template acil değişikliğin neden normal akıştan hızlandırıldığını açıklamalıdır. Minimum review ve çalıştırılan kritik testler görünür olmalıdır. Break glass kullanıldıysa kim tarafından ve neden kullanıldığı kaydedilmelidir. Production metric'lerinin deployment sonrası nasıl izleneceği belirtilmelidir. Sonradan tam review veya follow up işi gerekiyorsa issue oluşturulmalıdır.

Security Change Template

Security template threat, etkilenen trust boundary ve access model değişikliklerini görünür hale getirebilir. Hassas vulnerability ayrıntıları herkesin erişebildiği PR description içine yazılmamalıdır. Security reviewer otomatik atanabilir. Secret veya credential değişikliği varsa rotation ihtiyacı düşünülmelidir. Security testleri ve deployment sonrası gözlem planı açık biçimde belirtilmelidir.

Database Migration Template

Migration template schema değişikliği, tablo boyutu ve lock riskini sormalıdır. Backfill varsa veri hacmi ve çalışma süresi tahmini eklenebilir. Application sürümleri arasında backward compatibility doğrulanmalıdır. Rollback veya roll forward stratejisi açık olmalıdır. Database owner approval yüksek riskli migration'larda zorunlu hale getirilebilir.

Infrastructure Change Template

Infrastructure template Terraform plan, Kubernetes diff veya IAM değişikliğinin özetini içerebilir. Network ve security etkisi ayrıca sorulmalıdır. Maliyet değişikliği tahmin edilebiliyorsa görünür hale getirilmelidir. Production kaynaklarını silen veya yeniden oluşturan işlemler özellikle işaretlenmelidir. Deployment ve rollback planı application değişikliğinden daha ayrıntılı olabilir.

PR/MR Self-Review Nedir?

Self review author'ın reviewer atamadan önce kendi değişikliğini bir reviewer gözüyle baştan sona incelemesidir. Bu alışkanlık debug kodu, yanlış dosya, eksik test ve kötü naming gibi kolay yakalanabilecek hataları azaltır. Diff'i web arayüzünden okumak IDE içinde çalışırken fark edilmeyen gereksiz değişiklikleri görünür hale getirebilir. Self review human review'un yerine geçmez. Ama reviewer zamanının daha değerli correctness, design ve security sorularına ayrılmasını sağlar.

Reviewer Atamadan Önce Diff'i Okumak

Author commit ettiği değişikliklerin tamamını diff görünümünde okumalıdır. Yanlış formatlama veya istemeden değişen config dosyaları bu aşamada kolayca fark edilir. IDE'de yalnızca aktif dosyaya bakarken repository genelindeki değişiklik gözden kaçabilir. Diff okurken reviewer'ın hangi satırda neden duraksayacağı düşünülmelidir. Açıklama gerektiren bölüm description veya kod comment'i ile daha anlaşılır hale getirilebilir.

Debug Kodlarını Temizlemek

Geçici log, console çıktısı ve development flag'leri production'a istemeden taşınabilir. Self review bu tür kalıntıları merge öncesinde yakalamak için iyi fırsattır. Debug log hassas veri içeriyorsa güvenlik riski de oluşturabilir. Otomatik lint bazı örnekleri yakalasa bile tüm debugging davranışlarını tanıyamaz. Author kendi değişikliğinin production koşullarında nasıl davranacağını düşünmelidir.

Gereksiz Dosyaları Çıkarmak

IDE ayarı, local environment dosyası veya unrelated formatting değişikliği PR'a yanlışlıkla eklenebilir. Bu dosyalar review diff'ini büyütür ve önemli değişikliklerin görünürlüğünü azaltır. Gereksiz generated output da mümkünse ayrı tutulmalıdır. Repository ignore kuralları tekrar eden sorunları önleyebilir. Her dosyanın PR amacıyla ilişkili olması iyi bir kalite kontrolüdür.

Testleri Çalıştırmak

Author yalnızca CI'ın test çalıştırmasını beklememelidir. Hızlı unit ve lint kontrolleri lokal ortamda çalıştırılabilir. CI kaynakları böylece açık hataları bulmak için gereksiz tüketilmez. Değişiklik belirli environment gerektiriyorsa uygulanabilir test yöntemi description'a yazılmalıdır. CI ile local sonuç farklıysa bunun nedeni incelenmelidir.

Naming ve Formatting Kontrolü

Naming kodun uzun dönem okunabilirliğini doğrudan etkiler. Yanlış veya aşırı genel isimler reviewer'ın iş mantığını anlamasını zorlaştırır. Formatting mümkün olduğunca otomatik araçlara bırakılmalıdır. İnsan review zamanı boşluk ve satır hizası tartışmak için harcanmamalıdır. Self review sırasında ekip convention'larıyla açıkça çelişen isimler düzeltilmelidir.

Description'ı Güncellemek

PR geliştirme sırasında değiştiyse ilk yazılan description güncelliğini kaybedebilir. Self review sonunda problem, çözüm ve test bilgisi gerçek diff ile karşılaştırılmalıdır. Kaldırılan yaklaşım description içinde bırakılmamalıdır. Reviewer eski bilgi üzerinden yanlış varsayım yapabilir. Güncel description review sürecinde gereksiz soru trafiğini azaltır.

Riskli Değişiklikleri Annotate Etmek

Author yüksek dikkat gerektiren satırları veya dosyaları reviewer'a açıkça işaret edebilir. Özellikle concurrency, cache invalidation veya migration gibi alanlarda kısa açıklama faydalıdır. Bu yaklaşım reviewer'ı yönlendirmek değil risk bağlamını paylaşmaktır. GitHub veya GitLab discussion mekanizmaları author notları için kullanılabilir. Riskli bölümün neden gerekli olduğu açıklanırsa daha kaliteli review yapılır.

PR/MR Ne Kadar Büyük Olmalı?

PR boyutu için her ekipte geçerli tek bir satır sayısı yoktur. Yüz satırlık karmaşık authorization değişikliği bin satırlık generated dosyadan daha fazla review yükü taşıyabilir. Bu nedenle lines changed yalnızca yardımcı bir sinyal olarak düşünülmelidir. Kavramsal scope, dosya sayısı ve birbirinden farklı karar noktaları daha anlamlı olabilir. Reviewer'ın değişikliği tek oturumda anlayıp güvenilir karar verebilmesi pratik bir hedef olarak kullanılabilir.

Küçük Değişikliklerin Avantajları

Küçük PR daha hızlı review edilir ve conflict ihtimali daha düşüktür. Hata çıktığında revert alanı sınırlı olur. Reviewer attention daha uzun süre korunur. Deployment etkisi daha kolay gözlemlenir. Ekipte review SLA'nın sürdürülebilir kalmasına da yardımcı olur.

Lines Changed Tek Başına Yeterli Bir Ölçü mü?

Hayır, lines changed değişikliğin zihinsel yükünü doğrudan ölçmez. Mechanical rename binlerce satır değiştirebilir ancak review nispeten kolay olabilir. Buna karşılık küçük authorization diff'i ciddi business risk taşıyabilir. Generated code ve lock file'lar toplamdan ayrı gösterilebilir. Risk, scope ve cognitive complexity birlikte değerlendirilmelidir.

Cognitive Complexity

Cognitive complexity reviewer'ın değişikliği anlamak için kaç farklı kavramı aynı anda takip etmesi gerektiğini ifade eder. Bir PR aynı anda database, authentication ve UI davranışını değiştiriyorsa satır sayısı düşük olsa bile ağır olabilir. Bu durumda değişiklik katmanlara ayrılabilir. Reviewer uzmanlık alanları da daha doğru atanır. Küçük kavramsal parçalar bilgi paylaşımını ve rollback yönetimini kolaylaştırır.

Generated Code'u Boyuttan Ayırmak

Generated code veya lock file değişiklikleri diff'i yapay biçimde büyütebilir. Reviewer'ın bu bölümleri elle satır satır incelemesi her zaman gerekli değildir. Source değişiklik ve generated çıktı açıkça ayrılmalıdır. CI generated dosyanın source ile tutarlı olduğunu doğrulayabilir. Böylece gerçek review enerjisi insan kararına ihtiyaç duyan kodda kalır.

Büyük PR/MR Nasıl Bölünür?

Önce davranış değiştirmeyen refactor ayrı PR olarak gönderilebilir. Database migration application kullanımından önce bağımsız biçimde deploy edilebilir. Backend contract ve frontend kullanımı gerektiğinde ayrı aşamalara bölünebilir. Feature flag incomplete feature'ın main'e güvenle taşınmasını sağlar. Her parça tek başına güvenli ve mümkün olduğunca backward compatible olmalıdır.

Büyük Feature'ları Küçük PR/MR'lara Bölmek

Büyük feature'ı tek PR içinde göndermek başlangıçta kolay görünür fakat review ve integration maliyeti hızla artar. Daha iyi yaklaşım feature'ı güvenli ara adımlara bölmektir. Ön hazırlık refactor'ı, migration, backend API ve frontend kullanım ayrı değişiklikler olabilir. Feature flag kullanıcıya açılmamış kodun main üzerinde bulunmasına izin verebilir. Bu şekilde ekip feature tamamlanana kadar haftalarca büyük bir branch taşımak zorunda kalmaz.

Refactor'ı Feature'dan Ayırmak

Refactor ve yeni davranış aynı diff içinde olduğunda reviewer hangi satırın davranış değiştirdiğini ayırt etmekte zorlanır. Refactor önce merge edilirse sonraki feature diff'i daha küçük kalır. İlk PR'ın davranışı değiştirmediği testlerle doğrulanmalıdır. Gereksiz refactor sırf feature öncesi yapılıyor diye genişletilmemelidir. Bu ayrım revert ve blame geçmişini de daha anlaşılır hale getirir.

Database Migration'ı Önce Göndermek

Backward compatible migration application kodundan önce deploy edilebilir. Örneğin yeni nullable column eklenip daha sonra uygulama tarafından kullanılabilir. Bu yaklaşım deployment sırasında uygulama ile schema arasında sert bağımlılığı azaltır. Destructive değişiklikler en sona bırakılmalıdır. Expand ve contract yaklaşımı bu tür güvenli aşamalandırmada sık kullanılır.

Backend ve Frontend'i Ayırmak

Backend önce backward compatible contract sunabilir. Frontend sonraki PR'da yeni davranışı kullanmaya başlayabilir. Bu ayrım farklı domain reviewer'ların daha odaklı review yapmasını sağlar. API contract değişikliği açık biçimde version veya compatibility planı içermelidir. Tek deployment zorunluluğu varsa feature flag veya capability detection kullanılabilir.

Feature Flag Kullanmak

Feature flag tamamlanmamış feature kodunun kullanıcıya görünmeden main'e merge edilmesini sağlar. Küçük PR'lar üretim hattında erken entegrasyon kazanır. Dark launch ile yeni backend davranışı gerçek trafik altında sınırlı biçimde gözlenebilir. Flag kill switch olarak da kullanılabilir. Feature tamamlandıktan sonra kullanılmayan flag mutlaka temizlenmelidir.

Follow-Up PR/MR

Her iyileştirmeyi aynı PR'a eklemek yerine gerekli olmayan işleri follow up olarak ayırmak faydalıdır. Reviewer "iyi olur" önerisini blocking requirement'tan ayırabilir. Follow up işin unutulmaması için issue ile takip edilebilir. Böylece mevcut değişiklik gereksiz büyümez. Ancak güvenlik veya correctness problemi yalnızca scope küçük kalsın diye ertelenmemelidir.

Stacked Pull Request / Merge Request Nedir?

Stacked değişiklik yaklaşımı birbirine bağımlı küçük branch'lerin zincir halinde review edilmesini sağlar. Büyük feature tek dev diff yerine mantıksal katmanlara ayrılır. Her branch bir önceki branch'i base alabilir ve reviewer değişiklikleri alttan yukarı inceleyebilir. Stack yönetimi rebase ve merge sırasında ek disiplin gerektirir. Doğru kullanıldığında büyük feature'ların haftalarca review bekleyen tek PR'a dönüşmesini engeller.

Birbirine Bağımlı Küçük Değişiklikler

Bazı feature parçaları tamamen bağımsız merge edilemez. İlk PR ortak interface eklerken ikinci PR bunun implementation'ını kullanabilir. Stack bu bağımlılığı açık biçimde ifade eder. Her PR yalnızca kendi incremental diff'ini gösterdiği için review daha kolay yapılır. Dependency zinciri description içinde görünür tutulmalıdır.

Base Branch Zinciri

Stack'te ilk branch main'i, sonraki branch ise önceki feature branch'ini base alabilir. Böylece her PR yalnızca kendi değişiklik farkını gösterir. Alt branch merge olduğunda üst branch'in base bilgisi güncellenir veya rebase edilir. Zincir çok uzun olursa yönetim zorlaşabilir. Bu nedenle stack yine makul sayıda parçadan oluşmalıdır.

Bottom-Up Review

Reviewer önce en alttaki temel değişikliği inceler. Alt katman onaylandıktan sonra onun üzerine kurulan değişiklik daha anlaşılır hale gelir. Üst PR'da alttaki diff tekrar review edilmemelidir. Review sırası dependency sırasıyla aynı tutulmalıdır. Bu yaklaşım architecture değişikliklerinde özellikle faydalıdır.

Stack Rebase

Main ilerledikçe stack'in alt branch'i yeni target üzerine rebase edilebilir. Üst branch'ler de zincirin devamı olarak yeniden hizalanmalıdır. Manuel rebase uzun stack'lerde conflict riskini artırabilir. Tooling veya script kullanımı operasyonu kolaylaştırabilir. Rebase sonrası CI ve gerekli approval davranışı repository policy'ye göre yeniden değerlendirilmelidir.

Stack Merge

Stack merge genellikle alttan yukarı yapılır. Alt PR merge edildiğinde üst branch doğrudan main'i hedefleyecek şekilde güncellenebilir. Queue desteği varsa stack sırası korunarak entegrasyon yapılabilir. Her parça kendi required check'lerini tamamlamalıdır. Stack'in ortasındaki değişiklik başarısızsa üst parçalar merge edilmemelidir.

Büyük Feature'larda Avantajı

Stack büyük feature'ın review süresini paralel ve aşamalı hale getirir. İlk parçalar feature tamamlanmadan main'e alınabilir. Conflict ve stale branch riski azalır. Reviewer küçük diff üzerinde daha güvenilir karar verir. Bunun karşılığında branch zinciri ve rebase operasyonu için ekipte ortak yöntem bulunması gerekir.

Draft PR/MR Ne Zaman Kullanılmalı?

Draft PR veya MR değişikliğin görünür olmasını istediğiniz ancak merge için henüz hazır olmadığınız durumlarda kullanılmalıdır. Early feedback almak büyük yanlış yönlere gitmeden önce faydalıdır. Architecture ve interface kararları kod tamamlanmadan tartışılabilir. Draft durumu reviewer'a change request'in henüz final olmadığını açıkça bildirir. Ready aşamasına geçiş için test, self review ve description gibi minimum kriterler belirlenmelidir.

Early Feedback

Geliştirici çözümün tamamını bitirmeden yaklaşım hakkında feedback isteyebilir. Özellikle yeni domain veya unfamiliar component üzerinde bu yöntem zaman kazandırır. Reviewer küçük bir yönlendirmeyle günlerce yanlış yönde geliştirme yapılmasını önleyebilir. Early feedback detaylı final review ile karıştırılmamalıdır. Değişiklik tamamlandığında yeniden tam review yapılmalıdır.

Architecture Feedback

Yeni servis, interface veya data model kararı kod bitmeden review edilirse değişiklik maliyeti düşer. Draft description içinde problem ve planlanan yaklaşım açıklanabilir. Reviewer implementation detail yerine architecture sınırlarına odaklanabilir. Büyük tasarım tartışmaları gerektiğinde kısa toplantı yapılabilir. Son karar ve gerekçe daha sonra PR discussion'a özetlenmelidir.

Henüz Merge Edilmemesi Gereken Değişiklik

Bazı değişiklikler CI çalışsın veya preview environment oluşsun diye erken açılabilir. Ancak testler eksik veya dependency bekleniyor olabilir. Draft işareti yanlışlıkla merge riskini azaltır. Branch protection yine temel güvenlik mekanizması olarak kalmalıdır. Draft'ın haftalarca unutulmaması için owner ve takip süreci gerekir.

Draft'tan Ready for Review'a Geçiş Kriterleri

Author feature scope'unun tamamlandığından emin olmalıdır. Temel testler çalışmalı ve bilinen CI hataları çözülmelidir. Self review tamamlanmalı ve description güncellenmelidir. Breaking change, migration veya security etkisi açıkça belirtilmelidir. Bu kriterler ekip review kuyruğunun hazır olmayan işler tarafından doldurulmasını engeller.

Code Review Nedir?

Code review bir geliştiricinin değişikliğinin başka bir kişi tarafından teknik ve bağlamsal olarak değerlendirilmesidir. Amaç yalnızca bug bulmak değildir. Maintainability, security, performance ve knowledge sharing de review'un önemli parçalarıdır. Review otomatik testlerle birlikte çalışır, onların yerine geçmez. İnsan reviewer requirement ve domain bağlamını değerlendirirken CI tekrarlanabilir teknik kontrolleri üstlenir.

Code Review'un Amaçları

İyi review kodun doğru çalıştığını ve ileride bakım yapılabilir kaldığını anlamaya çalışır. Güvenlik ve performans etkileri değişikliğin riskine göre değerlendirilir. Reviewer tek doğru stil dayatmak yerine ekip standardı ve requirement üzerinden konuşmalıdır. Review aynı zamanda kod tabanındaki bilgiyi farklı kişilere yayar. Bu nedenle her review yalnızca gate değil öğrenme ve ortak sahiplik fırsatıdır.

Correctness

Correctness kodun belirtilen requirement'ı doğru biçimde karşılayıp karşılamadığını değerlendirir. Happy path yanında edge case ve failure koşulları incelenmelidir. Reviewer yalnızca testlerin geçtiğine güvenmemelidir. Yanlış requirement'a göre yazılmış testlerin tamamı green olabilir. Issue ve acceptance criteria bu nedenle review sırasında mutlaka okunmalıdır.

Maintainability

Maintainability kodun gelecekte anlaşılması ve değiştirilmesi ne kadar kolay sorusuna odaklanır. Gereksiz abstraction veya aşırı duplication bu değerlendirmeye dahil olabilir. Naming ve module boundary önemlidir. Reviewer kişisel stil tercihlerini zorunlu kural gibi sunmamalıdır. Kodun ekip tarafından sürdürülebilir olması temel kriterdir.

Security

Security review input validation, authentication, authorization ve secret kullanımını değerlendirebilir. Her reviewer security uzmanı olmak zorunda değildir. Hassas path'ler CODEOWNERS ile uzman review'una yönlendirilebilir. Otomatik SAST faydalıdır ancak business authorization hatalarını her zaman bulamaz. Yüksek riskli değişikliklerde insan security review'u ayrıca gerekli olabilir.

Performance

Performance review yeni query, loop, network call veya memory kullanımının etkisini düşünür. Her micro optimization blocking hale getirilmemelidir. Gerçek workload ve SLO bağlamı önemlidir. Büyük data set üzerinde davranış değişecekse benchmark veya load test gerekebilir. Reviewer tahminle değil mümkün olduğunca ölçümle karar verilmesini teşvik etmelidir.

Knowledge Sharing

Review kod sahipliğinin tek kişide kalmasını engeller. Junior reviewer domain bilgisini öğrenebilir, senior reviewer da yeni implementation detaylarını görebilir. Reviewer rotation bus factor riskini azaltır. Yorumlarda karar gerekçesi açıklandığında bilgi repository içinde kalıcı hale gelir. Bu nedenle hızlı approval uğruna her değişikliği aynı tek kişiye göndermek uzun vadede sağlıklı değildir.

Review'un Test Sürecinden Farkı

Test belirli input ve davranışların beklenen sonucu üretip üretmediğini doğrular. Code review ise requirement, tasarım, bakım maliyeti ve risk gibi daha geniş sorular sorar. Otomatik test yanlış mimari kararı veya gereksiz scope'u her zaman yakalayamaz. İnsan reviewer da tüm edge case'leri zihinsel olarak güvenilir biçimde test edemez. İki mekanizma birbirinin alternatifi değil tamamlayıcısıdır.

Author, Reviewer, Approver ve Maintainer Rolleri

PR veya MR sürecinde rollerin ne anlama geldiği açık olmadığında sorumluluk kolayca karışır. Author değişikliği hazırlar, reviewer teknik inceleme yapar ve approver gerekli onayı verir. Code Owner belirli kod alanında sorumluluk taşırken maintainer repository yönetimi ve merge yetkisine sahip olabilir. Merger final entegrasyon işlemini gerçekleştiren kişi veya otomasyon olabilir. Kritik sistemlerde security reviewer gibi uzman roller ayrıca tanımlanabilir.

Author

Author değişikliği geliştiren ve PR veya MR'ı hazırlayan kişidir. Test, self review ve açıklama kalitesi öncelikle author'ın sorumluluğundadır. Reviewer'ın temel hataları bulmasını beklemek doğru çalışma modeli değildir. Author review yorumlarına cevap verir ve gerekli değişiklikleri uygular. Merge sonrası production etkisinin izlenmesine de gerektiğinde katılmalıdır.

Reviewer

Reviewer diff'i teknik ve domain bağlamında inceler. Yorumların blocking mi suggestion mı olduğunu açıkça belirtmelidir. Reviewer sadece hata arayan kişi değildir. Kodun anlaşılabilirliğine ve ekip bilgisinin yayılmasına katkı sağlar. Review kapasitesi ekip planlamasında gerçek iş olarak görülmelidir.

Approver

Approver değişikliğin merge edilmesi için gerekli formal onayı veren kişidir. Her reviewer approver olmak zorunda değildir. Regüle süreçlerde approver belirli yetki veya domain sorumluluğuna sahip olabilir. Approval mekanik kutu işaretleme haline gelmemelidir. Approver hangi diff versiyonunu onayladığını bilmelidir.

Code Owner

Code Owner belirli dosya veya dizinlerin teknik sorumluluğunu temsil eder. CODEOWNERS üzerinden otomatik review request oluşturulabilir. Hassas path'lerde owner approval zorunlu tutulabilir. Ownership yalnızca en kıdemli kişiye verilirse bottleneck oluşabilir. Takım bazlı ownership bilgi paylaşımını ve sürekliliği artırabilir.

Maintainer

Maintainer repository'nin teknik yönetiminde daha geniş sorumluluk taşır. Branch policy, release veya merge yetkileri bu role bağlı olabilir. Maintainer yetkisi normal review sürecini sürekli bypass etmek için kullanılmamalıdır. Emergency bypass ayrı break glass prosedürüne bağlanmalıdır. Maintainer davranışları audit edilebilir olmalıdır.

Merger

Merger gerekli tüm koşullar tamamlandıktan sonra değişikliği target branch'e alan kişi veya otomasyondur. Auto merge ya da merge queue kullanıldığında bu iş otomatikleşebilir. Merger'ın human reviewer ile aynı kişi olması her sistemde problem değildir. Ancak kritik regüle süreçlerde separation of duties gereği ayrılabilir. Merge işleminin hangi koşullarda yapılabileceği repository policy ile teknik olarak zorlanmalıdır.

Security Reviewer

Security reviewer yüksek riskli değişikliklerde güvenlik açısından ek inceleme yapar. Authentication, authorization, cryptography ve IAM alanlarında özellikle değerlidir. Her PR'ın security ekibine gönderilmesi bottleneck yaratır. CODEOWNERS ve path bazlı risk sınıflandırması doğru değişiklikleri doğru kişilere yönlendirebilir. Security review sonucunda çıkan blocking bulgular açık biçimde kaydedilmelidir.

Separation of Duties

Separation of duties kritik değişikliklerde tek kişinin kodu yazma, onaylama ve production'a alma yetkilerinin tamamını kontrolsüz biçimde kullanmasını engellemeyi amaçlar. Küçük ekiplerde tüm rollerin tamamen ayrılması pratik olmayabilir. Buna rağmen author'ın kendi değişikliğine tek formal onayı vermesi yüksek riskli sistemlerde zayıf kontrol oluşturur. Finans ve regüle yapılarda dört göz prensibi sık kullanılır. Politika değişiklik riskine ve uyum gereksinimlerine göre tasarlanmalıdır.

Author Kendi Değişikliğini Onaylayabilir mi?

Teknik olarak platform ve ayara göre mümkün olabilen senaryolar bulunabilir. Ancak author'ın kendi değişikliğini tek gerekli approval olarak kullanması human review hedefini ortadan kaldırır. Düşük riskli personal repository ile production ödeme sistemi aynı policy'ye ihtiyaç duymaz. Kurumsal repository'lerde self approval çoğu zaman kapatılmalıdır. En az bir bağımsız reviewer iyi bir varsayılan oluşturur.

Commit Atan Kişi Approval Verebilir mi?

MR'a sonradan commit ekleyen kişinin approval verebilmesi stale review riskine benzer bir sorun oluşturabilir. Kişi kendi eklediği değişiklikleri bağımsız gözle değerlendirmemiş olur. GitLab approval ayarlarında committer approval davranışı policy ile sınırlandırılabilir. Kritik projelerde commit atan kullanıcıların formal approval'a sayılmaması daha güçlü kontrol sağlar. Bu tür kuralın ekip tarafından neden uygulandığı açıkça anlatılmalıdır.

Merger ve Author Ayrılmalı mı?

Her repository'de merger ve author'ın farklı kişi olması zorunlu değildir. Gerekli reviewer ve CI kontrolleri teknik olarak enforced ise auto merge güvenli seçenek olabilir. Regüle sistemlerde ise final merge yetkisinin farklı role ait olması istenebilir. Amaç düğmeye kimin bastığından çok gerekli bağımsız doğrulamaların yapılmasıdır. Policy gerçek risk modeline göre belirlenmelidir.

Finans ve Regüle Sistemlerde Dört Göz Prensibi

Dört göz prensibi kritik değişikliğin en az iki bağımsız kişi tarafından görülmesini hedefler. Payment, ledger veya yetkilendirme değişikliklerinde bu kontrol önemli olabilir. Reviewer sayısı yalnızca form doldurmak için artırılmamalıdır. İkinci kişinin gerçekten ilgili domain veya risk alanını anlaması gerekir. Approval ve audit kayıtlarının değiştirilemez biçimde saklanması da uyum süreçlerinde önem taşıyabilir.

Reviewer Nasıl Seçilmeli?

Reviewer seçimi yalnızca kimin boş olduğuna göre yapılmamalıdır. Domain expertise ve code ownership yüksek riskli değişikliklerde önemlidir. Bunun yanında aynı kişiye sürekli review göndermek bottleneck ve bus factor problemi oluşturur. Reviewer workload görünür tutulmalı ve bilgi paylaşımı için rotation uygulanmalıdır. Junior ve senior reviewer'ların birlikte yer aldığı review süreci hem öğrenme hem kalite açısından güçlü sonuç verebilir.

Domain Expertise

Domain expert business kurallarını ve geçmiş kararları bilir. Ödeme veya authentication değişikliğinde bu bilgi genel kod becerisinden daha kritik olabilir. CODEOWNERS expert reviewer'ın otomatik atanmasını kolaylaştırabilir. Tek bir domain expert'e bağımlılık oluşturulmamalıdır. Pair review ve dokümantasyon bilgiyi ekip içinde yaymalıdır.

Code Ownership

Code ownership belirli modüllerin bakım sorumluluğunu görünür hale getirir. Owner değişiklik geçmişini ve hassas noktaları daha hızlı değerlendirebilir. Ownership bir kişiye özel kalmak zorunda değildir. Takım veya birden fazla kişi owner olabilir. Owner'ın izin veya yoğunluk durumunda review'un durmaması için alternatifler bulunmalıdır.

Reviewer Workload

Reviewer'ın on açık review beklemesi time to first review süresini uzatır. Review workload sprint veya günlük iş planının görünür parçası olmalıdır. Otomatik load balancing veya rotation kullanılabilir. Aynı domain içinde birden fazla reviewer yetiştirmek kapasiteyi artırır. Hız uğruna uygun olmayan reviewer'a kritik değişiklik göndermek doğru çözüm değildir.

Bus Factor

Bus factor bir sistemin bilgisinin kaç kişide bulunduğunu anlatan pratik risk göstergesidir. Her PR'ın aynı tek kişiye gitmesi kısa vadede hızlı olabilir. Uzun vadede o kişi ayrıldığında veya müsait olmadığında ciddi darboğaz oluşur. Review bilginin yayılması için kullanılmalıdır. CODEOWNERS grupları ve rotation bu riski azaltabilir.

Knowledge Sharing

Reviewer seçiminde yalnızca en bilgili kişiyi düşünmek öğrenme fırsatını kaçırabilir. Domain expert yanında öğrenmesi istenen ikinci reviewer atanabilir. Bu kişi başlangıçta formal approval vermek zorunda değildir. Zamanla farklı kişiler ownership alabilecek seviyeye gelir. Review süreci böylece repository'nin eğitim mekanizmasına dönüşür.

Junior–Senior Review Dengesi

Junior reviewer yeni bakış açısıyla anlaşılmayan kod bölümlerini fark edebilir. Senior reviewer architecture ve risk bağlamında daha fazla deneyim sağlayabilir. Her review'un yalnızca senior kişilere gitmesi ekipte bottleneck oluşturur. Junior review'u formal approval yerine ek öğrenme review'u olarak başlatılabilir. Zamanla domain bilgisi arttıkça approval sorumluluğu genişletilebilir.

CODEOWNERS Nedir?

CODEOWNERS repository içindeki dosya ve klasörleri belirli kullanıcı veya takımlarla eşleştiren ownership tanımıdır. Değişiklik ilgili path'e dokunduğunda otomatik review request üretilebilir. Required Code Owner approval kullanıldığında hassas kod alanları owner onayı olmadan merge edilemez. GitHub ve GitLab bu yaklaşımı farklı branch policy mekanizmalarıyla destekler. CODEOWNERS özellikle büyük ekiplerde reviewer seçimini manuel hafızadan çıkarıp repository metadata'sına dönüştürür.

Dosya ve Klasör Sahipliği

Ownership belirli dosya pattern'leri veya klasörler üzerinden tanımlanabilir. Backend ve frontend farklı ekipler tarafından sahiplenilebilir. Daha spesifik pattern genel ownership kuralını gerektiğinde geçersiz kılabilir. Dosya yapısı değiştiğinde CODEOWNERS da güncellenmelidir. Eski path'e bakan ownership görünürde var olup gerçekte hiçbir değişikliği yakalamayabilir.

Takım Bazlı Ownership

Tek kişi yerine takım kullanmak reviewer availability sorununu azaltır. Birden fazla domain uzmanı review yapabilir. Takım üyeliği organization veya group yönetimiyle güncellenebilir. Ayrılan kişinin username'ini onlarca repository'de değiştirme ihtiyacı azalır. Ownership grubunun çok geniş olması ise gerçek sorumluluğu belirsiz hale getirebilir.

Otomatik Review Request

Değişen path'e göre otomatik reviewer istemek author'ın doğru uzmanı elle seçme yükünü azaltır. Özellikle monorepo içinde yüzlerce component varsa bu önemli kolaylıktır. Otomatik request yalnızca notification üretmekle kalmamalı, gerekli path'lerde approval policy ile birlikte kullanılmalıdır. Reviewer overload oluşuyorsa ownership dağılımı yeniden değerlendirilmelidir. Otomasyon yanlış ownership modelini düzeltemez.

Required Code Owner Approval

Required Code Owner approval belirli dosyaların owner onayı olmadan merge edilmesini engeller. GitHub'da Code Owner review branch koruma kurallarıyla zorunlu tutulabilir. GitLab'da protected branch ve Code Owner approval birlikte uygulanabilir. Bu özellik payment veya authentication gibi hassas alanlarda güçlü kontrol sağlar. Ancak admin veya push bypass izinlerinin aynı korumayı etkisiz bırakmadığından emin olunmalıdır.

Sensitive Path'lerin Korunması

Security policy, IAM, production infrastructure ve payment kodları sensitive path olarak değerlendirilebilir. Bu alanlar genel bir reviewer yerine özel owner'a yönlendirilebilir. İki farklı approval kuralı aynı PR için birlikte gerekebilir. Path bazlı security scan de CI tarafında devreye girebilir. Sensitive path listesinin gerçek threat model ile uyumlu olması gerekir.

CODEOWNERS Nasıl Tasarlanmalı?

CODEOWNERS dosyası organizasyon şemasının birebir kopyası olmamalıdır. Amaç değişen kodu gerçekten anlayan kişilere review yönlendirmektir. Backend, frontend, database ve infrastructure gibi teknik alanlar temel gruplar olabilir. Authentication ve payment gibi yüksek riskli domain'ler daha spesifik owner kurallarına sahip olabilir. Ownership modelinin düzenli review edilmesi repository yapısı değiştikçe doğruluğunu korumasını sağlar.

Backend

Backend ownership API, service ve domain logic klasörlerini kapsayabilir. Büyük backend yapısında tek ekip yerine servis bazlı gruplar oluşturulabilir. Shared library için ortak platform owner gerekebilir. Reviewer'ın yalnızca framework bilgisi değil domain etkisini de anlayabilmesi önemlidir. Çok genel backend owner grubu yüzlerce gereksiz review notification'ı oluşturabilir.

Frontend

Frontend ownership component, page veya feature bazında dağıtılabilir. Design system ayrı owner grubuna sahip olabilir. UI security ve accessibility gibi özel alanlar gerektiğinde ek reviewer gerektirebilir. Generated asset dosyaları için review politikasının ayrı tutulması faydalıdır. Frontend owner değişen backend contract etkisini de gerektiğinde görebilmelidir.

Database

Migration ve schema klasörleri database owner tarafından review edilebilir. Büyük tablo ve index değişikliklerinde performance etkisi değerlendirilmelidir. Ownership yalnızca DBA rolüne bağlanmak zorunda değildir. Database konusunda deneyimli application geliştiricileri de bu gruba dahil olabilir. Amaç deployment sırasında veri güvenliği ve availability riskini azaltmaktır.

Infrastructure

Terraform, Kubernetes ve production configuration yolları infrastructure owner'a bağlanabilir. IAM veya network değişiklikleri ayrıca security owner gerektirebilir. Infrastructure diff'leri genellikle uygulama kodundan daha geniş blast radius taşır. Bu nedenle required owner approval mantıklıdır. Plan çıktısı CI üzerinden reviewer'a görünür biçimde sunulmalıdır.

Security

Security policy, authentication middleware veya cryptography code path'leri security owner'a yönlendirilebilir. Her repository dosyasını security ekibine göndermek gerekli değildir. Hassas path seçimi risk temelli yapılmalıdır. Security owner grubunda yeterli review kapasitesi bulunmalıdır. Aksi halde güvenlik kuralı sürekli bypass talebi üreten bottleneck'e dönüşebilir.

Documentation

Dokümantasyon ownership özellikle public API ve operational runbook'larda değerlidir. Yanlış dokümantasyon kod hatası kadar ciddi operasyon problemi oluşturabilir. Teknik writer veya domain owner birlikte reviewer olabilir. Generated docs için source dosya owner'ı yeterli olabilir. Documentation review'u sırf kod değil diye atlanmamalıdır.

Payment

Payment path'leri business ve security açısından yüksek risk taşıyabilir. Domain owner yanında security veya finance control reviewer gerekebilir. Idempotency, rounding ve retry davranışları dikkatle incelenmelidir. Değişiklikların audit logging etkisi de değerlendirilmelidir. Çok kritik sistemlerde minimum iki bağımsız approval uygulanabilir.

Authentication

Authentication kodu kimlik doğrulama akışını doğrudan etkiler. Session, token ve credential işlemleri hassas kabul edilmelidir. Security owner review'u burada güçlü koruma sağlar. Backward compatibility özellikle mobil client veya uzun oturumlarda önemlidir. Authentication değişiklikleri için failure ve abuse senaryoları test edilmelidir.

CODEOWNERS Dosyasının Kendisi Nasıl Korunur?

CODEOWNERS dosyası reviewer seçimini ve gerekli approval kurallarını etkilediği için güvenlik açısından özel bir dosyadır. Bu dosya herkes tarafından review olmadan değiştirilebiliyorsa saldırgan veya hatalı bir değişiklik kendi owner kontrolünü kaldırabilir. GitHub dokümantasyonu da CODEOWNERS dosyasının kendisi için owner tanımlanmasını güçlü koruma yöntemi olarak önerir. Protected branch ve direct push kısıtları bu kontrolü desteklemelidir. Repository governance tasarımında ownership policy dosyalarının kendileri de hassas configuration olarak görülmelidir.

CODEOWNERS İçin Code Owner

CODEOWNERS dosyasının kendisine ayrı owner tanımlamak ownership değişikliğini ikinci bir gözden geçirir. Bu owner repository yöneticisi veya governance ekibi olabilir. Değişiklik yapan kişi kendi kontrolünü tek başına kaldırmamalıdır. Owner grubunun erişimi düzenli kontrol edilmelidir. Bu basit kural birçok ownership bypass riskini azaltır.

Protected Branch

CODEOWNERS ana branch üzerinde tutulduğu için protected branch policy kritik rol oynar. Direct push açık kalırsa MR veya PR review'u atlanabilir. GitLab dokümantasyonunda da belirli push izinlerinin merge request tabanlı Code Owner kontrollerini atlayabileceği açıkça belirtilir. Push izni bu nedenle yalnızca gerçekten gerekli otomasyon veya yönetim hesaplarıyla sınırlandırılmalıdır. Branch protection tek başına değil approval policy ile birlikte düşünülmelidir.

Yetkisiz Ownership Değişikliğini Engellemek

Ownership değişikliği normal uygulama kodu değişikliğinden daha güçlü etki yaratabilir. Bu nedenle dedicated reviewer veya minimum iki approval düşünülebilir. Audit log ownership dosyasındaki geçmiş değişiklikleri göstermelidir. CI policy dosyada beklenmeyen pattern veya wildcard kullanımını kontrol edebilir. Özellikle security path owner'ının kaldırılması otomatik uyarı oluşturabilir.

Security-Sensitive Repository Governance

Security sensitive repository'lerde CODEOWNERS yalnızca kontrollerden biridir. Protected branch, required CI, signed commit ve separation of duties birlikte kullanılabilir. Admin bypass kullanımı kayıt altına alınmalıdır. Emergency süreç normal workflow yerine istisna olarak tasarlanmalıdır. Governance kurallarının periyodik olarak gerçek repository ayarlarıyla karşılaştırılması gerekir.

GitHub Pull Request Review Durumları

GitHub review akışında reviewer genel yorum bırakabilir, approve verebilir veya changes request edebilir. Yeni commit geldiğinde reviewer'dan tekrar review istenebilir. Discussion thread'lerin çözülmesi repository policy'ye göre merge için zorunlu hale getirilebilir. Review state yalnızca bir UI etiketi değil branch protection kurallarıyla birlikte merge kararını etkileyen sinyaldir. Ekiplerin hangi review durumunun ne anlama geldiğini ortak biçimde tanımlaması gerekir.

Comment

Comment reviewer'ın formal approve veya reject kararı vermeden feedback bırakmasını sağlar. Soru, suggestion veya bilgi amaçlı yorum için uygundur. Comment review merge'i otomatik olarak engellememelidir. Eğer yorum blocking ise bunun açıkça belirtilmesi gerekir. Böylece author hangi feedback'in merge öncesi çözülmesi gerektiğini anlayabilir.

Approve

Approve reviewer'ın mevcut değişikliği kabul edilebilir bulduğunu gösterir. Required review kuralı varsa merge koşullarından biri olabilir. Approval sonrası yeni commit gelirse repository stale review politikasına göre onay geçersiz hale gelebilir. Reviewer approval vermeden önce CI sonucunu ve unresolved discussion'ları gözden geçirmelidir. Approval hızlı ilerlemek için yapılan formaliteye dönüşmemelidir.

Request Changes

Request Changes reviewer'ın merge öncesinde düzeltilmesi gereken problem gördüğünü açıkça belirtir. Blocking correctness veya security sorunu için uygundur. Küçük naming tercihi için sürekli changes request kullanmak review sürecini gereksiz sertleştirir. Reviewer hangi koşulda tekrar approve edeceğini yorumda açıklamalıdır. Author gerekli değişiklikleri yaptıktan sonra re review isteyebilir.

Re-Request Review

Author review yorumlarını uyguladıktan sonra reviewer'ı tekrar çağırabilir. Re request yalnızca notification göndermek değil değişikliğin yeniden değerlendirilmesini istemektir. Büyük yeni commit geldiyse reviewer diff'i yalnızca son yorum satırından değil güncel bütünlük içinde kontrol etmelidir. CI sonucu da yeniden incelenmelidir. Ekip re review için makul SLA belirleyebilir.

Conversation Resolution

Conversation resolution discussion thread'in çözüldüğünü gösterir. Branch policy gerekli discussion'ların çözülmesini merge koşulu yapabilir. Her thread'in çözülmesi yalnızca author tarafından "resolve" düğmesine basılması anlamına gelmemelidir. Blocking konu gerçekten ele alınmış olmalıdır. Non blocking öneriler follow up issue ile kapatılabilir.

GitLab Merge Request Approval Yapısı

GitLab Merge Request approvals optional veya required olacak biçimde yapılandırılabilir. Required approval rules belirli sayıda veya belirli gruplardan onay alınmasını zorunlu kılabilir. Code Owner approval protected branch ile birlikte kullanılabilir. Approval rules farklı domain veya target branch'ler için ayrı uygulanabilir. GitLab'ın güncel dokümantasyonunda required approval ve Code Owner yeteneklerinin plan ve deployment modeline göre erişim koşulları bulunabildiği için kurumların kullandıkları sürüm ve planı ayrıca doğrulaması gerekir.

Optional Approval

Optional approval reviewer feedback'ini görünür hale getirir ancak merge için zorunlu değildir. Düşük riskli veya küçük ekip repository'lerinde başlangıç seviyesi olarak kullanılabilir. Ancak production main branch için yalnızca optional review çoğu durumda yeterli güvence sağlamaz. Optional approval knowledge sharing amacıyla ek reviewer'larda faydalıdır. Formal gate gereken alanlar required rule ile ayrılmalıdır.

Required Approval

Required approval tamamlanmadan merge işleminin gerçekleşmesini engeller. En az bir bağımsız review için iyi temel kontrol olabilir. Riskli değişikliklerde sayı veya domain requirement artırılabilir. Required sayı kör biçimde üç veya dört yapmak review kalitesini garanti etmez. Doğru approver grubunun seçilmesi sayının kendisinden daha önemlidir.

Approval Rules

Approval rules hangi kullanıcının veya grubun kaç onay vermesi gerektiğini tanımlayabilir. Farklı rules aynı MR üzerinde birden fazla uzmanlık alanını temsil edebilir. Database ve security değişikliği aynı anda iki ayrı rule tetikleyebilir. Rule isimleri neden gerektiğini açıkça göstermelidir. Çok fazla gereksiz rule developer experience'i bozacağı için risk bazlı tasarım tercih edilmelidir.

Code Owner Approval

Code Owner approval değişen dosyanın owner'ından review alınmasını sağlar. Protected branch ile birlikte zorunlu hale getirildiğinde kritik path'leri etkili biçimde korur. Owner grubu çok dar ise izin dönemlerinde merge süreci durabilir. Birden fazla yetkin reviewer bulunması bu nedenle önemlidir. Ownership değişikliği de aynı governance süreciyle korunmalıdır.

Grup Bazlı Approval

Approval için tek tek kullanıcı yerine grup tanımlamak bakım maliyetini azaltabilir. Ekip üyeliği değiştiğinde repository rule'larının tek tek değiştirilmesi gerekmez. Ancak grubun doğrudan üyelik ve eligibility davranışı kullanılan platform ayarlarına göre doğru anlaşılmalıdır. Çok geniş grup rubber stamp approval riskini artırabilir. Grup gerçek domain sorumluluğunu temsil etmelidir.

Domain Bazlı Approval

Domain bazlı approval değişikliğin etkilediği alana göre uzman review gerektirir. Payment, security, database veya infrastructure buna örnektir. Path tabanlı CODEOWNERS ve approval rules birlikte kullanılabilir. Böylece sıradan application değişikliği gereksiz security queue'suna girmez. High risk path dokunulduğunda ek kontrol otomatik devreye girer.

Approval Rule Nasıl Tasarlanmalı?

Approval policy değişiklik riskine göre kademeli olmalıdır. Her PR için üç reviewer zorunlu tutmak küçük değişikliklerde gereksiz bekleme yaratabilir. Buna karşılık authentication veya production infrastructure değişikliğinde tek genel reviewer yetersiz olabilir. Minimum bir reviewer iyi başlangıçtır ve özel path'ler için domain approval eklenebilir. Policy'nin amacı mümkün olan en fazla onayı toplamak değil doğru riski doğru uzmanla değerlendirmektir.

Minimum Bir Reviewer

Çoğu production repository'sinde en az bir bağımsız reviewer iyi temel kuraldır. Bu kontrol direct push yerine değişikliğin başka bir kişi tarafından görülmesini sağlar. Küçük ekiplerde review kapasitesi dikkate alınmalıdır. Reviewer author dışında biri olmalıdır. Green CI ile birlikte kullanıldığında basit fakat güçlü bir quality gate oluşturur.

Kritik Değişikliklerde İki Reviewer

High risk değişikliklerde iki bağımsız reviewer daha fazla perspektif sağlar. Reviewer'lardan biri domain, diğeri security veya platform uzmanı olabilir. İki kişinin aynı bilgiyi tekrar etmesi yerine farklı risk boyutlarını kapsaması daha değerlidir. Critical path listesi önceden tanımlanmalıdır. Böylece author hangi durumda iki approval gerektiğini önceden bilir.

Database Approval

Schema, index ve büyük backfill değişiklikleri database reviewer gerektirebilir. Lock ve migration duration riski değerlendirilmelidir. Application developer tek başına production veri hacminin etkisini fark etmeyebilir. Database owner deployment sırasını da inceleyebilir. Küçük query değişikliklerinin tamamını aynı gate'e sokmak yerine path ve risk bazlı kural kullanılabilir.

Security Approval

Authentication, authorization, cryptography ve secret yönetimi security approval gerektirebilir. Otomatik scan bu human review'un yerine geçmez. Security reviewer threat model ve abuse case açısından farklı sorular sorar. Approval kapasitesini korumak için yalnızca hassas path'ler bu rule'u tetiklemelidir. Security ekiplerinin review SLA'sı ayrıca planlanmalıdır.

Infrastructure Approval

Production Terraform veya Kubernetes değişiklikleri platform owner review'una yönlendirilebilir. Resource deletion ve network değişiklikleri geniş blast radius taşıyabilir. CI plan çıktısı reviewer'a sunulmalıdır. IAM değişikliği ayrıca security approval tetikleyebilir. Infrastructure review'u yalnızca syntax kontrolü olarak görülmemelidir.

Production Configuration Approval

Feature flag default değerleri, rate limit veya production secret reference gibi config değişiklikleri kod kadar etkili olabilir. Bu dosyalar ayrı CODEOWNERS kuralı ile korunabilir. Config diff küçük görünse bile kullanıcı etkisi büyük olabilir. Reviewer rollout ve rollback davranışını değerlendirmelidir. Environment specific configuration değişiklikleri audit geçmişinde açıkça görünmelidir.

Yeni Commit Geldiğinde Approval Sıfırlanmalı mı?

Approval belirli bir diff versiyonuna verilmiş karardır. Approval sonrasında yeni commit geldiğinde reviewer'ın görmediği kod merge edilebilir. Bu nedenle stale approval problemi özellikle high risk repository'lerde önemlidir. Tüm approval'ları sıfırlamak en güvenli yaklaşım olsa da küçük değişikliklerde review yükünü artırabilir. Risk bazlı politika veya yalnızca etkilenen Code Owner approval'ını yenileme yaklaşımı değerlendirilebilir.

Stale Approval Problemi

Reviewer PR'ı onayladıktan sonra author yeni commit push edebilir. Yeni kod önceki review kapsamının dışında kalır. Approval aynen geçerli kalırsa formal gate gerçek anlamını kaybedebilir. Repository ayarları stale review dismissal ile bu riski azaltabilir. Kritik sistemlerde son push'un mutlaka bağımsız kişi tarafından görülmesi iyi bir kontroldür.

Yeni Diff'in Önceki Review'u Geçersiz Hale Getirmesi

Küçük typo düzeltmesi ile authorization logic değişikliği aynı riskte değildir. Ancak sistem yeni commit'in semantik etkisini her zaman anlayamaz. Bu nedenle basit policy tüm approval'ı resetleyebilir. Daha gelişmiş workflow Code Owner path değişikliğine göre kısmi review isteyebilir. Ekip developer experience ile güvenlik arasında açık denge kurmalıdır.

Tüm Approval'ları Resetlemek

Her yeni commit sonrası approval resetlemek anlaşılır ve güçlü kuraldır. Reviewer güncel diff'i tekrar görmeden merge yapılamaz. Çok sık küçük commit gönderilen ekiplerde re review yükü oluşabilir. Author bu nedenle review'a hazır olmadan approval istememelidir. Final düzeltmelerin suggestion batch'i şeklinde yapılması süreç maliyetini azaltabilir.

Yalnızca Etkilenen Code Owner Approval'ını Resetlemek

Path bazlı ownership varsa yeni commit yalnızca belirli alanı etkileyebilir. Bu durumda yalnızca ilgili Code Owner'ın tekrar review etmesi daha verimli olabilir. Platformun bu davranışı nasıl uyguladığı kullanılan özelliklere göre doğrulanmalıdır. Cross cutting değişikliklerde birden fazla owner etkilenebilir. Otomasyonun yanlış güven üretmemesi için policy test edilmelidir.

Risk Bazlı Politika

Düşük riskli docs değişikliğinde tüm approval reset gereksiz olabilir. Payment veya IAM değişikliğinde ise en son diff'in mutlaka bağımsız review edilmesi gerekir. Risk seviyesi label, path veya policy engine üzerinden belirlenebilir. Exception süreci audit edilmelidir. Ekip hangi değişikliğin hangi risk kategorisine girdiğini kolayca anlayabilmelidir.

Reviewer Son Commit'i de Görmeli mi?

Evet, gerekli formal approval'ın anlamlı olması için en az bir reviewer'ın merge edilecek son değişiklik durumunu görmesi güçlü bir prensiptir. Approval sonrası author'ın küçük görünen fakat davranışı değiştiren commit eklemesi mümkündür. Most recent push approval veya stale review dismissal bu riski azaltabilir. Final review özellikle security sensitive repository'lerde önemlidir. CI'ın son commit üzerinde çalıştığı da ayrıca doğrulanmalıdır.

Review Sonrası Yeni Commit Riski

Yeni commit review edilen davranışı değiştirebilir. Bir test düzeltmesi bile production koduna yanlışlıkla dokunabilir. Reviewer yalnızca discussion cevabına bakıp diff'i kontrol etmezse problem gözden kaçabilir. Platform yeni değişiklikleri açık biçimde göstermelidir. High risk PR'larda final diff review bir merge kriteri yapılabilir.

Most Recent Push Approval

Most recent push yaklaşımı son değişikliği author dışında birinin görmesini hedefler. Böylece eski approval üzerinden görünmeyen code change merge edilmez. Kural review kalitesini artırırken küçük ekiplerde işlem süresini etkileyebilir. Emergency workflow ayrı tutulabilir. Normal süreçte bypass kullanılmaması gerekir.

Author'ın Approval Sonrası Kod Değiştirmesi

Approval sonrası code push etmek doğal geliştirme sürecinin parçası olabilir. Sorun değişikliğin yeni review almadan merge edilmesidir. Author push sonrasında reviewer'a ne değiştiğini kısa biçimde açıklayabilir. CI yeniden çalışmalıdır. Previous approval'ın korunması repository risk modeline göre otomatik yönetilmelidir.

Merge Öncesi Final Review

Final review özellikle uzun discussion ve çok sayıda commit içeren PR'larda değerlidir. Reviewer güncel Files Changed görünümünü tekrar kontrol eder. Tüm blocking thread'lerin gerçekten çözüldüğünü doğrular. Required checks ve security scan'in son SHA üzerinde green olduğunu görür. Bu kısa kontrol stale state nedeniyle oluşabilecek ciddi hataları azaltır.

İyi Bir Code Review Nasıl Yapılır?

İyi review diff'e doğrudan satır satır dalmadan önce değişikliğin bağlamını anlamakla başlar. Issue, description ve risk bilgisi okunur. Reviewer önce genel mimariyi tarar, ardından dosyaları ayrıntılı inceler ve testlerin gerçekten doğru davranışı doğruladığını kontrol eder. CI sonucuna bakılır fakat green pipeline otomatik approval anlamına gelmez. Review sonunda blocking konular ve genel değerlendirme kısa summary ile paylaşılabilir.

Önce Context'i Okumak

Reviewer önce PR'ın hangi problemi çözmeye çalıştığını anlamalıdır. Issue ve acceptance criteria okunmadan yalnızca kod stiline odaklanmak eksik review üretir. Business constraint veya backward compatibility gereksinimi description içinde olabilir. Riskli deployment bilgileri review kararını etkileyebilir. Context birkaç dakikada diff review'unun kalitesini ciddi biçimde artırır.

Diff'i Genel Olarak Taramak

İlk turda değişen dosyaların genel yapısı incelenebilir. Unexpected dosya veya çok geniş scope fark edilebilir. Refactor ile feature'ın gereksiz karışıp karışmadığı görülür. Reviewer hangi dosyaların daha yüksek risk taşıdığını belirler. Daha sonra ayrıntılı review bu öncelik sırasıyla yapılabilir.

Dosyaları Ayrıntılı İncelemek

Ayrıntılı incelemede logic, error handling ve data flow değerlendirilir. Reviewer yalnızca değişen satırlara değil gerekli olduğunda çevredeki mevcut koda da bakmalıdır. Bir fonksiyon değişikliği başka caller'ları etkileyebilir. Naming ve abstraction ekip standardıyla karşılaştırılabilir. Blocking olmayan stil önerileri açıkça suggestion olarak işaretlenmelidir.

Testleri Kontrol Etmek

Test dosyasının varlığı yeterli değildir. Test gerçekten yeni davranışı ve failure senaryosunu doğruluyor mu diye bakılmalıdır. Mock kullanımı gerçekte hata verecek entegrasyonu gizleyebilir. Regression fix'te hatayı yeniden üreten test değerli olur. Testin yalnızca coverage yüzdesini artırmak için yazılmadığından emin olunmalıdır.

CI Sonuçlarını Kontrol Etmek

Reviewer merge öncesinde required check'lerin green olduğunu kontrol etmelidir. Başarısız job blind retry ile geçildiyse flaky test ihtimali araştırılmalıdır. Son pipeline'ın güncel commit üzerinde çalıştığı doğrulanmalıdır. Merge queue varsa queue içinde combined validation ayrıca çalışabilir. CI sonucu code review kararını destekleyen sinyaldir.

Architecture'ı Değerlendirmek

Yeni dependency, module boundary veya cross service call architecture etkisi yaratabilir. Reviewer çözümün mevcut sistem prensipleriyle uyumlu olup olmadığını değerlendirmelidir. Her küçük PR'da architecture tartışması açmak gereksizdir. Ancak kalıcı interface veya data ownership kararı sonraki değişiklikleri yıllarca etkileyebilir. Bu tür kararlar draft aşamasında erken feedback ile ele alınırsa daha verimli olur.

Security Etkisini Kontrol Etmek

User input, permission veya secret kullanımını değiştiren kod security açısından incelenmelidir. Authorization kontrolünün yanlış katmana taşınması ciddi risk oluşturabilir. Automated scan yalnızca bilinen pattern'leri yakalayabilir. Reviewer business logic abuse senaryolarını da düşünmelidir. Gerekiyorsa security owner ek review vermelidir.

Review Summary Yazmak

Uzun review sonunda kısa summary author'a genel durumu anlatır. Blocking konular net biçimde listelenebilir. Olumlu noktalar da belirtilebilir. Çok sayıda thread arasında temel kararın kaybolması önlenir. Re review sırasında hangi sorunların çözülmesi beklendiği anlaşılır olur.

Reviewer Neleri Kontrol Etmeli?

Reviewer checklist değişiklik türüne göre uyarlanmalıdır. Doğruluk, edge case, error handling ve readability çoğu PR için temel başlıklardır. Security, performance ve backward compatibility yalnızca özel ekiplerin değil normal review'un da risk bazlı parçalarıdır. Observability özellikle production davranışını değiştiren feature'larda unutulmamalıdır. Checklist mekanik onay formuna dönüşmeden reviewer'ın önemli soruları hatırlamasını sağlamalıdır.

Doğruluk

Kod requirement'ı gerçekten karşılıyor mu sorusu review'un merkezindedir. Testin green olması yanlış requirement implementasyonunu engellemez. Reviewer issue ile diff'i karşılaştırmalıdır. Happy path ve failure davranışı birlikte değerlendirilmelidir. Yanlış data transformation gibi sessiz hatalara ayrıca dikkat edilmelidir.

Edge Case

Null, boş liste, tekrar eden istek veya concurrency gibi edge case'ler düşünülmelidir. Her olası durum için test zorunlu değildir. Ancak yüksek etkili sınır koşulları görünür olmalıdır. Domain expert geçmişte yaşanan edge case'leri daha iyi hatırlayabilir. Review bilgisi zamanla test suite'e taşınmalıdır.

Error Handling

Hata oluştuğunda sistem kontrollü davranmalıdır. Exception swallow edilmemeli ve gereksiz şekilde hassas bilgi kullanıcıya gösterilmemelidir. Retry mekanizması duplicate işlem üretmemelidir. Error logging yeterli bağlam içermelidir. Failure mode kullanıcı etkisi açısından değerlendirilebilir.

Readability

Kod başka bir geliştirici tarafından makul sürede anlaşılabilmelidir. Aşırı kısa isimler veya gereksiz abstraction okuma yükünü artırabilir. Comment yalnızca kodun ne yaptığını tekrar etmemelidir. Neden sıra dışı bir yaklaşım kullanıldığını açıklayan comment daha değerlidir. Readability kişisel stil tartışmasıyla karıştırılmamalıdır.

Maintainability

Değişiklik gelecekte yeni requirement geldiğinde kolayca genişletilebilir mi sorusu önemlidir. Ancak gelecekte belki gerekir diye aşırı general solution yazmak da maliyet oluşturur. Reviewer bugünkü gerçek ihtiyaca uygun sadelik aramalıdır. Coupling ve dependency yönleri incelenebilir. Testability maintainability'nin önemli parçalarından biridir.

Test Coverage

Coverage yalnızca yüzde olarak değerlendirilmemelidir. Yeni davranışın kritik branch'leri test ediliyor mu daha önemli sorudur. Changed code coverage yardımcı metric olabilir. Generated veya trivial kodlar coverage kararını yanıltabilir. Test kalitesi oran kadar önemlidir.

Security

Permission, input validation ve sensitive data handling kontrol edilmelidir. Secret source code'a eklenmemelidir. SQL injection veya unsafe command execution gibi bilinen riskler otomatik araçlarla da taranabilir. Business authorization mantığı human review gerektirir. High risk path security approval'a yönlendirilmelidir.

Performance

Yeni query veya API call request başına ekstra maliyet oluşturabilir. N plus one davranışı özellikle data erişiminde incelenmelidir. Caching ekleniyorsa invalidation ve stale data etkisi düşünülmelidir. Performance endişesi ölçülebilir olmalıdır. Kritik hot path değişikliklerinde benchmark veya load test istenebilir.

Backward Compatibility

Mevcut client ve servisler yeni değişiklikle çalışmaya devam edebilmelidir. API field silmek veya database column rename etmek riskli olabilir. Staged deployment döneminde eski ve yeni sürüm aynı anda çalışabilir. Expand contract yaklaşımı compatibility sağlar. Breaking change varsa deprecation ve migration planı gerekir.

Observability

Yeni davranış production'da nasıl anlaşılacak sorusu review sırasında sorulmalıdır. Hata oluştuğunda yeterli log bulunmalı ve kritik business metric gerekirse eklenmelidir. Yeni dependency latency'si ölçülebilir olmalıdır. Log içine hassas veri yazılmamalıdır. Deployment sonrası problemi görmek için telemetry değişiklikle birlikte düşünülmelidir.

Review Comment Severity Standardı

Review yorumlarının önem seviyesi açık olmadığında author her yorumu blocking kabul edebilir. Bu durum küçük stil önerilerinin merge süresini gereksiz uzatmasına yol açar. Blocking, major, suggestion, nit ve question gibi basit bir standardizasyon ortak dil oluşturur. Praise kullanımı da iyi uygulamaların görünür olmasını sağlar. Yorum severity'si ekip içinde suçlama değil öncelik bilgisi olarak kullanılmalıdır.

Blocking

Blocking yorum merge öncesinde çözülmesi gereken correctness, security veya ciddi requirement problemidir. Reviewer neden blocking olduğunu açıklamalıdır. Kişisel stil tercihleri blocking yapılmamalıdır. Author farklı çözüm önerirse discussion teknik gerekçeler üzerinden ilerlemelidir. Blocking thread çözülmeden approval verilmemelidir.

Major

Major önemli ancak bağlama göre follow up ile ele alınabilecek problem olabilir. Maintainability veya belirgin performance riski bu sınıfa girebilir. Ekip major yorumun merge'i engelleyip engellemediğini açıkça tanımlamalıdır. Aksi halde blocking ile farkı kalmaz. Reviewer severity etiketini yorum içeriğinde belirtebilir.

Suggestion

Suggestion daha iyi yaklaşım önerir ancak mevcut kodu hatalı ilan etmez. Alternative naming veya küçük refactor örneği olabilir. Author kabul etmeyebilir ve gerekçesini açıklayabilir. Suggestion'ların tamamını uygulamak zorunlu olmamalıdır. Bu ayrım review tartışmasını daha sağlıklı hale getirir.

Nit

Nit çok küçük ve çoğunlukla stil niteliğindeki gözlemdir. Formatting gibi konular mümkün olduğunca otomatik araçlara bırakılmalıdır. Nit merge'i engellememelidir. Çok sayıda nit yorumu asıl review sinyalini gölgeleyebilir. Tekrarlanan nit konuları linter kuralına dönüştürülebilir.

Question

Question reviewer'ın davranışı veya kararı anlamak istediğini gösterir. Soru otomatik requirement anlamına gelmemelidir. Author gerekçeyi açıklayabilir ve kod değişikliği gerekmeyebilir. Soru sonucunda gerçek risk ortaya çıkarsa blocking yoruma dönüşebilir. Bu ayrım savunmacı review iletişimini azaltır.

Praise

Praise iyi çözüm veya test yaklaşımını görünür hale getirir. Review yalnızca problem bulma alanı olmak zorunda değildir. Olumlu feedback ekip standardının hangi davranışları teşvik ettiğini gösterir. Ancak gereksiz formal praise yorumları review'u kalabalıklaştırmamalıdır. Gerçekten öğretici veya örnek bir nokta olduğunda kullanılmalıdır.

Neden Tüm Yorumlar Blocking Olmamalı?

Her yorum blocking olursa review kişisel tercihlerin merge gate'ine dönüşebilir. Author küçük suggestion'ları çözmek için sürekli yeni commit gönderir ve approval resetlenebilir. Bu durum cycle time'ı uzatır. Blocking yalnızca merge edildiğinde gerçek kalite veya risk problemi yaratacak konulara ayrılmalıdır. Diğer iyileştirmeler suggestion veya follow up issue olarak yönetilebilir.

Etkili Review Comment Nasıl Yazılır?

Review comment yalnızca "yanlış" demek yerine problemi ve nedenini açıklamalıdır. Mümkün olduğunda çözüm yönü önerilebilir ancak reviewer author adına tüm implementasyonu tasarlamak zorunda değildir. Yorum kişi yerine kod davranışına odaklanmalıdır. Question ile requirement açık biçimde ayrılmalıdır. Bu iletişim biçimi review'un teknik tartışma olarak kalmasını sağlar.

Problemi Açıklamak

Reviewer hangi davranışın problem olduğunu açıkça yazmalıdır. "Bu kötü" gibi yorum author'a aksiyon sağlamaz. Örneğin aynı payment request'in retry durumunda iki kez işlenebileceği belirtilirse risk anlaşılır. İlgili input veya senaryo eklenebilir. Böylece discussion kişisel görüş yerine gözlemlenebilir davranış üzerinden ilerler.

Nedenini Belirtmek

Yorumun arkasındaki teknik neden bilgi paylaşımı sağlar. Reviewer yalnızca kuralı söylemek yerine güvenlik, bakım veya performans etkisini açıklayabilir. Author aynı prensibi sonraki değişikliklerde uygulayabilir. Internal standard varsa bağlantı verilebilir. Gereksiz uzun teori yerine karar için gereken bağlam yeterlidir.

Çözüm Önerisi Sunmak

Net alternatif varsa reviewer örnek çözüm önerebilir. Platform suggestion özelliği küçük değişikliklerde hızlı uygulanabilir. Ancak öneri tek doğru çözüm gibi sunulmamalıdır. Author farklı ve daha iyi yaklaşım getirebilir. Blocking olan şey çözüm biçimi değil çözülmesi gereken problem olmalıdır.

Kişi Yerine Koda Odaklanmak

"Sen yanlış yaptın" yerine "Bu koşulda request iki kez çalışabilir" gibi kod odaklı dil kullanılmalıdır. Review ekip içi güveni korumalıdır. İnsanlar değişebilir fakat repository'de teknik tartışma kalıcıdır. Sert kişisel dil bilgi paylaşımını azaltır. Empatik ve açık iletişim teknik kaliteyi düşürmez.

Question ve Requirement'ı Ayırmak

"Bunu cache'e taşısak mı?" sorusu ile "Bu query request başına yüz kez çalıştığı için düzeltilmeli" aynı şey değildir. Reviewer niyetini severity veya açık kelimelerle belirtmelidir. Author hangi konunun merge öncesi gerekli olduğunu bilmelidir. Discussion sayısı azalsa bile belirsizlik daha çok zaman kaybettirebilir. Standardize edilmiş review dili bu problemi azaltır.

Review Discussion Nasıl Yönetilir?

Review discussion teknik kararların görünür biçimde çözüldüğü alandır. Thread belirli konuya odaklanmalı ve cevaplar aynı bağlamda tutulmalıdır. Problem çözüldüğünde discussion resolve edilebilir. Offline görüşme yapılırsa kararın kısa özeti PR veya MR'a geri yazılmalıdır. Daha sonra yapılabilecek non blocking işler follow up issue olarak çıkarılabilir.

Thread

Thread tek bir review konusu etrafındaki mesajları toplar. Farklı sorunlar mümkünse ayrı thread açılmalıdır. Böylece hangi konunun çözüldüğü açık görülür. Uzun discussion başka tasarım konusuna kayıyorsa yeni issue veya thread açılabilir. Thread sonunda kararın ne olduğu anlaşılır kalmalıdır.

Reply

Author yalnızca "done" yazmak yerine gerektiğinde ne değiştirdiğini açıklayabilir. Reviewer böylece çözümü daha hızlı doğrular. Değişiklik yapılmadıysa gerekçe teknik biçimde paylaşılmalıdır. Uzun savunma yerine requirement ve trade off üzerinden konuşmak daha verimlidir. Reply history gelecekte aynı kararın neden alındığını gösterebilir.

Resolve

Resolve thread'in artık açık aksiyon taşımadığını belirtir. Blocking comment gerçekten ele alınmadan resolve edilmemelidir. Bazı ekipler yalnızca yorum sahibi reviewer'ın resolve etmesini tercih eder. Diğer ekiplerde author değişikliği yaptıktan sonra resolve edebilir. Kural ne olursa olsun formal düğmeden çok gerçek problemin çözülmesi önemlidir.

Unresolved Conversation

Unresolved conversation merge öncesinde dikkat gerektiren açık tartışmayı gösterir. Branch policy tüm discussion'ların çözülmesini zorunlu hale getirebilir. Ancak non blocking fikir tartışmalarının merge'i haftalarca engellemesi sağlıklı değildir. Severity standardı bu noktada yardımcı olur. Blocking thread'ler çözülmeden merge edilmemelidir.

Follow-Up Issue

Current PR için gerekli olmayan fakat değerli iyileştirme follow up issue olarak taşınabilir. Issue owner ve öncelik bilgisi içermelidir. Böylece discussion "sonra bakarız" diyerek kaybolmaz. Security veya correctness problemi follow up'a atılmadan önce risk değerlendirilmelidir. Gerçekten merge sonrası yapılabilir işler ayrılmalıdır.

Offline Tartışmayı PR/MR'a Özetlemek

Bazen karmaşık konu kısa görüşmeyle daha hızlı çözülür. Ancak karar yalnızca toplantıya katılan kişilerin zihninde kalmamalıdır. PR veya MR discussion'a kısa karar özeti yazılmalıdır. Seçilen yaklaşım ve önemli gerekçe belirtilmelidir. Böylece audit ve gelecek bakım çalışmaları için bağlam korunur.

Tüm Discussion'lar Çözülmeden Merge Yapılmalı mı?

Bu karar discussion'ın niteliğine bağlıdır. Blocking correctness veya security konusu çözülmeden merge yapılmamalıdır. Non blocking suggestion ise follow up issue ile ertelenebilir. Repository policy tüm conversations resolved şartı koyuyorsa ekip comment severity standardını buna göre kullanmalıdır. Amaç teknik olarak tüm thread düğmelerini kapatmak değil gerçek risklerin açık kalmamasını sağlamaktır.

Required Conversation Resolution

Required conversation resolution açık discussion varken merge'i engeller. Bu kural reviewer feedback'inin unutulmasını önler. Ancak her küçük öneri unresolved bırakılırsa süreç yavaşlayabilir. Reviewer non blocking konuları açık biçimde işaretlemelidir. Follow up issue bağlantısı sonrası thread çözülebilir.

Blocking Discussion

Blocking discussion gerçek düzeltme veya karar gerektirir. Author değişiklik yapmalı veya reviewer ile kabul edilebilir alternatif üzerinde anlaşmalıdır. Thread resolve edilmeden approval verilmemelidir. Security riski varsa gerekli domain owner dahil edilebilir. Merge düğmesi teknik olarak açık olsa bile süreç kuralı ihlal edilmemelidir.

Non-Blocking Discussion

Non blocking discussion mevcut değişikliği merge etmeye engel olmayan iyileştirme veya soru içerir. Suggestion veya nit buna örnektir. Author isterse aynı PR'da uygulayabilir. Değişiklik scope'u büyütecekse follow up daha iyi olabilir. Reviewer bu ayrımı yorumda açıkça belirtmelidir.

Follow-Up Issue ile Erteleme

Bir konu bilinçli olarak erteleniyorsa issue oluşturulması kararı görünür kılar. Issue PR'a linklenmelidir. Risk ve neden ertelendiği kısa biçimde yazılabilir. Owner ve priority belirlenmesi unutulmayı önler. Kritik correctness sorunu yalnızca cycle time kısalsın diye follow up'a taşınmamalıdır.

Review SLA Nasıl Tanımlanmalı?

Review SLA geliştiricinin değişiklik açtıktan sonra ne kadar sürede feedback bekleyebileceğini belirler. Çok uzun review süreleri branch drift ve developer context loss oluşturur. Time to first review ve re review için farklı hedefler tanımlanabilir. Hotfix değişiklikleri daha hızlı response gerektirir. SLA reviewer kapasitesini dikkate almadan yalnızca sayı olarak belirlenirse sürekli ihlal edilen anlamsız hedefe dönüşür.

Time to First Review

İlk review süresi author'ın bekleme zamanını doğrudan etkiler. Küçük ekiplerde aynı iş günü içinde ilk feedback makul hedef olabilir. Büyük global ekiplerde timezone farkı dikkate alınmalıdır. Critical değişiklikler farklı önceliklendirilmelidir. Metric ekipleri cezalandırmak yerine bottleneck bulmak için kullanılmalıdır.

Re-Review Süresi

Author yorumları uyguladıktan sonra tekrar günlerce beklemek toplam merge süresini ciddi artırır. Re review genellikle ilk review'dan daha kısa sürer. Reviewer notification veya queue sistemi bunu görünür tutmalıdır. Çok büyük yeni commit geldiyse re review tekrar full review'a dönüşebilir. SLA bu farkı dikkate almalıdır.

Kritik Hotfix Review Süresi

Production incident sırasında hotfix review dakikalar veya kısa saatler içinde gerekebilir. On call veya designated reviewer hazır tutulabilir. Aciliyet review'un tamamen kaldırılması anlamına gelmemelidir. Minimum test ve bağımsız review korunmalıdır. Break glass kullanılırsa sonradan tam review yapılmalıdır.

Reviewer Availability

Review SLA gerçek reviewer availability'sine bağlıdır. Tek Code Owner tatildeyse required approval süreci durabilir. Ownership grupları birden fazla kişiden oluşmalıdır. Rotation ve backup reviewer planı yapılabilir. Availability sorunu bypass ile değil organizasyonel kapasiteyle çözülmelidir.

Review SLA'nın Developer Experience'a Etkisi

Uzun review bekleme süresi geliştiricinin başka işe geçmesine ve context kaybetmesine neden olur. Geri döndüğünde küçük değişiklik için yeniden saatlerce hatırlama maliyeti oluşabilir. Hızlı fakat yüzeysel review da kaliteyi düşürür. Amaç predictable ve yeterince derin review süresidir. PR analytics bu dengeyi ölçmeye yardımcı olur.

Reviewer Bottleneck Nasıl Önlenir?

Reviewer bottleneck genellikle teknik araçtan değil ownership modelinden kaynaklanır. Her kritik dosyanın tek kişiye bağlı olması review kuyruğu oluşturur. CODEOWNERS grupları, reviewer rotation ve knowledge sharing bu riski azaltır. Review workload görünür biçimde dağıtılmalıdır. Domain bilgisi zamanla daha fazla kişiye yayılmadıkça otomatik assignment yalnızca aynı darboğazı daha düzenli hale getirir.

CODEOWNERS Dağılımı

Ownership birden fazla yetkin kişiye dağıtılmalıdır. Tek username yerine uygun team kullanımı availability'yi artırır. Team çok büyükse herkes notification'ı başkasının ele alacağını düşünebilir. Rotation veya assignment otomasyonu gerçek owner belirleyebilir. Ownership review kapasitesiyle birlikte tasarlanmalıdır.

Reviewer Rotation

Rotation belirli gün veya hafta reviewer sorumluluğunu dağıtabilir. Diğer geliştiriciler kesintisiz feature çalışmasına daha fazla odaklanabilir. Rotation knowledge sharing'i destekler. Domain expert gerektiren değişiklikler yine özel owner'a gidebilir. Rotation yükü metric'lerle gözlenmelidir.

Review Load Balancing

Açık review sayısına göre reviewer seçmek daha dengeli dağılım sağlar. Otomasyon reviewer availability ve domain'i birlikte değerlendirebilir. Yalnızca round robin kullanmak yanlış uzman atamasına yol açabilir. High risk değişiklikler load'dan bağımsız doğru owner'a gitmelidir. Düşük riskli değişiklikler daha geniş ekipte paylaşılabilir.

Domain Bilgisini Yaymak

Tek domain expert bottleneck sorunu eğitim ve ortak review ile çözülmelidir. İkinci reviewer öğrenme amacıyla değişikliklere dahil edilebilir. Runbook ve architecture dokümantasyonu bilgi transferini destekler. Pair programming de belirli alanlarda kullanılabilir. Birkaç ay içinde daha fazla kişinin formal approver olabilecek seviyeye gelmesi hedeflenebilir.

Tek Maintainer'a Bağımlılığı Azaltmak

Merge yetkisi yalnızca tek maintainer'da olduğunda review tamamlanmış PR'lar bekleyebilir. Güvenli policy ve auto merge kullanımı bu ihtiyacı azaltabilir. Birden fazla maintainer veya merge queue operasyon sürekliliği sağlar. Yetki genişletilirken audit ve branch protection korunmalıdır. İnsan düğme basma görevi mümkün olduğunca otomatik koşullara bağlanabilir.

Protected Branch Nedir?

Protected branch kritik branch'lerin belirli kurallar dışında değiştirilmesini engeller. main branch için direct push, force push veya deletion sınırlandırılabilir. PR veya MR zorunlu hale getirilerek review ve CI kontrollerinin atlanması önlenebilir. GitHub branch protection kuralları required review ve status check gibi koşulları uygulayabilir. GitLab protected branch ise push ve merge izinlerini yönetirken Code Owner approval ile birlikte daha güçlü kontrol sağlayabilir.

main Branch'i Korumak

main branch çoğu repository'de production'a giden kaynak olduğundan en güçlü kuralları hak eder. Her geliştiricinin doğrudan push yapabilmesi insan review'unu atlar. Branch protection merge koşullarını teknik olarak enforce eder. CI veya approval şartı yalnızca dokümantasyonda kalmaz. Bu yaklaşım ekip büyüdükçe process drift riskini azaltır.

Direct Push Engelleme

Direct push kapatıldığında değişiklik PR veya MR üzerinden geçmek zorunda kalır. Böylece CI, code review ve audit kaydı oluşur. Release automation gerekiyorsa özel hesaplar kontrollü istisna alabilir. Bu istisnaların normal developer workflow'a dönüşmemesi gerekir. GitLab tarafında push izni verilen kullanıcıların MR kontrollerini atlayabileceği unutulmamalıdır.

Force Push Engelleme

Force push shared branch history'sini yeniden yazabilir. main üzerinde commit kaybı veya audit geçmişinin değişmesi riskini yaratır. Protected branch force push'u kapatmalıdır. Feature branch'lerde rebase workflow nedeniyle force push gerekebilir. Bu durumda force with lease gibi daha güvenli alışkanlıklar kullanılabilir.

Branch Delete Engelleme

Kritik branch'in yanlışlıkla silinmesi pipeline ve deployment süreçlerini bozabilir. Protected branch deletion kontrolü bu riski azaltır. Release branch'ler de gerektiğinde korunabilir. Kısa ömürlü feature branch'ler merge sonrasında otomatik silinebilir. Koruma policy branch'in gerçek rolüne göre uygulanmalıdır.

Pull/Merge Request Zorunluluğu

PR veya MR zorunluluğu tüm normal değişikliklerin aynı review akışından geçmesini sağlar. Required approval ve status check bu gate üzerinde uygulanabilir. Emergency bypass için ayrı break glass prosedürü tutulmalıdır. Her kullanıcıya bypass yetkisi verilirse kural görünürde var olur fakat pratikte etkisiz kalır. Audit düzenli olarak bypass olaylarını kontrol etmelidir.

GitHub Branch Protection ve Rulesets

GitHub branch protection ve rulesets repository değişikliklerini belirli koşullara bağlamak için kullanılabilir. Required reviews, required status checks, conversation resolution, signed commits ve linear history gibi kurallar desteklenir. Rulesets birden fazla kural setini aynı repository veya kapsam üzerinde yönetmeye yardımcı olabilir. Merge queue da yoğun branch'lerde required integration kontrolü olarak kullanılabilir. Güncel GitHub dokümantasyonuna göre required status checks geçmeden ilgili branch veya tag'e hedeflenen değişiklikler merge edilemez.

Required Reviews

Required reviews PR merge edilmeden önce belirli sayıda approving review ister. Minimum bir bağımsız reviewer production repository'leri için güçlü başlangıçtır. Code Owner review ayrıca zorunlu tutulabilir. Stale review dismissal yeni commit riskini azaltır. Admin bypass davranışı repository riskine göre ayrıca yapılandırılmalıdır.

Required Status Checks

Required status checks belirli CI kontrollerinin başarılı olmasını merge şartı yapar. Build, test ve security scan buna dahil edilebilir. GitHub rulesets gerekli check'in belirli kaynaktan gelmesini de destekleyen kontrol seçenekleri sunar. Yanlış veya güvenilmeyen check provider quality gate'i zayıflatabilir. Check isimleri pipeline refactor sırasında değişirse repository rule'ları da güncellenmelidir.

Conversation Resolution

Conversation resolution açık review discussion varken merge yapılmasını engelleyebilir. Blocking feedback'in unutulmasını önler. Reviewer suggestion yorumlarını gereksiz şekilde unresolved bırakmamalıdır. Follow up issue açılan konu çözülebilir. Takım hangi yorum türünün merge öncesi kapanması gerektiğini ortak biçimde tanımlamalıdır.

Signed Commits

Signed commit commit'in belirli cryptographic identity ile imzalandığını doğrulamaya yardımcı olur. GitHub rulesets signed commits gerektirebilir. Bu kontrol source identity güvenini artırır fakat kötü kodun merge edilmesini tek başına engellemez. Review ve CI yine gereklidir. Bot ve automation hesaplarının signing süreci de planlanmalıdır.

Linear History

Linear history merge commit oluşturmadan daha düz bir commit geçmişi hedefler. Squash veya rebase stratejileriyle uyumlu olabilir. History okumayı ve bazı bisect süreçlerini kolaylaştırabilir. Ancak gerçek branch birleşme bilgisini kaybetme trade off'u vardır. Ekip debug ve release ihtiyaçlarına göre karar vermelidir.

Merge Queue

Merge Queue özellikle aynı target branch'e yoğun değişiklik gelen repository'lerde kullanılır. PR gerekli branch protection koşullarını sağladıktan sonra queue'ya alınabilir. GitHub değişikliği target branch'in son hali ve sıradaki önceki değişikliklerle birlikte required check'lerden geçirir. Başarısız check veya conflict durumunda PR queue'dan çıkarılabilir. Böylece ayrı ayrı green olan PR'ların birlikte main'i bozma riski azaltılır.

Deployment Success Requirement

Ruleset politikaları belirli deployment environment sonucunu merge öncesi koşul olarak kullanabilecek şekilde tasarlanabilir. Bu yaklaşım staging doğrulamasını merge gate'e bağlamak isteyen ekiplerde faydalı olabilir. Environment protection ve deployment güvenliği ayrıca doğru yapılandırılmalıdır. Her PR için pahalı full deployment yapmak CI maliyetini artırabilir. Risk bazlı preview veya staging doğrulaması daha verimli olabilir.

GitLab Protected Branch Yönetimi

GitLab protected branch kuralları branch'e kimlerin push veya merge yapabileceğini kontrol eder. Code Owner approval protected branch ile birlikte zorunlu hale getirilebilir. Bu yapı direct push ile MR approval süreçlerinin atlanmasını önlemek için dikkatli yapılandırılmalıdır. Production branch için push permission mümkün olduğunca dar tutulabilir. Güncel GitLab dokümantasyonu protected branch üzerinde Code Owner approval ve farklı erişim seviyeleri için ayrı yapılandırmalar sunar.

Push Permission

Push permission branch'e doğrudan değişiklik gönderebilecek kullanıcıları belirler. main üzerinde geniş push izni MR review sürecini zayıflatabilir. Automation hesabı gerekiyorsa özel ve sınırlı erişim kullanılmalıdır. Human developer değişiklikleri mümkün olduğunca Merge Request üzerinden ilerlemelidir. Permission değişiklikleri audit edilmelidir.

Merge Permission

Merge permission gerekli koşullar tamamlandıktan sonra branch'e merge yapabilecek rolleri belirler. Approval vermek ile merge yetkisi aynı olmak zorunda değildir. Auto merge veya merge train bu işlemi koşullar üzerinden otomatikleştirebilir. Yetki çok sınırlıysa tek maintainer bottleneck oluşabilir. Governance ve developer experience birlikte değerlendirilmelidir.

Code Owner Approval

Protected branch için Code Owner approval etkinleştirildiğinde değişen path'lerin owner review'u zorunlu hale gelir. Bu kontrol sensitive kod alanlarında değerlidir. CODEOWNERS dosyasının kendisi de korunmalıdır. Push bypass izni owner review'u etkisiz hale getirebileceği için erişim modeli birlikte düşünülmelidir. Ownership gruplarının aktif ve ulaşılabilir olması gerekir.

Protected Branch Bazlı Approval

Her branch aynı riskte değildir. main veya production branch için daha güçlü approval kuralları kullanılabilir. Release branch farklı domain approver gerektirebilir. Development branch daha hafif policy ile çalışabilir. Branch sayısı arttıkça policy bakım maliyetinin yükseldiği unutulmamalıdır.

Production Branch Governance

Production branch doğrudan deployment tetikliyorsa güçlü approval ve CI gate gerekir. Direct push kapalı tutulmalıdır. Required discussions ve pipeline success merge şartı olabilir. Emergency change break glass süreciyle yönetilmelidir. Production branch'teki her bypass olayının sonradan review edilmesi iyi pratiktir.

Admin ve Maintainer Bypass Politikası

Admin veya maintainer yetkisinin tüm repository kurallarını istediği zaman atlaması kolay görünse de governance açısından önemli risk oluşturur. Bypass yalnızca gerçek acil durum veya recovery ihtiyacı için kullanılmalıdır. Break glass erişimi normal workflow'dan ayrı tutulabilir. Her bypass işlemi audit log ile kayıt altına alınmalıdır. Olay sonrasında değişikliğin normal review ve CI açısından tekrar değerlendirilmesi gerekir.

Administrator Her Kuralı Bypass Edebilmeli mi?

Teknik olarak bazı sistemlerde admin'e istisna tanınabilir. Ancak yüksek riskli repository'de admin bile required security rule'ları atlayamamalı yaklaşımı tercih edilebilir. Emergency ihtiyaç varsa ayrı kontrollü mekanizma kullanılmalıdır. Bypass yetkisi ne kadar genişse insider risk ve yanlışlık etkisi o kadar artar. Policy compliance gereksinimleriyle birlikte değerlendirilmelidir.

Break-Glass Access

Break glass normalde kullanılmayan acil erişim yöntemidir. Credential veya role yalnızca incident sırasında devreye alınabilir. Kullanım nedeni ve süresi kayıt altına alınmalıdır. Erişim sonrasında otomatik olarak geri kaldırılması tercih edilir. Düzenli tatbikat sürecin gerçekten çalıştığını doğrulayabilir.

Emergency Merge

Emergency merge production kesintisini düzeltmek için normal queue'dan daha hızlı ilerleyebilir. Buna rağmen minimum human review ve kritik testlerin korunması gerekir. Security veya data loss riski varsa uzman reviewer dahil edilmelidir. Merge sonrası production telemetry yakından izlenmelidir. Sonradan tam review ve post incident kontrol yapılmalıdır.

Audit Log

Audit log kim, ne zaman ve hangi kuralı bypass etti sorularını cevaplamalıdır. Yalnızca güvenlik olayı için değil process improvement için de değerlidir. Tekrarlanan bypass aynı policy'nin pratikte çalışmadığını gösterebilir. Audit erişimi sınırlandırılmalıdır. Önemli olaylar security monitoring'e gönderilebilir.

Bypass Sonrası Review

Acil merge olması code review ihtiyacını ortadan kaldırmaz. Incident kontrol altına alındıktan sonra değişiklik normal standartlarda tekrar incelenmelidir. Eksik test veya documentation tamamlanabilir. Bypass nedeni postmortem içinde değerlendirilmelidir. Eğer aynı tür emergency sürekli yaşanıyorsa workflow veya test altyapısı geliştirilmelidir.

CI/CD Merge Quality Gate

CI/CD merge quality gate insan tarafından tekrar edilmesi gereksiz olan kontrolleri otomatik hale getirir. Unit test, integration test, build, lint ve type check temel katmanlardır. Security scan yüksek riskli değişikliklerde ek koruma sağlar. Required status check olarak tanımlanan job'lar başarısızken merge işlemi teknik olarak engellenebilir. Pull request yönetiminde code owner CI kontrolleri ve otomatik test süreçleri birlikte çalıştığında review süreci daha hızlı ve güvenilir hale gelir.

Unit Test

Unit test küçük kod birimlerinin beklenen davranışını hızlı doğrular. PR başına sürekli çalıştırılabilecek kadar hızlı olması idealdir. Regression fix için yeni test önemli güvence sağlar. Unit test integration hatalarını tek başına yakalayamaz. Test suite'in güvenilirliği flaky test oranıyla birlikte izlenmelidir.

Integration Test

Integration test component veya servislerin birlikte doğru çalıştığını kontrol eder. Database, queue veya external contract etkileri bu katmanda görülebilir. Çalışma süresi unit test'ten daha uzun olabilir. Path based CI ile yalnızca ilgili testler çalıştırılabilir. Kritik entegrasyon testleri merge öncesinde required tutulabilir.

End-to-End Test

End to end test gerçek kullanıcı akışına yakın senaryoyu doğrular. Login, checkout veya critical workflow buna örnektir. Testler genellikle daha yavaş ve flaky olmaya yatkındır. Bu nedenle tüm E2E testlerini her küçük PR için çalıştırmak gerekli olmayabilir. Risk bazlı selection ve preview environment kullanımı maliyeti azaltabilir.

Build

Build uygulamanın derlenebilir veya paketlenebilir olduğunu doğrular. Compile error gibi temel problemler reviewer zamanından önce yakalanır. Container image üretiliyorsa reproducibility ve dependency güvenliği değerlendirilebilir. Build artifact daha sonraki test ve deployment aşamalarında yeniden kullanılabilir. Her stage'de farklı artifact üretmek tutarsız sonuç oluşturabilir.

Lint

Lint tekrar eden stil ve basit kod kalitesi kontrollerini otomatik hale getirir. Reviewer'ın whitespace ve formatting yorumları yazmasını azaltır. Kural sayısı aşırı olursa developer experience kötüleşebilir. Her lint kuralı gerçek ekip standardını yansıtmalıdır. Autofix desteklenen kontroller mümkün olduğunca otomatik uygulanmalıdır.

Type Check

Type check destekleyen dillerde birçok interface hatasını runtime öncesinde yakalayabilir. API contract veya refactor değişikliklerinde özellikle faydalıdır. Type escape kullanımının sürekli artması güveni azaltabilir. Required status olarak hızlı çalıştırılabilir. Type system business correctness testinin yerine geçmez.

Security Scan

Security scan source, dependency, secret veya container risklerini otomatik tarayabilir. Tool sonucu insan security review'unun yerine geçmemelidir. False positive yönetimi yapılmalıdır. Critical finding merge'i engelleyebilir. Suppression kullanılırsa gerekçe ve expiration tutulması faydalıdır.

Required Status Check

Required status check belirli CI sonucunu merge için zorunlu hale getirir. Check'in güncel commit üzerinde çalışması önemlidir. Merge queue kullanıldığında queue merge group için ayrıca CI tetiklenebilir. Flaky required check developer'ı sürekli retry yapmaya iter ve gate'e güveni azaltır. Bu nedenle required yapılan her job yüksek güvenilirlik hedeflemelidir.

Merge Öncesi Security Kontrolleri

Security kontrolleri merge sonrasında yapılan ayrı bir denetim olmaktan çıkarılıp PR veya MR akışına alınabilir. SAST, dependency, secret, container ve IaC scanning farklı risk sınıflarını kapsar. License compliance ve SBOM supply chain görünürlüğünü artırabilir. Tüm araç çıktısını blocking yapmak gereksiz gürültü oluşturabilir. Severity, exploitability ve değişikliğin gerçek bağlamına göre risk bazlı quality gate kullanılmalıdır.

SAST

SAST source code üzerinde bilinen güvenlik pattern'lerini analiz eder. Injection veya unsafe API kullanımını yakalayabilir. False positive oluşabileceği için finding review süreci gerekir. Critical sonuçlar security owner'a yönlendirilebilir. Business authorization hatalarının tamamı SAST ile bulunamaz.

Dependency Scanning

Dependency scanning kullanılan kütüphanelerde bilinen vulnerability olup olmadığını kontrol eder. Yalnızca vulnerability varlığı exploit edildiği anlamına gelmez. Runtime kullanım ve fix sürümü değerlendirilmelidir. Critical upgrade ayrı PR olarak hızlı ilerleyebilir. Otomatik dependency bot'ları bu süreci destekleyebilir.

Secret Scanning

Secret scanning repository'ye yanlışlıkla eklenen credential veya token pattern'lerini yakalamaya çalışır. Secret commit edildikten sonra yalnızca satırı silmek yeterli değildir. Credential rotate edilmelidir. Pre commit kontrolü ve platform scanning birlikte kullanılabilir. False positive pattern'leri kontrollü biçimde yönetilmelidir.

Container Scanning

Container scanning image içindeki OS package ve dependency risklerini analiz eder. Base image güncelliği önemlidir. Her vulnerability application tarafından erişilebilir olmayabilir. Critical ve exploitable finding'ler merge veya release gate olabilir. Image üretim pipeline'ı aynı artifact üzerinde tarama yapmalıdır.

IaC Scanning

Infrastructure as Code scanning Terraform veya Kubernetes configuration'larında riskli pattern'leri yakalayabilir. Public storage, geniş IAM yetkisi veya unsafe network rule buna örnektir. Security owner human review'u yine değerlidir. Tool policy kurum standartlarıyla uyumlu olmalıdır. False positive yüzünden scanner sürekli bypass edilmemelidir.

License Compliance

Dependency lisansları ürünün dağıtım modelini etkileyebilir. License compliance izin verilmeyen veya özel yükümlülük taşıyan dependency'leri merge öncesinde işaretleyebilir. Legal policy teknik pipeline'a yansıtılabilir. Her warning developer tarafından yorumlanamayacağı için net escalation yolu gerekir. Policy değişiklikleri merkezi olarak yönetilmelidir.

SBOM

Software Bill of Materials uygulamanın hangi component ve dependency'lerden oluştuğunu kayıt altına alır. Supply chain incident sırasında etkilenen component'i hızlı bulmaya yardımcı olur. CI artifact olarak üretilebilir. SBOM'un güncel build ile eşleşmesi gerekir. Tek başına security kontrolü değildir fakat görünürlük sağlar.

Code Coverage Quality Gate

Coverage test suite hakkında faydalı sinyal sunar fakat kaliteyi tek başına ölçmez. Toplam coverage oranı legacy repository'de yeni değişikliğin test kalitesini gizleyebilir. Changed code coverage bu nedenle daha anlamlı ek metric olabilir. Coverage düşüşünü engellemek faydalıdır ancak sırf sayı artsın diye anlamsız test yazmak istemediğiniz bir sonuçtur. Review testin gerçekten doğru davranışı doğrulayıp doğrulamadığını değerlendirmeye devam etmelidir.

Toplam Coverage

Toplam coverage repository'deki çalıştırılan kod oranını gösterir. Büyük legacy projede yüzde artışı yavaş olabilir. Sert yüksek threshold yeni geliştirmeleri gereksiz zorlaştırabilir. Component bazlı hedefler düşünülebilir. Metric trend olarak izlendiğinde daha anlamlı hale gelir.

Changed-Code Coverage

Changed code coverage yalnızca PR'ın dokunduğu yeni veya değişen kodu değerlendirir. Legacy düşük coverage'ın yeni kod standardını düşürmesini önler. Yeni davranış için daha güçlü test beklentisi getirilebilir. Generated kod hariç tutulabilir. Yine de yüzde yüz coverage correctness garantisi değildir.

Coverage Düşüşünü Engellemek

Mevcut coverage seviyesinin PR nedeniyle belirgin düşmesi quality gate ile engellenebilir. Küçük dalgalanmalar için tolerance gerekebilir. Refactor sırasında branch sayısı değiştiğinde oran doğal olarak hareket edebilir. Author neden düşüş olduğunu açıklayabilmelidir. Policy test kalitesini desteklemeli, metriğin kendisini hedef haline getirmemelidir.

Coverage'ın Kalite ile Aynı Şey Olmaması

Test satırı çalıştırabilir fakat doğru assertion yapmayabilir. Yüksek coverage birçok edge case'in test edildiği anlamına gelmez. Reviewer test isimlerini ve davranışını okumalıdır. Mutation testing gibi farklı teknikler gerektiğinde ek güven sağlayabilir. Coverage yalnızca tek kalite sinyalidir.

Flaky Test'ler Merge Sürecini Nasıl Etkiler?

Flaky test aynı kod üzerinde bazen geçen bazen başarısız olan testtir. Required CI içinde flaky test bulunması developer'ın gerçek hatayla test altyapısı hatasını ayırmasını zorlaştırır. Blind retry alışkanlığı zamanla gerçek regression'ın da "test yine bozuldu" diyerek gözden kaçmasına yol açabilir. Flaky test ownership ve quarantine süreçleri oluşturulmalıdır. Merge queue kullanılan sistemlerde flaky test kuyruk throughput'unu doğrudan düşürür.

False-Negative Pipeline

Kod doğru olduğu halde test rastgele hata verebilir. PR gereksiz yere blocked olur. Reviewer pipeline'a güvenini kaybetmeye başlar. Hangi testlerin flaky olduğu metric olarak tutulabilir. Kritik required testlerin reliability seviyesi yüksek olmalıdır.

Blind Retry Problemi

Pipeline failed olduğunda neden bakmadan retry yapmak tehlikelidir. İkinci deneme green olursa gerçek race condition gizlenebilir. Retry sayısı takip edilebilir. Flaky olduğu bilinen test ayrı issue ile sahiplenilmelidir. "Bir daha çalıştır geçer" kültürü quality gate'i anlamsızlaştırır.

Flaky Test Quarantine

Quarantine problemli testi ana required gate'ten geçici olarak ayırabilir. Test tamamen silinmemeli ve görünmez hale gelmemelidir. Owner ve düzeltme deadline'ı bulunmalıdır. Quarantine suite ayrı raporlanabilir. Uzun süre quarantine'de kalan testler technical debt haline gelir.

Flaky Test Ownership

Her flaky test belirli ekip veya component owner'a atanmalıdır. Sahipsiz test sürekli retry ile yaşamaya devam eder. Flaky rate ekip kalite metriği olarak izlenebilir. Root cause CI environment veya test isolation olabilir. Düzeltme yalnızca timeout süresini artırmak olmamalıdır.

Merge Queue Üzerindeki Etkisi

Queue içinde başarısız flaky check PR'ın kuyruktan çıkarılmasına veya grup validation'ın tekrar çalışmasına neden olabilir. Bu durum yalnızca ilgili author'ı değil arkasındaki PR'ları da etkiler. CI maliyeti ve merge latency artar. Queue kullanan repository'lerde test reliability daha kritik hale gelir. Flaky test azaltmak doğrudan developer throughput iyileştirmesidir.

Preview Environment Kullanımı

Preview environment her PR veya MR için geçici uygulama ortamı oluşturmayı sağlar. Reviewer yalnızca code diff değil çalışan davranışı da görebilir. UI, QA ve product review özellikle bu modelden faydalanır. Environment üretim verisi veya gerçek secret'larla gereksiz biçimde paylaşılmamalıdır. Merge veya PR kapanışı sonrasında otomatik cleanup maliyet ve güvenlik açısından önemlidir.

Her PR/MR İçin Geçici Ortam

Branch adına veya PR numarasına göre ephemeral environment oluşturulabilir. Application ve gerekli dependency'lerin minimal versiyonu deploy edilebilir. Her değişiklik için full production kopyası pahalı olabilir. Risk ve ihtiyaç seviyesine göre environment kapsamı ayarlanabilir. URL PR description içine otomatik eklenebilir.

UI Review

Designer veya frontend reviewer çalışan ekranı doğrudan görebilir. Responsive davranış ve interaction diff'ten daha kolay anlaşılır. Screenshot yine review kaydı için eklenebilir. Preview data kişisel bilgi içermemelidir. Visual regression test ile human review birbirini tamamlayabilir.

QA

QA acceptance criteria'yı geçici ortamda doğrulayabilir. Backend ve frontend entegrasyon hataları daha erken fark edilir. Test data tekrar üretilebilir olmalıdır. Environment instability QA sonucunu yanıltmamalıdır. Build edilen artifact ile sonradan production'a gidecek artifact mümkün olduğunca aynı kaynak olmalıdır.

Product Review

Product owner feature'ın requirement'a uygunluğunu merge öncesinde görebilir. Bu review code approval yerine geçmez. Kullanıcı akışı ve business acceptance açısından farklı perspektif sağlar. Büyük değişikliklerde yanlış requirement interpretation erken yakalanabilir. Product feedback'in blocking olup olmadığı net belirtilmelidir.

Environment Cleanup

PR merge veya close olduğunda preview kaynakları otomatik silinmelidir. Unutulan environment cloud maliyeti ve security surface oluşturur. TTL yaklaşımı ek güvenlik sağlar. Persistent test data varsa cleanup ayrıca yapılmalıdır. Cleanup job'ının kendisi de başarısızlık açısından izlenmelidir.

Infrastructure PR/MR'larında Review

Infrastructure değişiklikleri çoğu zaman application kodundan daha geniş etki alanına sahiptir. Terraform plan veya Kubernetes manifest diff'i reviewer'a gerçek resource etkisini göstermelidir. IAM ve network değişiklikleri security açısından ayrıca incelenebilir. Maliyet etkisi de review kararının parçası olabilir. Production infrastructure için domain owner ve security approval birleşik biçimde uygulanabilir.

Terraform Plan

Terraform plan hangi kaynakların create, update veya destroy edileceğini gösterir. Reviewer source diff kadar plan çıktısını da incelemelidir. Unexpected resource replacement özellikle dikkat gerektirir. Plan ile apply arasında configuration drift oluşmamalıdır. CI plan artifact'ını PR üzerinde kolay okunabilir biçimde sunabilir.

Kubernetes Manifest Diff

Manifest değişikliği replica, resource limit, security context veya network behavior'ı etkileyebilir. Generated Helm output gerektiğinde ayrıca incelenmelidir. Deployment strategy ve readiness davranışı review edilmelidir. Kubernetes üzerinde servis dağıtımı ve operasyon yönetimi hakkında daha geniş bir bakış için https://www.diyarbakiryazilim.com.tr/posts/ubuntu-sunucularda-servis-dagitimi-ve-yonetim-ipuclari adresindeki yaklaşım da altyapı süreçlerini planlarken yararlı bağlam sağlayabilir. Merge sonrasında rollout metric'leri izlenmelidir.

Network Değişiklikleri

Firewall, route veya load balancer değişikliği birçok servisi aynı anda etkileyebilir. Blast radius description içinde açıkça belirtilmelidir. Connectivity test planı bulunmalıdır. Security review özellikle public exposure değişiyorsa gerekli olabilir. Rollback yöntemi önceden hazırlanmalıdır.

IAM Değişiklikleri

IAM permission değişiklikları least privilege açısından incelenmelidir. Wildcard yetkiler gerekçesiz biçimde eklenmemelidir. Resource ve action scope reviewer tarafından kontrol edilmelidir. Security CODEOWNER bu path'lerde required approval verebilir. Production access değişikliği audit trail içinde açıkça görünmelidir.

Maliyet Etkisi

Infrastructure PR yeni büyük database veya sürekli çalışan compute kaynağı oluşturabilir. Plan teknik olarak doğru olsa bile maliyet etkisi önemli olabilir. Tahmini cost diff CI tarafından üretilebilir. Büyük maliyet değişiklikleri platform veya finance owner approval gerektirebilir. Cost review gereksiz küçük kaynaklarda bureaucracy oluşturmamalıdır.

Security Approval

Public endpoint, IAM veya encryption değişikliği security approval gerektirebilir. Security reviewer Terraform syntax yerine threat ve permission etkisine odaklanmalıdır. Automated IaC scan ek sinyal sağlar. High risk değişikliklarda minimum iki domain review kullanılabilir. Emergency infrastructure fix sonradan tam review edilmelidir.

Database Değişikliklerinde Review

Database değişiklikleri yanlış yönetildiğinde uygulama rollback'inden daha zor sorunlar yaratabilir. Schema migration, index, backfill ve table lock riski ayrı ayrı değerlendirilmelidir. Deployment sırasında eski ve yeni uygulama sürümlerinin aynı schema ile çalışabilmesi önemlidir. Irreversible data transformation açıkça işaretlenmelidir. Database domain reviewer yüksek riskli migration'larda merge gate olarak kullanılabilir.

Schema Migration

Schema migration mümkün olduğunca backward compatible tasarlanmalıdır. Yeni column eklemek genellikle mevcut column'ı doğrudan silmekten daha güvenlidir. Expand contract yaklaşımı staged deployment sağlar. Migration'ın production veri hacminde çalışma süresi değerlendirilmelidir. Test database boyutu gerçek riski yansıtmayabilir.

Table Lock

Bazı DDL işlemleri tablo üzerinde uzun lock oluşturabilir. Büyük production tablolarında bu durum user request'lerini durdurabilir. Reviewer kullanılan database engine davranışını bilmelidir. Online migration yöntemi gerekebilir. Deployment window ve rollback planı açık olmalıdır.

Index

Yeni index query performance'ı artırabilir fakat write maliyeti ve storage tüketimi oluşturur. Büyük tabloda index creation uzun sürebilir. Concurrent veya online seçenekler platforma göre değerlendirilebilir. Gereksiz duplicate index eklenmemelidir. Query plan ölçümü karar için faydalıdır.

Backward Compatibility

Rolling deployment sırasında eski application instance'ları yeni schema ile çalışmaya devam etmelidir. Column rename veya type change bu durumu bozabilir. İki aşamalı migration daha güvenlidir. Consumer tamamıyla geçtikten sonra eski field kaldırılabilir. Compatibility planı PR description içinde görünmelidir.

Backfill

Backfill milyonlarca row üzerinde ciddi load oluşturabilir. Tek transaction içinde çalıştırmak lock ve replication lag yaratabilir. Batch ve rate limit kullanılabilir. Progress metric ve retry mekanizması düşünülmelidir. Backfill çoğu zaman schema migration'dan ayrı job olarak yönetilmelidir.

Rollback

Database rollback her zaman eski migration'ı tersine çalıştırmak kadar kolay değildir. Silinen veri geri getirilemeyebilir. Forward fix daha güvenli olabilir. Application rollback'in schema ile uyumu ayrıca kontrol edilmelidir. Reviewer gerçek failure senaryosunu düşünmelidir.

Database Domain Reviewer

Database reviewer engine davranışı, production veri hacmi ve query pattern konusunda uzmanlık sağlar. Her küçük ORM değişikliğinin özel reviewer beklemesi gerekmeyebilir. Migration ve critical query path'leri CODEOWNERS ile otomatik yönlendirilebilir. Review SLA bottleneck oluşturmayacak şekilde kapasite planlanmalıdır. Domain bilgisi birden fazla geliştiriciye yayılmalıdır.

API Değişikliklerinde Review

API değişikliği yalnızca server kodunu değil onu kullanan tüm consumer'ları etkileyebilir. Breaking change, schema ve backward compatibility bu nedenle açıkça değerlendirilmelidir. API contract otomatik testlerle doğrulanabilir. Consumer impact bilinmeden field silmek production incident oluşturabilir. Deprecation planı breaking change'i kontrollü geçişe dönüştürür.

Breaking Change

Mevcut consumer'ın kod değişikliği olmadan çalışmasını bozan davranış breaking change'dir. Field silmek, meaning değiştirmek veya yeni zorunlu parametre eklemek örnek olabilir. Breaking değişiklik açık label ile işaretlenmelidir. Versioning veya staged rollout planı gerekir. Consumer owner'ların review'a dahil edilmesi faydalıdır.

Backward Compatibility

Yeni API sürümü eski consumer'ların kullanımını sürdürmesine izin verebilir. Additive field değişiklikleri çoğu zaman daha güvenlidir. Server ve client deployment sırası dikkate alınmalıdır. Contract test compatibility'yi otomatik doğrulayabilir. Eski behavior kaldırılmadan önce kullanım metric'i izlenmelidir.

API Contract

OpenAPI veya benzeri contract diff'i review sırasında görünür hale getirilebilir. Reviewer implementation detail yerine dış interface etkisini hızlı görür. Contract CI tarafından generated kodla karşılaştırılabilir. Breaking change otomatik tespit edilebilir. Contract source of truth açıkça belirlenmelidir.

Schema

Request ve response schema değişiklikleri validation davranışını etkiler. Optional field'ı required yapmak eski consumer'ları bozabilir. Enum'a yeni değer eklemek bazı client'larda unexpected behavior oluşturabilir. Serialization format değişikliği ayrıca incelenmelidir. Schema diff review checklist'in parçası olabilir.

Consumer Impact

API'yi hangi servis ve uygulamaların kullandığı bilinmelidir. Service catalog veya telemetry bu bağımlılığı gösterebilir. Internal API olduğu için otomatik olarak güvenli değişiklik varsayılmamalıdır. Consumer ekipler riskli değişikliklerde review'a çağrılabilir. Usage metric kaldırma kararını destekleyebilir.

Deprecation Plan

Eski API behavior bir anda kaldırılmak yerine deprecation süreciyle yönetilebilir. Deadline ve migration dokümanı consumer'lara iletilmelidir. Kullanım metric'i hangi consumer'ın hâlâ eski versiyonda olduğunu gösterir. Son kullanıcı geçişi tamamlanmadan removal merge edilmemelidir. Deprecation code'unun da belirli tarihte temizlenmesi planlanmalıdır.

Feature Flag ile PR/MR Yönetimi

Feature flag deployment ile kullanıcıya release kararını birbirinden ayırır. Incomplete feature küçük PR'lar halinde main'e merge edilebilir fakat flag kapalı olduğu için kullanıcıya görünmez. Bu yaklaşım uzun ömürlü feature branch ihtiyacını azaltır. Dark launch ve progressive rollout yapılabilir. Ancak unutulan flag'ler zamanla kod tabanında ciddi bakım maliyeti oluşturduğu için cleanup planı şarttır.

Deployment ile Release'i Ayırmak

Kod production'a deploy edilebilir fakat feature flag kapalı tutulabilir. Teknik deployment başarılı olduktan sonra product release farklı zamanda yapılabilir. Bu ayrım rollback baskısını azaltır. Flag değerinin production configuration governance'ı altında olması gerekir. Release sırasında metric ve error rate izlenmelidir.

Eksik Feature'ı Güvenle Merge Etmek

Büyük feature'ın temel altyapısı kullanıcıya görünmeden main'e alınabilir. Küçük PR'lar erken integration avantajı sağlar. Flag dışındaki path'lerde yeni kodun yan etki yaratmadığından emin olunmalıdır. Hidden code yine security ve test review'dan geçmelidir. "Kapalı flag" quality gate'leri atlamak için gerekçe değildir.

Dark Launch

Dark launch yeni backend davranışını kullanıcıya görünür sonuç üretmeden gerçek trafik üzerinde çalıştırabilir. Performance ve dependency etkisi ölçülebilir. User data handling dikkatle tasarlanmalıdır. Duplicate side effect oluşturulmamalıdır. Metric'ler old ve new path'i karşılaştırmayı sağlamalıdır.

Kill Switch

Kill switch problemli feature'ı deploy rollback yapmadan hızlıca devre dışı bırakır. Kritik user facing feature'larda güçlü mitigation yöntemidir. Flag yönetim sisteminin kendisi yüksek availability sağlamalıdır. Yetkisiz kullanıcı flag değiştirememelidir. Incident sonrasında kalıcı düzeltme yapılmalı ve switch sürekli açık bırakılmamalıdır.

Feature Flag Cleanup

Feature tamamen rollout edildiğinde eski branch logic ve flag kaldırılmalıdır. Stale flag test matrix'i ve cognitive load'u artırır. Expiration date veya owner metadata kullanılabilir. Otomatik rapor uzun süredir değişmeyen flag'leri gösterebilir. Cleanup ayrı küçük PR olarak yapılabilir.

Merge Conflict Nedir?

Merge conflict Git'in iki değişikliği otomatik olarak nasıl birleştireceğine güvenli karar veremediği durumdur. Aynı satırın değiştirilmesi en bilinen örnektir fakat rename veya delete durumları da conflict üretebilir. Branch uzun süre target'tan uzak kaldıkça conflict ihtimali artar. Binary dosyalarda otomatik merge daha da sınırlıdır. Conflict çözümü yalnızca marker silmek değil iki değişikliğin niyetini doğru biçimde korumaktır.

Conflict Neden Oluşur?

İki branch aynı kod alanını farklı biçimde değiştirmiş olabilir. Git satır tabanlı history üzerinden birleştirme kararı verir. Semantik olarak uyumsuz fakat text conflict oluşturmayan değişiklikler de mümkündür. Bu nedenle conflict yokluğu integration güvenliği anlamına gelmez. CI birleşik sonucu mutlaka test etmelidir.

Branch'in Güncel Olmaması

Feature branch haftalarca main'den güncellenmezse drift büyür. Aynı dosyalarda başka değişiklikler birikir. Rebase veya merge işlemi daha zor hale gelir. Kısa branch yaşamı bu problemi azaltır. Merge queue final target durumu üzerinde ek doğrulama sağlar.

Aynı Satırın Değiştirilmesi

İki branch aynı satırı farklı içerikle değiştirdiğinde Git otomatik tercih yapamaz. Developer iki değişikliğin niyetini anlamalıdır. Sadece kendi tarafını seçmek diğer feature'ı kaybettirebilir. Conflict çözüldükten sonra ilgili testler yeniden çalıştırılmalıdır. Reviewer final diff'i görmelidir.

Rename/Delete Conflict

Bir branch dosyayı rename ederken diğer branch aynı dosyayı silebilir veya değiştirebilir. Git kullanıcıdan hangi intent'in doğru olduğunu belirlemesini isteyebilir. Dosya taşıma refactor'ları conflict oranını artırabilir. Büyük rename'leri feature değişikliğinden ayırmak faydalıdır. Conflict çözümü sonrasında build ve tests özellikle önemlidir.

Binary Conflict

Binary dosyalar satır tabanlı otomatik merge'e uygun değildir. İki versiyondan biri seçilmek zorunda kalabilir. Generated binary artifact'ları repository'de tutmamak mümkünse tercih edilmelidir. Asset değişikliklerinde source file korunmalıdır. Conflict ownership ilgili domain reviewer'a yönlendirilebilir.

Merge Conflict Nasıl Çözülür?

Conflict çözmeden önce target branch'in güncel durumu alınmalıdır. Team workflow'a göre merge veya rebase ile branch güncellenebilir. Conflict dosyalarında iki tarafın niyeti anlaşılmalı ve doğru final davranış oluşturulmalıdır. Çözüm sonrasında testlerin tamamı yeniden çalıştırılmalıdır. Büyük conflict varsa önceki approval'ın güncel diff için geçerli olmadığı kabul edilip yeni review istenmesi daha güvenlidir.

Target Branch'i Güncellemek

Önce remote target branch fetch edilmelidir. Local branch'in hangi commit'e göre çalıştığı anlaşılmalıdır. Güncel target ile integration yapılmadan eski CI sonucuna güvenilmemelidir. Merge queue bu işlemin final aşamasını otomatik hale getirebilir. Manuel workflow kullanan ekiplerde update sıklığı açık standarda bağlanabilir.

Merge ile Güncellemek

Target branch feature branch'e merge edilerek güncelleme yapılabilir. History'de merge commit oluşabilir. Conflict bir kez çözülür ve branch üzerine yeni commit eklenir. Shared branch'te history rewrite gerekmez. Repository'nin linear history kuralıyla uyumluluğu kontrol edilmelidir.

Rebase ile Güncellemek

Rebase feature commit'lerini güncel target'ın üzerine yeniden oynatır. Daha linear history sağlar. Commit hash'leri değiştiği için remote branch'e force push gerekebilir. Shared feature branch'te koordinasyon önemlidir. Rebase sonrası approval ve CI tekrar çalışmalıdır.

Conflict Dosyalarını Düzenlemek

Conflict marker'ları mekanik biçimde kaldırmak yeterli değildir. İki branch'in getirdiği davranış birlikte düşünülmelidir. Gerektiğinde ilgili author ile kısa görüşme yapılabilir. Final kod lint ve type check'ten geçmelidir. Özellikle security path conflict'i domain owner tarafından yeniden incelenmelidir.

Testleri Yeniden Çalıştırmak

Conflict çözümü yeni ve daha önce test edilmemiş bir kod kombinasyonu oluşturur. Bu nedenle eski green pipeline geçerli sayılmamalıdır. Unit ve integration testler tekrar çalışmalıdır. Merge result pipeline veya queue varsa final kombinasyonu ayrıca doğrular. Flaky failure'lar kör retry ile geçilmemelidir.

Approval'ın Yenilenmesi

Conflict çözümü önemli kod değişikliği yaratmış olabilir. Reviewer'ın onay verdiği diff artık aynı değildir. Stale approval dismissal otomatik kullanılabilir. Küçük conflict bile sensitive path'i etkiliyorsa Code Owner yeniden review etmelidir. Final merge öncesi en az bir bağımsız reviewer güncel diff'i görmelidir.

Merge Commit, Squash ve Rebase Arasındaki Fark

Merge yöntemi repository history'sinin nasıl görüneceğini belirler. Merge commit branch birleşimini ayrı commit olarak korur. Squash PR içindeki commit'leri tek commit'e indirger. Rebase merge commit oluşturmadan commit'leri target history'nin devamına taşır. Hiçbir yöntem evrensel olarak en iyi değildir ve repository debug, release ve contributor modeline göre seçim yapılmalıdır.

Merge Commit

Merge commit feature branch history'sini ve birleşme noktasını korur. PR içindeki individual commit'ler main history'de görünür kalır. Büyük feature'ın gelişim adımları gerektiğinde izlenebilir. Buna karşılık çok sayıda küçük "fix review" commit'i history'yi kalabalıklaştırabilir. Commit disiplininin iyi olduğu ekiplerde güçlü seçenek olabilir.

Avantajları

Branch'in gerçek development history'si korunur. PR sınırı merge commit üzerinden kolayca görülebilir. Revert bazı durumlarda merge commit üzerinden yönetilebilir. Individual commit'ler debugging için değerlidir. History rewrite ihtiyacı azdır.

Dezavantajları

Sık merge yapılan repository'de history yoğun görünebilir. Author'ın geçici commit mesajları kalıcı hale gelir. Linear history isteyen ekipler için uygun değildir. Bisect sırasında ara commit'ler çalışmıyor olabilir. Commit hygiene daha fazla önem kazanır.

Squash Merge

Squash merge PR içindeki tüm commit'leri tek final commit olarak target'a ekler. PR başlığı ve description final history için daha önemli hale gelir. Küçük feature branch'lerde temiz ve kolay okunur history sağlar. Lokal "fix typo" ve review commit'leri ana history'ye taşınmaz. Buna karşılık detaylı commit gelişim geçmişi kaybolur.

Avantajları

Her PR target branch'te tek atomic commit olabilir. Revert etmek kolaylaşır. History daha kısa ve okunabilir kalır. Contributor commit kalitesi değişken olsa bile final commit standardize edilebilir. Conventional PR title otomatik changelog ile iyi çalışır.

Dezavantajları

PR içindeki anlamlı commit ayrımları target history'de kaybolur. Büyük PR tek commit haline geldiğinde bisect granularity azalır. Co author attribution dikkatli yönetilmelidir. Commit bazlı release süreçleri PR başlığına bağımlı hale gelir. Çok büyük değişiklikleri squash etmek onları otomatik olarak iyi hale getirmez.

Rebase Merge

Rebase merge feature commit'lerini merge commit oluşturmadan target branch history'sinin devamına ekler. Linear history korunur. Individual commit'ler görünür kalabilir. Commit'lerin kendi başına temiz ve build edilebilir olması daha önemli hale gelir. Contributor'ların rebase kavramını anlaması süreç kalitesini artırır.

Avantajları

History linear ve kolay takip edilir. Merge commit gürültüsü oluşmaz. Individual commit'ler korunabilir. Bisect anlamlı commit yapısında iyi çalışır. Release history sade kalabilir.

Dezavantajları

Commit history rewrite nedeniyle hash'ler değişebilir. Shared branch'lerde rebase koordinasyon gerektirir. Kötü hazırlanmış commit'ler main history'ye taşınır. Conflict her commit aşamasında çözülebilir. PR sınırı merge commit kadar belirgin olmayabilir.

Hangi Merge Stratejisi Kullanılmalı?

Merge stratejisi ekip büyüklüğü, history kullanım biçimi ve release modeline göre seçilmelidir. Küçük SaaS ekibi squash ile sade history tercih edebilir. Açık kaynak projede contributor commit'lerini korumak önemli olabilir. Enterprise monorepo merge queue ile belirli yöntemleri standardize edebilir. Seçim sürekli değiştirilmemeli ve repository policy ile açık biçimde uygulanmalıdır.

Küçük SaaS Takımları

Squash merge küçük ve tek amaçlı PR'larla iyi çalışır. Her feature veya fix main history'de tek commit olur. Revert kolaylaşır. PR title standardı release note üretiminde kullanılabilir. Çok uzun branch'lerden kaçınılmalıdır.

Açık Kaynak Projeleri

Açık kaynak projelerde contributor attribution ve commit history önem taşıyabilir. Merge commit veya rebase tercih edilebilir. Maintainer contributor commit'lerini squash etmeyi repository standardına göre uygulamalıdır. DCO veya CLA süreçleri merge yöntemiyle uyumlu olmalıdır. Contributor guide açık beklenti sunmalıdır.

Enterprise Monorepo

Monorepo'da günde yüzlerce PR merge edilebilir. Standardized merge method ve merge queue history tutarlılığını artırır. Path based CI ve CODEOWNERS review hızını korur. Squash küçük feature history'sini sadeleştirebilir. Repository çapındaki tooling bütün ekipler için aynı davranışı enforce etmelidir.

Release Branch Kullanan Projeler

Release branch modelinde merge history cherry pick ve backport süreçlerini etkileyebilir. Atomic squash commit backport yapmayı kolaylaştırabilir. Büyük squash commit ise sadece bir kısmını backport etmeyi zorlaştırır. Release workflow gerçek maintenance ihtiyacına göre test edilmelidir. Merge stratejisi hotfix süreciyle de uyumlu olmalıdır.

Linear History İsteyen Takımlar

Linear history için rebase veya squash kullanılabilir. Merge commit kapatılabilir. Bunun karşılığında branch birleşme geçmişi daha az görünür olur. PR linkleri commit metadata veya platform üzerinden korunmalıdır. Developer'lar rebase conflict çözümünü bilmelidir.

Squash Commit Message Nasıl Standartlaştırılır?

Squash merge final target history'de tek commit oluşturduğu için commit mesajının kalitesi önem kazanır. PR veya MR başlığını final subject olarak kullanmak pratik yaklaşım sunar. Conventional Commit prefix otomatik release süreçlerini destekleyebilir. Issue ID traceability sağlar. Release note otomasyonu başlık standardıyla doğrudan ilişkilendirilebilir.

PR/MR Title Kullanımı

PR title final squash commit message olarak kullanılabilir. Bu nedenle title açık ve anlamlı olmalıdır. "Update code" gibi başlık history'yi değersizleştirir. Reviewer merge öncesinde title kalitesini de kontrol edebilir. Platform template veya lint rule standardı enforce edebilir.

Conventional Commit

feat, fix veya refactor prefix'leri final commit'in türünü gösterir. Automated versioning buna göre çalışabilir. Breaking change ayrıca işaretlenebilir. Prefix zorunluysa CI title lint kullanılabilir. Standard takım tarafından kolay anlaşılmalıdır.

Issue ID

Issue ID commit'i requirement veya ticket ile ilişkilendirir. Başlık veya body içinde tutulabilir. ID tek başına commit mesajı olmamalıdır. Repository başka sisteme taşınsa bile kısa niyet açıklaması anlamını korur. Issue linkinin erişilebilirliği ayrıca düşünülmelidir.

Release Note

Kullanıcıya yansıyan değişiklik için release note bilgisi PR'dan üretilebilir. Internal refactor release note'a girmeyebilir. Breaking change açıkça belirtilmelidir. Product diline ihtiyaç varsa ayrı field kullanılabilir. Commit subject ile kullanıcı release note'u aynı olmak zorunda değildir.

Otomatik Changelog

Changelog generation consistent title ve label metadata'dan yararlanabilir. Manuel release note hazırlama yükü azalır. Yanlış sınıflandırma kullanıcıya anlamsız changelog üretir. Reviewer PR label'ını da kontrol edebilir. Automation source of truth net biçimde belirlenmelidir.

Auto-Merge Nedir?

Auto merge gerekli review ve CI şartları tamamlandığında PR veya MR'ın insanın tekrar düğmeye basmasını beklemeden merge edilmesini sağlar. Bekleyen pipeline nedeniyle geliştiricinin işi sürekli takip etme ihtiyacını azaltır. GitHub auto merge required review ve status checks tamamlandığında PR'ı birleştirebilir. GitLab tarafında gerekli koşullar sonrasında otomatik merge akışı uygulanabilir. Auto merge güvenli olabilmesi için stale approval ve required check policy'sinin doğru yapılandırılmış olması gerekir.

Approval Sonrası Otomatik Merge

Gerekli approval tamamlanmış fakat CI hâlâ çalışıyorsa auto merge etkinleştirilebilir. Developer pipeline tamamlanınca yeniden dönmek zorunda kalmaz. Sonradan yeni commit gelirse approval policy yeniden uygulanmalıdır. Blocking discussion açık kalmamalıdır. Automation yalnızca mevcut quality gate'lerin tamamı green olduğunda işlem yapmalıdır.

Pipeline Başarılı Olunca Merge

CI tamamlanınca değişiklik otomatik target branch'e alınabilir. Bu yaklaşım özellikle uzun test suite'lerinde faydalıdır. Pipeline stale target üzerinde çalışıyorsa integration riski devam edebilir. Merge queue veya merged result pipeline bu boşluğu azaltır. Required checks'in gerçekten doğru branch state'ini doğruladığından emin olunmalıdır.

Required Checks

Auto merge required checks'i bypass etmemelidir. Test, build ve security gate aynı şekilde uygulanır. Failure oluşursa merge gerçekleşmez. Check sonradan yeniden çalıştırılırsa sonuç güncel commit ile ilişkilendirilmelidir. Required job listesi repository değiştikçe güncel tutulmalıdır.

Auto-Merge'in Manuel Merge'den Farkı

Manuel merge'de kişi tüm koşullar tamamlandıktan sonra geri dönüp işlem yapar. Auto merge aynı kararın otomatik gerçekleşmesini sağlar. Kalite standardı teoride değişmez. Fark developer bekleme ve operasyon yükündedir. Yoğun repository'de queue ile birlikte kullanıldığında daha kontrollü throughput sağlar.

GitHub Merge Queue Nedir?

GitHub Merge Queue yoğun branch'lerde Pull Request'lerin güvenli sırayla merge edilmesini otomatikleştirir. Required checks'i tamamlamış PR queue'ya eklenebilir. GitHub değişikliği target branch'in son durumu ve queue'da önünde bulunan değişikliklerle birlikte test eder. Required check başarısız olursa veya conflict oluşursa PR queue'dan çıkarılabilir. Böylece PR author'larının sürekli branch update edip yeniden CI beklemesi ihtiyacı azalır.

Yoğun main Branch Problemi

Çok sayıda PR aynı anda green olabilir. İlk PR merge edildikten sonra ikinci PR'ın test ettiği target artık eskimiş olur. Bu stale result birlikte çalışan kodun bozuk olmasını gizleyebilir. Her author'ın sürekli main rebase etmesi ciddi CI ve zaman maliyeti oluşturur. Merge queue bu koordinasyonu merkezi biçimde yönetir.

PR'ı Queue'ya Eklemek

PR gerekli review ve branch koşullarını sağladığında queue'ya alınabilir. GitHub uygun durumda Merge when ready akışıyla sıraya ekleme sağlayabilir. Queue sırası branch policy tarafından yönetilir. User write access gereksinimi ve plan özellikleri kullanılan hesap modeline göre değişebilir. Repository kurulumunda güncel platform dokümantasyonu kontrol edilmelidir.

Merge Group

Queue bir veya birden fazla PR'ı target'ın güncel haliyle geçici merge group içinde doğrulayabilir. CI provider merge group event'ini desteklemelidir. Required checks bu combined state üzerinde çalışır. Grup başarısızsa problemli PR queue'dan çıkarılabilir. Böylece target'a gitmeden integration problemi görülür.

Required Checks

Queue için required check workflow'larının merge group üzerinde de çalışması gerekir. Sadece pull request event'ine bağlı CI queue'da beklenen sonucu üretmeyebilir. Pipeline configuration güncel GitHub event modeline göre ayarlanmalıdır. Security ve test job'ları combined code üzerinde çalışabilir. Check reliability queue throughput için kritiktir.

Queue'dan Çıkarılma

Failed required check veya merge conflict PR'ın queue'dan çıkarılmasına neden olabilir. User da manuel olarak çıkarabilir. PR timeline neden çıkarıldığını gösterebilir. Problem düzeltildikten sonra tekrar queue'ya girilebilir. Flaky test nedeniyle sürekli çıkarılan PR'lar CI kalitesi problemini görünür hale getirir.

Merge Sırası

Queue merge sırasını otomatik yönetir. Önceki değişiklik target'a girdikçe arkadaki validation buna göre güncellenir. Priority veya queue settings repository politikasına göre farklılaşabilir. Manual sıra müdahalesi gereksiz kullanılmamalıdır. Amaç main branch'i predictable ve green tutmaktır.

GitLab Merge Train Nedir?

GitLab Merge Train aynı target branch'e giden Merge Request'leri queue mantığında birleştirerek doğrular. Her MR yalnızca mevcut target ile değil, önünde merge olması beklenen MR'ların değişiklikleriyle birlikte test edilir. GitLab'ın güncel dokümantasyonuna göre merge train pipeline'ları paralel çalışabilir ve başarısız MR train'den çıkarıldığında arkasındaki gerekli pipeline'lar yeni kombinasyona göre yeniden oluşturulur. Bu yapı ayrı ayrı başarılı olan MR'ların birlikte target branch'i bozmasını engellemeyi hedefler. Yoğun default branch kullanan projelerde önemli reliability katmanıdır.

Merge Request Queue

Merge Train MR'ları target branch için sıraya alır. Önündeki MR başarıyla merge olmadan arkadaki MR target'a geçmez. Queue state Merge Request arayüzünde görülebilir. Required approval ve pipeline koşulları yine geçerlidir. Train normal review sürecinin yerine geçmez, final integration aşamasını güçlendirir.

Merged Results Pipeline

Merged results pipeline source branch ile target branch'in geçici birleşik commit'ini test eder. Bu commit gerçek branch'lerde bulunmayabilir. Amaç merge sonrasında oluşacak kodu önceden doğrulamaktır. Standart MR pipeline yalnızca source değişikliğini test ediyorsa bu entegrasyon etkisini kaçırabilir. Merge Train bu merged result yaklaşımını queue içindeki önceki MR'larla genişletir.

Önündeki MR'ların Değişiklikleriyle Test

Train'deki ikinci MR target ile birlikte ilk MR'ın değişikliğini de içeren state üzerinde test edilir. Üçüncü MR önündeki ilk iki değişiklikle birlikte doğrulanabilir. Böylece A ve B ayrı ayrı green iken birlikte bozuluyorsa B merge edilmeden problem görülür. Bu davranış yoğun integration ortamında stale CI riskini azaltır. Queue sırası test bağlamının önemli parçasıdır.

Parallel Merge Train Pipeline

GitLab merge train pipeline'larını birden fazla MR için paralel çalıştırabilir. Her pipeline önündeki queue durumuna göre farklı combined commit test eder. Paralellik toplam merge throughput'u artırır. Ön sıradaki MR başarısız olursa arkasındaki bazı pipeline'ların yeniden hesaplanması gerekir. CI kapasitesi train parallelism seviyesine göre planlanmalıdır.

Auto-Merge

MR gerekli koşullar sağlandığında train üzerinden otomatik merge edilebilir. Developer pipeline sonuçlarını sürekli manuel takip etmek zorunda kalmaz. Merge Train etkin projede auto merge train mantığıyla uyumlu çalışmalıdır. Required review ve approval aynı şekilde uygulanır. Emergency bypass ayrı governance konusu olarak tutulmalıdır.

Merge Train'den Düşme

MR unmergeable hale geldiğinde train'den çıkarılabilir. Draft'a dönmesi veya conflict oluşması buna örnektir. Failed pipeline da MR'ın merge edilmesini engeller. Arkadaki MR'ların pipeline'ları yeni queue kombinasyonuna göre yeniden çalışabilir. System note düşme nedenini araştırmak için kullanılabilir.

Merge Queue ve Merge Train Neden Gereklidir?

Tek PR veya MR pipeline'ının başarılı olması onun birkaç dakika sonra target branch'e güvenle merge olacağını garanti etmez. Target bu sırada başka değişikliklerle ilerleyebilir. İki ayrı change ayrı ayrı doğru fakat birlikte uyumsuz olabilir. Queue ve train final merge sırasını CI doğrulamasıyla ilişkilendirir. Bu nedenle araçların temel amacı branch'i sıraya koymak değil stale integration sonucunu azaltmaktır.

İki PR/MR Tek Başına Başarılı Olabilir

A değişikliği current main üzerinde green olabilir. B değişikliği de aynı current main üzerinde green olabilir. Ancak ikisi aynı function veya contract'ı farklı varsayımlarla değiştiriyor olabilir. Text merge conflict oluşmadan runtime problem çıkabilir. Combined CI bu senaryoyu merge öncesinde yakalar.

Birlikte Merge Edilince Main Bozulabilir

Birinci change target'a girince ikinci change'in test ettiği base artık geçersiz hale gelir. İkinci PR doğrudan merge edilirse main bozulabilir. Bu durum yüksek merge hızında sıklaşır. Her geliştiricinin manuel rebase yapması verimsizdir. Queue integration sırasını otomatik yönetir.

Stale CI Result

CI sonucu belirli commit ve base state için geçerlidir. Target branch değiştiğinde bu sonuç yeni combined state'i temsil etmeyebilir. "Pipeline green" ifadesi hangi kod kombinasyonunun test edildiği bilinmeden yeterli değildir. Merged result pipeline veya merge group daha güçlü doğrulama sağlar. Stale result riskini azaltmak branch stability için önemlidir.

Integration Conflict

Integration conflict yalnızca Git conflict marker'ı değildir. API contract veya shared state değişiklikleri text conflict olmadan uyumsuz olabilir. Combined tests bu semantik çatışmayı yakalayabilir. Test coverage yoksa queue bile problemi bulamayabilir. Bu nedenle queue güçlü test suite ile birlikte değerlidir.

Target Branch'i Sürekli Green Tutmak

Main'in sürekli green olması deployment ve developer güvenini artırır. Bozuk main tüm ekibin pipeline ve feature çalışmalarını etkiler. Queue merge öncesi final kombinasyonu doğrulayarak risk azaltır. Failure yaşayan change sıradan çıkarılabilir. Bu yaklaşım yüksek throughput ile reliability arasında iyi denge sağlar.

GitHub Merge Queue vs GitLab Merge Train

GitHub Merge Queue ve GitLab Merge Train benzer problemi çözer ancak implementation ve CI entegrasyon ayrıntıları farklıdır. Her ikisi de yoğun target branch'te sıradaki değişiklikleri combined state üzerinden doğrulamayı hedefler. GitHub merge group required checks yaklaşımını kullanırken GitLab merge train merged results pipeline modelini genişletir. Parallelism ve enforcement seçenekleri kullanılan platform sürümü ve planına göre değişebilir. Araç seçiminde isimden çok repository throughput ve CI architecture uyumu değerlendirilmelidir.

Queue Mantığı

İki sistemde de değişikliklar merge sırasına alınır. Ön sıradaki değişiklik target'a girdikçe arkadaki validation güncel combined state'i temsil eder. Başarısız change normal merge akışını durdurmadan queue'dan çıkarılabilir. Author gerekli düzeltmeyi yapıp yeniden sıraya girebilir. Bu yapı manual merge koordinasyonunu azaltır.

Combined Validation

GitHub queue target branch ve queue'daki önceki değişikliklerle merge group oluşturabilir. GitLab Merge Train ise her MR'ı önündeki MR'ların combined değişiklikleriyle merged results pipeline üzerinden test eder. Amaç aynı stale base problemidir. Combined validation güçlü test suite yoksa yine yetersiz kalabilir. Integration test coverage özellikle önemlidir.

CI Entegrasyonu

GitHub Actions veya harici CI merge group event'ini doğru biçimde işleyecek şekilde yapılandırılmalıdır. GitLab tarafında merge request pipeline ve merged results pipeline gereksinimleri bulunur. CI yalnızca normal branch push event'ine bağlıysa queue davranışı eksik kalabilir. Setup production öncesi örnek queue değişiklikleriyle test edilmelidir. Required checks isim ve trigger değişiklikleri version control altında tutulmalıdır.

Parallelism

Parallel validation queue throughput'u artırır. GitLab Merge Train birden fazla train pipeline'ını parallel çalıştırabilir. GitHub Merge Queue da merge group ve queue settings üzerinden throughput kontrolü sağlar. Daha fazla parallelism daha fazla CI compute maliyeti yaratır. Test süresi ve runner capacity birlikte planlanmalıdır.

Enforcement

Queue özelliğinin bulunması herkesin onu kullanacağı anlamına gelmez. Branch policy bypass'a izin veriyorsa kullanıcı direct merge yapabilir. High traffic main branch'te queue zorunlu hale getirilebilir. Admin exception yalnızca break glass olarak tutulmalıdır. Enforcement davranışı kullanılan platformun güncel sürüm ve planında doğrulanmalıdır.

Operasyonel Kullanım

Küçük repository'de günde birkaç merge için queue ekstra CI maliyeti yaratabilir. Yüzlerce günlük merge alan monorepo'da ise ciddi stabilite avantajı sağlar. Queue wait time metric olarak izlenebilir. Failure nedeni flaky test ise önce test reliability geliştirilmelidir. Tool gerçek operasyon problemini çözüyorsa kullanılmalıdır.

Merge Queue Kullanmanın CI Maliyeti

Merge queue güvenilirlik sağlarken ek CI çalışması üretir. PR branch pipeline başarılı olsa bile queue combined state için tekrar test çalıştırabilir. Yoğun repository'de runner ihtiyacı önemli ölçüde artabilir. Path based testing ve akıllı test selection maliyeti azaltabilir. Queue throughput ile compute maliyeti birlikte ölçülmelidir.

Ek Pipeline Çalışmaları

Normal PR pipeline'a ek olarak queue validation çalışır. Bu tekrar gereksiz değildir, çünkü test edilen code state farklıdır. Ancak aynı pahalı job'ların tamamını tekrar çalıştırmak her zaman şart olmayabilir. Risk ve path bazlı seçilim yapılabilir. Artifact reuse build süresini azaltabilir.

Queue Throughput

Throughput bir saatte kaç değişikliğin güvenle merge edilebildiğini gösterir. Uzun pipeline queue'da bekleme oluşturur. Parallel runner kapasitesi artırılabilir. Flaky test failure throughput'u ciddi biçimde düşürür. Metric repository büyüklüğüne göre izlenmelidir.

Test Süresi

On dakikalık test ile iki saatlik test queue davranışını farklı etkiler. Test suite profiling yavaş job'ları bulabilir. Unit ve critical integration tests önceliklendirilebilir. Long running E2E test bazı değişikliklerde post merge çalışabilir. Risk bazlı karar gerekir.

CI Parallelism

Parallelism total pipeline duration'ı azaltabilir. Runner sayısı ve dependency limitleri sınır oluşturur. Fazla parallel job external service rate limit'lerini tetikleyebilir. Cost model dikkate alınmalıdır. Queue ayarları gerçek CI kapasitesine göre optimize edilmelidir.

Path-Based Testing

Monorepo'da frontend docs değişikliği için tüm backend integration suite çalıştırmak gereksiz olabilir. Changed path'e göre ilgili test seti seçilebilir. Dependency graph shared library etkisini doğru hesaba katmalıdır. Yanlış path mapping gerçek regression'ı kaçırabilir. Mapping code gibi test edilmelidir.

Test Selection

Test impact analysis değişiklikle ilişkili testleri seçmeye yardımcı olabilir. Critical smoke tests her durumda çalıştırılabilir. Selection sistemi probabilistic ise risk seviyesi dikkate alınmalıdır. Security veya shared core değişikliklerde full suite tercih edilebilir. Maliyet azaltılırken güven kaybedilmemelidir.

Monorepo'da PR/MR Yönetimi

Monorepo çok sayıda ekip ve component'i tek repository içinde birleştirdiği için PR yönetimi ayrı ölçek problemleri yaratır. Büyük CODEOWNERS dosyası reviewer yönlendirmesini sağlar. Path based review ve CI gereksiz iş yükünü azaltır. Bir değişiklik birden fazla domain'i etkiliyorsa çoklu approval gerekebilir. Merge queue yoğun main branch'i sürekli green tutmak için önemli hale gelir.

Büyük CODEOWNERS Dosyası

Yüzlerce path sahipliği zamanla yönetilmesi zor hale gelebilir. Pattern sırası ve override davranışı test edilmelidir. Takım isimleri organization yapısıyla uyumlu olmalıdır. Stale owner'lar düzenli temizlenmelidir. CODEOWNERS generation source of truth üzerinden otomatikleştirilebilir.

Path-Based Review

Değişen component'e göre yalnızca ilgili reviewer'lar çağrılabilir. Shared library değişikliği birden fazla takımı etkileyebilir. Dependency graph reviewer kapsamını genişletebilir. Her ekip her PR'ı görmek zorunda kalmaz. Review notification gürültüsü böylece azalır.

Path-Based CI

Changed path'e göre ilgili build ve test job'ları çalıştırılabilir. Monorepo pipeline süresi ciddi biçimde azalabilir. Shared config veya core package değişiklikleri geniş test setini tetiklemelidir. Dependency mapping yanlışsa regression kaçabilir. CI selection logic için test ve observability gerekir.

Çoklu Takım Approval

Bir PR frontend ve payment backend'i birlikte etkileyebilir. İki ayrı CODEOWNER approval gerekebilir. Cross cutting change büyükse parçalamak daha iyi olabilir. Approval rules doğru domain'leri kapsamalıdır. Takımlar arası review SLA ayrıca önem kazanır.

Build/Test Scope

Her PR tüm repository'yi build etmek pahalı olabilir. Affected project graph kullanılabilir. Cache ve artifact reuse süreyi azaltır. Critical integration suite belirli aralıklarla full çalıştırılabilir. Merge queue combined state için doğru test kapsamını seçmelidir.

Merge Queue

Monorepo yoğun merge hacmi nedeniyle stale base sorununa daha açıktır. Queue aynı main'e giden değişiklikları sıraya alır. Combined validation cross team regression riskini azaltır. Queue wait time önemli developer experience metriği haline gelir. CI kapasitesi repository büyümesiyle birlikte ölçeklenmelidir.

Fork Üzerinden Pull/Merge Request

Fork workflow external contributor'ın ana repository'ye doğrudan push yetkisi olmadan değişiklik önermesini sağlar. Contributor kendi fork'unda branch açar ve upstream repository'ye PR veya MR gönderir. Bu model açık kaynak projelerinde yaygındır. Fork kaynaklı CI untrusted code çalıştırdığı için secret güvenliği özellikle önemlidir. Maintainer approval olmadan privileged job veya secret erişimi verilmemelidir.

Open Source Contribution

Açık kaynak contributor repository'ye doğrudan write access olmadan katkı yapabilir. Contribution guide branch, test ve review beklentilerini açıklamalıdır. CI temel quality gate'leri otomatik kontrol eder. DCO veya CLA gerekiyorsa bot kontrolü eklenebilir. Maintainer review final merge sorumluluğunu taşır.

Fork → Branch → PR/MR

Contributor upstream repository'yi fork eder. Kendi fork'unda feature branch açıp commit ve push yapar. Ardından upstream target branch'e PR veya MR açar. Reviewer diff'i normal şekilde inceleyebilir. Source repository farklı olduğu için CI permission davranışı ayrıca önemlidir.

External Contributor

External contributor'ın repository iç secret'lara erişmemesi gerekir. İlk contribution'da maintainer onayı gerekebilir. Code Owners doğru domain reviewer'ı çağırabilir. Contributor feedback süreci açık ve saygılı olmalıdır. Merge sonrasında branch cleanup fork owner'ın kontrolünde kalabilir.

CI Secret Güvenliği

Fork'tan gelen kod kötü niyetli biçimde environment secret'larını okumaya çalışabilir. Privileged workflow'lar untrusted code üzerinde otomatik çalıştırılmamalıdır. Secret erişimi event türüne göre sınırlandırılmalıdır. Maintainer approval sonrası güvenli stage çalıştırılabilir. CI güvenlik modeli contribution guide'dan bağımsız teknik olarak enforce edilmelidir.

Untrusted Code Execution

Pull Request kodu repository owner tarafından henüz güvenilmeyen source'tur. Test çalıştırmak code execution anlamına gelebilir. Self hosted runner iç network'e erişebiliyorsa risk daha yüksektir. Ephemeral ve izole runner kullanılabilir. Fork pipeline threat model'in parçası olmalıdır.

Maintainer Approval

Maintainer external contribution'ı repository standardı ve security açısından değerlendirebilir. İlk contribution için manuel workflow approval gerekebilir. Review tamamlanmadan privileged deployment çalıştırılmamalıdır. Contributor'ın commit signing veya DCO kuralları varsa kontrol edilir. Merge history repository policy'ye göre squash veya rebase edilebilir.

Bot Tarafından Açılan PR/MR'lar

Dependency update bot'ları çok sayıda küçük PR üretebilir. Bu otomasyon security patch ve bakım hızını artırır fakat review gürültüsü de oluşturabilir. Patch, minor ve major update'ler farklı risk politikalarına sahip olabilir. Testleri green olan düşük riskli update'ler kontrollü auto merge edilebilir. Security update'leri ise öncelikli fakat yine doğrulanmış akıştan geçmelidir.

Dependabot

Dependabot dependency update PR'ları oluşturabilir. Version change ve security advisory bağlamı reviewer'a sunulabilir. Her update'i otomatik approve etmek doğru değildir. Lock file ve transitive dependency etkisi incelenmelidir. Güçlü CI düşük riskli patch update'leri otomatikleştirmeyi kolaylaştırır.

Renovate

Renovate dependency güncellemelerini configurable policy ile gruplayabilir veya zamanlayabilir. Repository update yoğunluğunu azaltmak için package grouping kullanılabilir. Major upgrade'ler ayrı PR olarak tutulabilir. Auto merge kuralı risk ve test güvenilirliğine göre uygulanmalıdır. Bot configuration dosyasının kendisi de review ile korunmalıdır.

Automated Dependency Update

Otomatik update dependency freshness'i artırır. Ancak her yeni version backward compatible değildir. Release note ve breaking change bilgisi gerektiğinde incelenmelidir. CI gerçek application behavior'ını yeterli düzeyde test etmelidir. Update bot'u security policy'nin yerine geçmez.

Auto-Approval Riskleri

Bot PR'ının otomatik olması güvenli olduğu anlamına gelmez. Compromised package veya malicious update supply chain riski taşıyabilir. Auto approval yalnızca düşük riskli ve trusted dependency policy'sinde kullanılmalıdır. Signed release veya checksum doğrulaması değerlendirilebilir. High impact dependency değişiklikleri human review almalıdır.

Patch/Minor/Major Güncelleme Politikası

Patch update otomatik merge için uygun aday olabilir. Minor update API behavior değiştirebilir ve daha güçlü test gerekebilir. Major upgrade genellikle manual migration review ister. Semantic versioning her package tarafından kusursuz uygulanmayabilir. Policy dependency türüne göre istisna içerebilir.

Security Update

Security update hızlı uygulanmalı fakat blind merge yapılmamalıdır. Vulnerability'nin gerçekten kullanılan path'i etkileyip etkilemediği değerlendirilebilir. Fix version test suite üzerinden doğrulanmalıdır. Production rollout metric ile izlenmelidir. Acil patch sonrası daha kapsamlı dependency upgrade follow up olarak planlanabilir.

AI Destekli Code Review

AI destekli reviewer syntax, pattern ve bazı yaygın hata sınıflarında yardımcı olabilir. Ancak domain requirement, organization policy ve production bağlamını insan kadar güvenilir anlayacağı varsayılmamalıdır. Security finding'lerde false positive ve false negative mümkündür. AI suggestion human reviewer'ın sorumluluğunu ortadan kaldırmaz. En iyi kullanım mekanik veya erken feedback katmanı olarak görülmesidir.

AI Reviewer'ın Rolü

AI reviewer ilk diff taramasında naming, duplication veya yaygın hata pattern'lerini işaretleyebilir. Author human review öncesinde bu feedback'i kullanabilir. Tool sonucu formal approval sayılmamalıdır. Sensitive code'un hangi servise gönderildiği security açısından değerlendirilmelidir. Kurumsal policy veri kullanım şartlarını açık biçimde belirlemelidir.

İnsan Reviewer'ın Yerine Geçer mi?

Hayır, özellikle riskli production değişikliklerinde insan reviewer gerekli kalır. Domain behavior ve business intent çoğu zaman issue ve tarihsel context gerektirir. AI doğru görünen fakat requirement'a aykırı code'u approve edebilir. İnsan reviewer trade off ve ownership sorumluluğunu taşır. Otomasyon destekleyici katman olarak kullanılmalıdır.

Syntax ve Pattern Kontrolü

Syntax error zaten compiler ve linter tarafından daha güvenilir yakalanabilir. AI tekrarlanan code smell veya missing error handling için ek sinyal sağlayabilir. Aynı konular static analysis ile enforce edilebiliyorsa deterministic araç tercih edilebilir. AI yorum yoğunluğu gereksiz notification oluşturmamalıdır. Faydalı finding oranı ölçülmelidir.

Security False Positive/Negative

AI bir kod parçasını riskli işaretleyip gerçekte problem olmayabilir. Daha tehlikelisi gerçek authorization açığını kaçırmasıdır. Bu nedenle security gate olarak tek başına kullanılmamalıdır. SAST ve human security review ile birlikte çalışabilir. Finding gerekçesi doğrulanabilir olmalıdır.

Domain Context Eksikliği

Model repository'nin tüm business geçmişini bilmeyebilir. Payment retry'nin neden özel davranması gerektiği koddan anlaşılmayabilir. Architecture decision record veya issue context yardımcı olsa da garanti sağlamaz. Domain owner review'u kritik kalır. AI yorumuna kör güven verilmemelidir.

Human Approval Sorumluluğu

Formal approval veren insan değişikliğin merge riskini kabul eder. AI önerisi bu sorumluluğu devralmaz. Reviewer tool feedback'ini değerlendirebilir fakat kendi judgement'ını kullanmalıdır. Kurum policy'si AI tarafından üretilen comment'in hukuki veya compliance statüsünü de belirlemelidir. Audit log human approval'ı açıkça göstermelidir.

Commit Signing ve Verified Changes

Commit signing commit'in belirli bir key veya identity tarafından oluşturulduğuna dair cryptographic doğrulama sağlar. GPG, SSH veya S/MIME gibi yöntemler kullanılabilir. Platform verified status ile signature doğrulamasını gösterebilir. Protected branch üzerinde signed commit zorunluluğu supply chain governance'ı güçlendirir. Ancak imzalı commit otomatik olarak güvenli veya doğru code anlamına gelmez.

Signed Commit

Signed commit commit metadata'sının private key ile imzalanmasını sağlar. Platform public key üzerinden doğrulama yapabilir. Identity trust modeli key sahipliğine bağlıdır. Key compromise durumunda revoke veya rotate süreci gerekir. CI bot'ları için ayrı signing identity kullanılmalıdır.

GPG

GPG commit signing için uzun süredir kullanılan yöntemlerden biridir. Developer public key platform hesabına eklenebilir. Private key güvenli saklanmalıdır. Key expiration ve rotation planlanabilir. Team onboarding dokümantasyonu signing kurulumunu kolaylaştırmalıdır.

SSH Signing

SSH key commit signing için de kullanılabilir. Developer zaten SSH key yönetiyorsa onboarding daha kolay olabilir. Signing key ile authentication key aynı olmak zorunda değildir. Kurum key rotation standardı belirlemelidir. Verified status platform davranışına göre kontrol edilmelidir.

S/MIME

S/MIME certificate tabanlı signing seçeneği sunabilir. Kurumsal PKI ile ilişkilendirilebilir. Certificate lifecycle operasyonu gerekir. Kullanıcı identity doğrulaması organization policy ile uyumlu olabilir. Platform desteği kullanılan deployment modelinde doğrulanmalıdır.

Verified Commit

Verified etiketi signature'ın platform tarafından tanınan identity ile doğrulandığını gösterir. Bu etiket code quality garantisi değildir. Reviewer yine diff'i incelemelidir. Unverified commit policy gereği merge'i engelleyebilir. Key ve account güvenliği birlikte önemlidir.

Protected Branch'te Signed Commit Zorunluluğu

GitHub rulesets signed commit requirement uygulayabilir. Bu rule contributor ve automation workflow'larını etkileyebilir. Squash merge behavior kullanılan signing ayarlarıyla test edilmelidir. Bot hesabı signing yapamıyorsa pipeline block oluşabilir. Policy production'a uygulanmadan önce tüm contribution yolları doğrulanmalıdır.

DCO ve CLA

DCO ve CLA özellikle açık kaynak contribution süreçlerinde katkının hukuki veya lisans bağlamını yönetmek için kullanılan mekanizmalardır. Developer Certificate of Origin contributor'ın katkıyı sunma hakkına sahip olduğunu beyan etmesine dayanır. Contributor License Agreement ise proje ile contributor arasında ayrı lisans sözleşmesi oluşturabilir. Hangi modelin gerekli olduğu projenin hukuki yapısına göre belirlenmelidir. Otomatik check PR sürecinde eksik imza veya onayı erken gösterebilir.

Developer Certificate of Origin

DCO contributor'ın commit üzerinde sign off kullanarak katkı hakkını beyan etmesine dayanır. Commit message içine Signed off by satırı eklenebilir. Bot her commit'in DCO şartını karşılayıp karşılamadığını kontrol edebilir. Rebase veya squash sürecinin sign off bilgisini nasıl etkilediği bilinmelidir. Contributor guide açık adımlar sunmalıdır.

Contributor License Agreement

CLA contributor'ın katkı için belirli lisans şartlarını kabul etmesini ister. Individual veya corporate CLA modelleri bulunabilir. İmzalanmamış contributor PR'ı merge öncesinde block edilebilir. Hukuki metin teknik ekip tarafından rastgele oluşturulmamalıdır. Organizasyonun gerçek lisans politikasına dayanmalıdır.

Open Source PR Sürecindeki Rolü

DCO veya CLA contribution acceptance gate haline gelebilir. Reviewer code'u approve etse bile hukuki check tamamlanmadan merge yapılmaz. Contributor hangi adımı eksik bıraktığını anlaşılır mesajla görmelidir. Gereksiz manuel takip otomasyonla azaltılabilir. Policy tüm contributor'lara tutarlı uygulanmalıdır.

Otomatik DCO Check

CI veya bot commit sign off bilgisini doğrulayabilir. Failure mesajı düzeltme komutunu açıkça gösterebilir. Rebase sonrası yeni commit tekrar kontrol edilmelidir. Maintainer bypass kullanımı hukuki policy'yi etkisiz bırakmamalıdır. Check hızlı çalıştığı için PR'ın erken aşamasında tetiklenebilir.

PR/MR ile Issue Yönetimi

Issue ile PR veya MR arasındaki bağ requirement traceability sağlar. Related issue değişikliğin neden yapıldığını gösterir. Closing keyword merge sonrasında task durumunu otomatik güncelleyebilir. Acceptance criteria reviewer için test ve code review bağlamı oluşturur. Issue, PR ve deployment zinciri production değişiklik geçmişini daha anlaşılır hale getirir.

Related Issue

Related issue PR description içinde görünür olmalıdır. Reviewer requirement detayına tek tıklamayla ulaşabilir. Bir PR birden fazla issue'yu etkiliyorsa scope'un fazla geniş olup olmadığı sorgulanabilir. Incident veya support ticket bağlantısı gerektiğinde eklenebilir. Hassas müşteri bilgisi public repository'ye taşınmamalıdır.

Closing Keyword

Closing keyword PR merge edildiğinde issue'yu otomatik kapatabilir. Manual task yönetimi azalır. Ancak partial implementation issue'yu erken kapatmamalıdır. Büyük issue altında birden fazla PR varsa child task yaklaşımı kullanılabilir. Otomasyon gerçek completion semantics ile uyumlu olmalıdır.

Acceptance Criteria

Acceptance criteria feature'ın hangi koşullarda tamamlanmış sayılacağını tanımlar. Reviewer code'u bu koşullara göre değerlendirebilir. QA test planı da aynı kriterlerden türetilebilir. Belirsiz acceptance criteria review tartışmasını uzatır. PR başlamadan önce issue kalitesi geliştirilmelidir.

Requirement Traceability

Requirement'tan commit ve deployment'a kadar ilişki kurulması regüle sistemlerde özellikle değerlidir. Audit sırasında neden değişiklik yapıldığı görülebilir. Otomatik linkler manual spreadsheet ihtiyacını azaltır. Requirement değişirse PR description da güncellenmelidir. Traceability bureaucracy değil karar geçmişidir.

Issue → PR/MR → Deployment Zinciri

Issue ihtiyacı temsil eder. PR veya MR teknik implementation ve review kaydını tutar. Merge commit source değişikliğini history'ye ekler. Deployment record hangi sürümün hangi environment'a çıktığını gösterir. Incident olduğunda bu zincir root cause araştırmasını hızlandırır.

PR/MR Labels Nasıl Kullanılmalı?

Label'lar PR veya MR'ları tür, risk ve durum açısından sınıflandırabilir. Feature, bug, security ve database gibi label'lar reviewer ve automation davranışını etkileyebilir. Needs Review veya Blocked workflow görünürlüğü sağlar. Ready to Merge otomasyon veya queue süreçleriyle ilişkilendirilebilir. Çok fazla label oluşturmak yerine gerçek karar veya raporlama değeri taşıyan sınıflar kullanılmalıdır.

Feature

Feature label yeni kullanıcı veya sistem davranışını gösterir. Release note automation bu label'ı kullanabilir. Feature flag ihtiyacı review template üzerinden sorulabilir. Product review gerekebilir. Label tek başına risk seviyesini belirlemez.

Bug

Bug label mevcut yanlış davranışı düzelten change'i işaretler. Regression test beklentisi buna göre uygulanabilir. Incident kaynaklı bug ayrıca severity label alabilir. Fix forward veya hotfix workflow farklı olabilir. Changelog bug fix'leri ayrı gruplayabilir.

Security

Security label hassas değişikliklerde özel reviewer veya pipeline tetikleyebilir. Public repository'de vulnerability detayını label ile gereksiz ifşa etmemek gerekir. Security team routing otomatik yapılabilir. Critical değişiklik iki approval isteyebilir. Label kullanım yetkisi kontrol edilebilir.

Database

Database label migration veya query impact change'i gösterir. DB owner otomatik reviewer olabilir. Migration test job'ları devreye girebilir. Deployment sequence review edilmelidir. Label path bazlı otomatik atanabilir.

Breaking Change

Breaking Change label consumer veya release davranışının değiştiğini açıkça gösterir. Extra approval ve migration plan gerekebilir. Release note otomasyonu major change olarak işleyebilir. API consumer ekipleri notification alabilir. Breaking değişiklik gizli kalmamalıdır.

Needs Review

Needs Review PR'ın author tarafından hazır olduğunu gösterir. Reviewer queue bu label üzerinden oluşturulabilir. Draft durumuyla otomatik senkronize edilebilir. CI başarısızsa label kaldırılabilir. Manual state drift oluşmaması için otomasyon tercih edilebilir.

Blocked

Blocked external dependency veya unresolved decision nedeniyle PR'ın ilerleyemediğini gösterir. Blocking nedeni description veya issue'da belirtilmelidir. Reviewer gereksiz yere zaman harcamaz. Uzun süre blocked kalan PR stale policy'ye girebilir. Owner düzenli takip etmelidir.

Ready to Merge

Ready to Merge tüm required review ve checks'in tamamlandığını gösterebilir. Merge queue automation label üzerinden tetiklenebilir. Platform zaten mergeability state sunuyorsa ek label gereksiz olabilir. Manuel label yanlış state'e düşebilir. Automation source of truth daha güvenlidir.

PR/MR Analytics ve Ölçülmesi Gereken Metrikler

PR analytics yalnızca geliştirici hızını ölçmek için kullanılmamalıdır. Open count, first review süresi, approval ve merge zamanı workflow bottleneck'lerini gösterebilir. Review iteration count büyük veya belirsiz PR problemini işaret edebilir. Revert rate ve conflict rate kalite ve branch drift hakkında ek bilgi sağlar. Metrikler bireysel performans sıralaması için kullanılırsa insanlar sistemi optimize etmek yerine rakamı optimize etmeye başlayabilir.

Open PR/MR Count

Açık PR sayısının sürekli artması review capacity sorununu gösterebilir. Draft ve ready değişiklikler ayrı sayılmalıdır. Stale PR'lar metric'i şişirebilir. Repository ve team bazında trend izlenebilir. Tek başına yüksek sayı kötü değildir, context gerekir.

Time to First Review

PR ready olduktan ilk anlamlı reviewer feedback'ine kadar geçen süredir. Developer wait time için güçlü sinyaldir. Draft zamanı hesaba katılmamalıdır. Timezone ve hafta sonu etkisi normalize edilebilir. Yüksek değer reviewer bottleneck araştırmasını tetikleyebilir.

Time to Approval

Ready state'ten gerekli approval'ların tamamlanmasına kadar geçen süreyi ölçer. Çok sayıda iteration requirement belirsizliği gösterebilir. High risk change doğal olarak daha uzun sürebilir. Risk kategorisiyle birlikte analiz edilmelidir. Hızlı approval her zaman iyi kalite anlamına gelmez.

Time to Merge

PR açılışından veya ready durumundan merge'e kadar geçen zamanı gösterir. Review, CI ve queue bekleme süreleri ayrı kırılımlarla daha anlamlıdır. Sadece toplam süre hangi bottleneck'in sorun olduğunu söylemez. Hotfix ve feature aynı benchmark'a konulmamalıdır. Cycle time trend olarak kullanılabilir.

Review Iteration Count

Kaç review ve re review turu gerektiğini gösterir. Yüksek sayı büyük PR veya eksik requirement işareti olabilir. Tek major architecture feedback çok sayıda küçük style comment'ten farklıdır. Comment severity ile birlikte analiz faydalıdır. Amaç sıfır iteration değil erken ve kaliteli feedback'tir.

PR/MR Size

Lines changed ve file count kaba boyut metric'leri sağlar. Generated code filtrelenmelidir. Büyük PR'ların time to review ve defect rate ile ilişkisi incelenebilir. Sert kişisel quota uygulanmamalıdır. Metric takım workflow iyileştirmesi için kullanılmalıdır.

Merge Conflict Rate

Conflict yaşayan PR oranı branch'lerin ne kadar uzun açık kaldığını gösterebilir. Monorepo veya hot file'larda doğal olarak daha yüksek olabilir. Kısa branch ve erken integration oranı azaltabilir. Büyük refactor dönemlerinde geçici artış normaldir. Conflict resolution sonrası defect rate de incelenebilir.

Revert Rate

Merge sonrası revert edilen değişiklik oranı kalite sinyalidir. Her revert kötü review anlamına gelmez. Product decision veya external dependency de neden olabilir. Revert reason kategorize edilmelidir. Yüksek risk alanlarında root cause review yapılabilir.

Code Review Kalite Metrikleri

Code review kalitesi yalnızca ne kadar hızlı approval verildiğiyle ölçülemez. Post merge defect, escaped defect ve security finding gibi sonuç metrikleri daha güçlü bağlam sağlar. Review comment resolution ve reviewer distribution süreç sağlığını gösterir. Review coverage kritik change'lerin gerçekten bağımsız kişi tarafından görülüp görülmediğini ölçebilir. Hiçbir metric tek başına bireysel performans değerlendirme aracı olmamalıdır.

Post-Merge Defect Rate

Merge sonrası kısa sürede bulunan defect oranı review ve test kalitesi hakkında sinyal verir. Change risk seviyesiyle normalize edilmelidir. Küçük docs change ile database migration aynı grupta değerlendirilmemelidir. Root cause review mu test mi requirement mı ayırmalıdır. Amaç suçlu bulmak değil quality gate'i geliştirmektir.

Escaped Defects

Escaped defect production'a ulaşan ve pre merge süreçte yakalanmayan hatadır. Severity ile birlikte izlenmelidir. Her incident sonrası hangi sinyalin eksik olduğu incelenebilir. Yeni alarm veya test gerektiği otomatik varsayılmamalıdır. Review checklist gerektiğinde güncellenebilir.

Review Comment Resolution

Blocking comment'lerin ne kadar sürede çözüldüğü re review bottleneck'ini gösterebilir. Çok sayıda nit comment kalite metriği olarak kullanılmamalıdır. Discussion tipi ayrıştırılmalıdır. Follow up issue'ların gerçekten kapatılıp kapatılmadığı izlenebilir. Metric davranış baskısı oluşturmamalıdır.

Security Finding Rate

PR sırasında bulunan security finding sayısı risk alanlarını gösterebilir. Daha fazla finding her zaman daha kötü kod anlamına gelmez, scan kapsamı artmış olabilir. Production security incident'larla karşılaştırma yapılabilir. Sensitive path'lerde review effectiveness değerlendirilebilir. False positive oranı ayrıca takip edilmelidir.

Review Coverage

Review coverage gerekli değişikliklerin kaçının gerçek human review aldığını gösterebilir. Bypass ve emergency merge'ler ayrı raporlanmalıdır. Code Owner approval oranı sensitive path için izlenebilir. Approval sayısı review derinliğini ölçmez. Outcome metric'lerle birlikte değerlendirilmelidir.

Reviewer Distribution

Review'ların yüzde sekseni tek kişiye gidiyorsa bus factor ve bottleneck riski vardır. Team içindeki dağılım görünür hale getirilebilir. Domain ownership nedeniyle belirli yoğunluk normal olabilir. Knowledge sharing planıyla zaman içinde daha dengeli yapı hedeflenebilir. Metric reviewer'ları cezalandırmak için kullanılmamalıdır.

PR/MR Hızını Körü Körüne Optimize Etmenin Riski

Time to merge'i tek başarı metriği yapmak reviewer'ları hızlı approval vermeye teşvik edebilir. Rubber stamp kültürü oluştuğunda formal gate var görünür fakat gerçek kalite kontrolü kaybolur. Riskli değişiklik ile küçük docs change aynı hedef sürede merge edilmeye çalışılmamalıdır. Hız ve kalite birlikte ölçülmelidir. Risk bazlı review workflow'u bu dengeyi kurmanın en pratik yollarından biridir.

Time to Merge Tek Başına Başarı Metriği Değildir

Bir PR'ın on dakikada merge olması harika veya tehlikeli olabilir. Değişikliğin riskini bilmeden süre anlamsızdır. Çok uzun süreler bottleneck gösterebilir fakat sıfıra yakın süre de review yapılmadığını gösterebilir. Defect ve revert rate ile birlikte değerlendirilmelidir. Metric target değil diagnostic araç olmalıdır.

Rubber-Stamp Approval

Reviewer diff'i okumadan approve verdiğinde formal policy değersiz hale gelir. Çok yüksek review load bunu teşvik edebilir. Approval süresinin aşırı kısa olması tek başına kanıt değildir fakat sinyal olabilir. Code Owner grupları yeterli kapasiteye sahip olmalıdır. Review kültürü manager baskısıyla hız odaklı hale getirilmemelidir.

Kalite ve Hız Dengesi

Küçük PR hem hızlı hem kaliteli review için en güçlü araçlardan biridir. Otomatik lint ve test mechanical workload'u azaltır. Human reviewer daha çok domain ve risk sorularına odaklanır. Merge queue stale integration maliyetini azaltır. Bu kombinasyon kaliteyi düşürmeden cycle time iyileştirebilir.

Risk Bazlı Review

Docs change bir reviewer ve hızlı CI ile ilerleyebilir. Payment logic iki reviewer ve security test gerektirebilir. Her PR'a aynı ağır policy uygulamak verimsizdir. Risk path, label veya change type ile otomatik sınıflandırılabilir. Exception kullanımı audit edilmelidir.

Risk Bazlı PR/MR Yönetimi

Risk bazlı yönetim değişikliğin potansiyel etkisine göre reviewer ve CI seviyesini ayarlar. Low risk change daha hafif akıştan geçebilir. High risk authentication veya production infrastructure değişikliği daha güçlü approval ve test gerektirir. Critical change separation of duties ve security review gibi ek kontroller alabilir. Bu model hem developer experience'i korur hem governance'i gerçek riskin olduğu yerde güçlendirir.

Low-Risk Change

Docs, comment veya küçük internal refactor düşük riskli olabilir. Minimum bir reviewer yeterli olabilir. Hızlı unit ve lint kontrolleri çalıştırılabilir. Sensitive path'e dokunmadığı doğrulanmalıdır. Auto merge kullanılabilir.

Medium-Risk Change

Normal feature veya bug fix orta risk kategorisine girebilir. Domain reviewer ve full test suite gerekli olabilir. Deployment sonrası metric izlenmelidir. Breaking API davranışı yoksa ekstra approval gerekmeyebilir. Feature flag rollout riskini azaltabilir.

High-Risk Change

Authentication, payment veya database migration high risk olabilir. İki reviewer veya domain plus security approval gerekebilir. Extended integration ve security checks çalıştırılabilir. Rollback planı zorunlu tutulmalıdır. Merge queue final combined validation sağlayabilir.

Critical Change

Production IAM veya cryptographic trust değişikliği critical sınıfa girebilir. Separation of duties uygulanabilir. Security ve platform owner approval birlikte gerekebilir. Manual deployment window veya staged rollout planlanabilir. Audit kayıtları daha ayrıntılı tutulabilir.

Risk Seviyesine Göre Reviewer Sayısı

Low risk bir reviewer ile ilerleyebilir. Medium risk domain expert gerektirebilir. High risk iki bağımsız approval isteyebilir. Critical change özel approver grubu kullanabilir. Sayı gerçek uzmanlık olmadan artırılmamalıdır.

Risk Seviyesine Göre CI Testleri

Low risk docs change full E2E suite çalıştırmayabilir. Shared core library geniş regression test tetikleyebilir. Payment change security ve integration test alabilir. IaC change policy scan ve plan doğrulaması gerektirir. Test selection risk metadata ile otomatik yönetilebilir.

High-Risk Değişiklikler Nelerdir?

High risk change kullanıcı erişimi, para, veri bütünlüğü veya production altyapısı üzerinde geniş etki yaratabilecek değişikliktir. Authentication, authorization ve payment en tipik örneklerdir. Database migration ve IAM hataları geniş blast radius oluşturabilir. Cryptography ve audit logging compliance açısından özel önem taşır. Bu path'ler CODEOWNERS ve risk bazlı CI politikalarıyla otomatik olarak daha güçlü review akışına yönlendirilebilir.

Authentication

Authentication kullanıcının kim olduğunu doğrulayan mekanizmayı etkiler. Session veya token değişikliği geniş kullanıcı kitlesini etkileyebilir. Security review gereklidir. Failure ve bypass senaryoları test edilmelidir. Rollback kullanıcı session'ları üzerindeki etkiyi dikkate almalıdır.

Authorization

Authorization kullanıcının ne yapabileceğini belirler. Küçük condition hatası privilege escalation yaratabilir. Unit test role matrix'i kapsamalıdır. Human reviewer business permission modelini anlamalıdır. Sensitive path security owner'a yönlendirilmelidir.

Payment

Payment değişikliği maddi sonuç yaratabilir. Duplicate charge ve idempotency kritik konulardır. Rounding, currency ve retry davranışı test edilmelidir. İki reviewer veya domain approval kullanılabilir. Deployment sonrası transaction failure metric'i izlenmelidir.

Database Migration

Migration data loss veya prolonged lock oluşturabilir. Büyük tablo değişikliği production availability'yi etkileyebilir. Backward compatibility ve rollback planı zorunlu olmalıdır. Database owner review'u faydalıdır. Migration sonucu gözlenebilir olmalıdır.

IAM

IAM değişikliği sistem veya kullanıcı yetkilerini genişletebilir. Wildcard permission ciddi risk taşır. Least privilege review edilmelidir. Security approval gerekebilir. Audit log erişim değişikliğini kaydetmelidir.

Production Infrastructure

Load balancer, network ve cluster değişiklikleri geniş blast radius taşır. Plan veya diff reviewer'a açık sunulmalıdır. Staged rollout mümkünse tercih edilir. Emergency rollback yolu hazır olmalıdır. Platform owner approval kullanılabilir.

Cryptography

Cryptographic algorithm veya key management değişikliği uzmanlık gerektirir. Kendi cryptographic primitive'ini yazmak yerine doğrulanmış library kullanılmalıdır. Backward compatibility encrypted data erişimini etkileyebilir. Security specialist review önemlidir. Key rotation ve recovery planı bulunmalıdır.

Audit Logging

Audit logging değişikliği compliance ve incident investigation yeteneğini etkiler. Event'in sessizce log dışı kalması risklidir. Hassas veri loglanmamalıdır. Log integrity ve retention gereksinimleri gözden geçirilmelidir. Security veya compliance owner review'a dahil olabilir.

Hotfix PR/MR Süreci

Hotfix production'daki acil problemi hızla azaltmayı hedefler. Süreç normal workflow'dan daha hızlı olabilir fakat kontrolsüz direct push'a dönüşmemelidir. Minimum review ve hızlandırılmış kritik CI korunmalıdır. Break glass gerekiyorsa neden kullanıldığı audit edilmelidir. Incident sonrasında değişiklik tam review'dan geçirilip eksik test ve documentation tamamlanmalıdır.

Normal Süreçten Ne Kadar Ayrılmalı?

Yalnızca gerçek aciliyet nedeniyle yavaş aşamalar kısaltılmalıdır. Security ve correctness kontrolü tamamen kaldırılmamalıdır. Full E2E yerine critical smoke test çalıştırılabilir. Reviewer on call kişi olabilir. Emergency policy önceden yazılı olmalıdır.

Minimum Review

En az bir bağımsız reviewer hotfix'i görmelidir. Critical domain ise uygun uzman seçilmelidir. Review hızlı fakat gerçek olmalıdır. Scope mümkün olduğunca küçük tutulmalıdır. Unrelated refactor hotfix'e eklenmemelidir.

Hızlandırılmış CI

Critical unit ve integration tests hızlı pipeline'da çalıştırılabilir. Uzun test suite post merge devam edebilir. Security scan riskli code path'te korunmalıdır. Test selection önceden hazırlanmış olmalıdır. Incident anında hangi job'ın gerekli olduğu tartışılmamalıdır.

Emergency Approval

Normal iki approval yerine önceden tanımlı emergency approver tek onay verebilir. Kullanım nedeni kaydedilmelidir. Emergency approval günlük convenience yöntemi olmamalıdır. Sonradan normal reviewer değişikliği tekrar incelemelidir. Audit düzenli olarak emergency kullanım sıklığını izlemelidir.

Break-Glass

Break glass yalnızca normal süreç hizmeti yeterince hızlı kurtaramadığında kullanılmalıdır. Access süresi sınırlı tutulmalıdır. Kullanım otomatik olarak güvenlik veya incident kanalına bildirim gönderebilir. Merge sonrası yetki geri alınmalıdır. Postmortem neden gerekli olduğunu değerlendirmelidir.

Sonradan Tam Review

Incident sona erdikten sonra hotfix normal review standardıyla incelenmelidir. Eksik regression test eklenebilir. Hızlı workaround sürdürülebilir çözüm değilse follow up oluşturulmalıdır. Documentation ve runbook güncellenebilir. Emergency process'in kalıcı technical debt üretmesine izin verilmemelidir.

Merge Sonrası Hata Çıkarsa Ne Yapılmalı?

Merge sonrası hata çıkması review sürecinin başarısız olduğu anlamına gelmek zorunda değildir. Hiçbir quality gate tüm riskleri sıfırlayamaz. İlk hedef kullanıcı etkisini azaltmaktır. Revert, fix forward, hotfix veya feature flag disable seçenekleri değerlendirilebilir. Incident ile ilgili PR veya MR arasında bağlantı kurmak sonraki öğrenme sürecini güçlendirir.

Revert

Revert problemli değişikliğin etkisini hızlı geri alabilir. Değişiklik atomic ve database açısından reversible ise güçlü seçenektir. Revert de PR ve CI üzerinden geçebilir. Emergency durumda hızlandırılmış workflow uygulanabilir. Sonrasında root cause ayrı fix ile ele alınmalıdır.

Fix-Forward

Fix forward geri almak yerine yeni düzeltmeyle ilerlemeyi ifade eder. Database veya data migration geri alınamıyorsa daha güvenli olabilir. Fix küçük ve neden açık ise hızlı uygulanabilir. Riskli workaround yeni problem üretmemelidir. Deployment sonrası monitoring şarttır.

Hotfix

Hotfix production incident için hızlı ayrı PR olabilir. Scope yalnızca incident etkisini azaltmaya odaklanmalıdır. Minimum review ve critical tests korunmalıdır. Sonradan full review yapılmalıdır. Incident ID PR'a bağlanmalıdır.

Feature Flag Disable

Problem yeni feature'dan kaynaklanıyorsa flag kapatmak en hızlı mitigation olabilir. Code deploy yerinde kalır fakat kullanıcı path'i devre dışı olur. Flag rollback kadar güvenli tasarlanmış olmalıdır. State veya migration etkisi devam edebilir. Root cause yine çözülmelidir.

Incident Oluşturma

Kullanıcı etkisi belirli seviyeyi aşıyorsa formal incident kaydı açılmalıdır. Timeline ve mitigation adımları burada tutulabilir. Problemli PR linklenmelidir. Deployment ve metric değişimi ilişkilendirilebilir. Postmortem review ve CI süreçlerini geliştirebilir.

PR/MR ile Incident Arasında Bağlantı Kurmak

Incident hangi change'in problemi tetiklediğini gösteriyorsa PR iki yönlü linklenebilir. Reviewer'lar hangi sinyalin kaçırıldığını daha sonra inceleyebilir. Eksik test veya rollback planı güncellenebilir. Aynı tür değişiklikler için risk sınıfı yükseltilebilir. Öğrenme repository sürecine geri beslenmelidir.

Revert PR/MR Nasıl Yönetilir?

Revert production history'den değişikliği silmez, ters etkili yeni commit oluşturur. Original change açıkça belirlenmelidir. Revert kendi PR veya MR'ı üzerinden CI ve review alabilir. Database değişikliklerinde ters işlem veri kaybı yaratabileceği için çok daha dikkatli olunmalıdır. Revert sonrası asıl feature branch tekrar merge edilmek istenirse history davranışı ayrıca planlanmalıdır.

Original Change'i Belirlemek

Önce incident'a neden olan gerçek commit veya PR doğrulanmalıdır. Yanlış change'i revert etmek kullanıcı etkisini artırabilir. Deployment timeline yardımcı olur. Birden fazla change aynı anda çıktıysa bisect veya telemetry kullanılabilir. Revert kararı varsayıma değil mümkün olduğunca kanıta dayanmalıdır.

Revert Commit

Git revert original commit'in ters değişikliğini yeni commit olarak ekler. Shared history rewrite edilmez. Merge commit revert davranışı ayrıca parent seçimi gerektirebilir. Commit mesajı original change'i referans etmelidir. CI çalıştırılmalıdır.

Revert PR/MR

Revert branch açılıp normal PR veya MR oluşturulabilir. Description incident ve original PR linkini içermelidir. Review acil durumda hızlandırılabilir. CI failure göz ardı edilmemelidir. Merge sonrası production metric normalleşmesi doğrulanmalıdır.

CI Validation

Revert eski kodu geri getiriyor görünse bile current main farklı olabilir. Bu nedenle yeni combined state test edilmelidir. Integration test önemlidir. Queue kullanılıyorsa revert PR da queue'dan geçebilir. Emergency incident severity'sine göre hızlı path uygulanabilir.

Database Değişikliklerinde Revert Riski

Dropping column veya irreversible data transformation kolayca geri alınamaz. Application code revert eski schema'yı bekleyebilir. Expand contract model bu riski azaltır. Revert yerine fix forward gerekebilir. Database owner incident kararına dahil edilmelidir.

Stale PR/MR Yönetimi

Uzun süre açık kalan PR'lar target branch drift ve unutulan iş yükü oluşturur. Otomatik reminder author'ı aksiyon almaya yönlendirebilir. Stale label belirli süre hareketsiz değişiklikleri görünür hale getirir. Otomatik close kullanılacaksa açık uyarı ve istisna mekanizması bulunmalıdır. Kritik veya blocked işler sırf süre doldu diye sessizce kapanmamalıdır.

Uzun Süre Açık Kalan Değişiklikler

Haftalarca açık feature branch review maliyetini artırır. Requirement bu sürede değişmiş olabilir. Author değişikliğin hâlâ gerekli olup olmadığını doğrulamalıdır. Büyük PR küçük parçalara bölünebilir. Stale metric team process problemini gösterebilir.

Target Branch Drift

Main ilerledikçe stale branch eski architecture ve dependency state'i üzerinde kalır. Merge conflict riski yükselir. CI eski base ile green olabilir. Rebase veya update gerekir. Çok büyük drift'te değişikliği yeniden tasarlamak daha doğru olabilir.

Otomatik Reminder

Bot belirli süre activity olmayan PR'a reminder bırakabilir. Author ve reviewer notification alabilir. Reminder sürekli spam üretmemelidir. Draft ve blocked PR'lar farklı süre kullanabilir. Response yoksa escalation veya close aşamasına geçilebilir.

Stale Label

Stale label repository backlog'unu filtrelemeyi kolaylaştırır. Otomatik olarak belirli inactivity süresinde atanabilir. Yeni comment veya commit label'ı kaldırabilir. Critical security PR stale olmamalıdır. Label yalnızca housekeeping sinyalidir.

Otomatik Close Politikası

Uzun süre yanıt alınmayan PR otomatik kapatılabilir. Contributor'a önceden notice verilmelidir. Work in progress veya roadmap item istisna olabilir. Kapanmak commit'leri silmez. Gerektiğinde PR yeniden açılabilir veya yeni branch oluşturulabilir.

Owner'a Eskalasyon

Kritik change uzun süre bekliyorsa author manager'ına değil önce service owner'a görünür escalation yapılabilir. Reviewer bottleneck araştırılmalıdır. Security patch gibi önemli işler daha hızlı kanal kullanabilir. Escalation blame amacı taşımamalıdır. Process kapasite problemini çözmeye odaklanmalıdır.

Merge Sonrası Branch Temizliği

Kısa ömürlü feature branch merge sonrasında genellikle gerekli değildir. Otomatik source branch deletion repository görünümünü temiz tutar. Remote branch sayısının kontrolsüz büyümesi branch listelerini kullanışsız hale getirebilir. Protected release ve long lived branch'ler retention policy dışında tutulur. Branch cleanup repository history'sini silmez ve merge edilen commit'ler target history'de kalır.

Source Branch'i Otomatik Silmek

Platform merge sonrası source branch'i otomatik silebilir. Developer manual cleanup yapmak zorunda kalmaz. Stack workflow'da üst branch dependency'si varsa davranış kontrol edilmelidir. Fork branch deletion farklı repository owner'ına bağlı olabilir. Protected source branch otomatik silinmemelidir.

Remote Branch Cleanup

Eski remote branch'ler düzenli raporlanabilir. Son activity tarihi kullanılabilir. Merge edilmemiş branch otomatik silinmeden önce owner uyarılmalıdır. Backup amacıyla branch saklamak Git tag veya release mekanizmasının yerine geçmemelidir. Cleanup policy dokümante edilmelidir.

Protected Long-Lived Branch'ler

main, release veya maintenance branch uzun süre yaşamak üzere tasarlanabilir. Bu branch'ler deletion protection altında olmalıdır. Direct push ve force push politikası ayrı uygulanır. Owner ve kullanım amacı belgelenmelidir. Artık desteklenmeyen release branch kontrollü biçimde archive edilebilir.

Branch Retention Politikası

Feature branch için merge sonrası immediate deletion uygulanabilir. Unmerged inactive branch için örneğin belirli süre review penceresi tanımlanabilir. Regulatory ihtiyaca göre retention değişebilir. Branch yerine commit ve tag geçmişi daha güvenilir kayıt mekanizmasıdır. Policy repository türüne göre esnek tutulmalıdır.

GitHub Repository İçin Önerilen Merge Policy

Production GitHub repository için iyi bir başlangıç main branch'i korumak ve normal direct push'u kapatmaktır. Minimum bir bağımsız approval ve CODEOWNERS sensitive path'lerde gerekli tutulabilir. Required CI checks ve conversation resolution merge öncesi kaliteyi artırır. Stale approval dismissal yeni commit riskini azaltır. Yoğun main branch'te Merge Queue ve merge sonrası automatic branch deletion süreç verimliliğini yükseltebilir.

main Protected

main branch protection veya uygun ruleset kapsamına alınmalıdır. Deletion ve force push sınırlandırılabilir. Required PR workflow uygulanabilir. Bypass yalnızca kontrollü rollerle sınırlanmalıdır. Rule değişiklikleri audit edilmelidir.

Direct Push Kapalı

Normal developer main'e doğrudan push yapmamalıdır. Tüm değişiklik PR üzerinden ilerler. Automation account gerekiyorsa özel istisna tanımlanabilir. İstisna minimum permission ile çalışmalıdır. Direct push olayları düzenli audit edilebilir.

Minimum Approval

En az bir approving review çoğu application repository için iyi başlangıçtır. High risk path iki veya özel owner approval isteyebilir. Author kendi approval'ına güvenmemelidir. Reviewer son diff'i görmelidir. Approval policy stale review davranışıyla birlikte düşünülmelidir.

CODEOWNERS

Sensitive ve domain specific path'ler Code Owner'a atanmalıdır. Required review from Code Owners etkinleştirilebilir. CODEOWNERS dosyasının kendisi owner tarafından korunmalıdır. Team based ownership bottleneck riskini azaltır. Stale owner'lar düzenli güncellenmelidir.

Required CI Checks

Build, unit test ve critical integration checks required olabilir. Security scan risk seviyesine göre gate olabilir. Flaky job required yapılmamalıdır. Check source ve isimleri kontrollü yönetilmelidir. Merge queue event'leri CI tarafından desteklenmelidir.

Conversation Resolution

Blocking review thread'ler merge öncesinde çözülmelidir. Required conversation resolution bunu enforce edebilir. Suggestion yorumlar follow up ile kapatılabilir. Reviewer severity standardı kullanmalıdır. Author yalnızca düğmeye basarak gerçek problemi kapatmamalıdır.

Stale Review Dismissal

Yeni commit geldiğinde eski approval geçersiz hale getirilebilir. Böylece reviewer görmediği kodu formal olarak approve etmiş sayılmaz. Küçük fix'lerde re review yükü oluşabilir. High risk repository'lerde güvenlik avantajı daha büyüktür. Ekip review ready olmadan approval istememelidir.

Merge Queue

Yüksek merge hacminde Merge Queue kullanılabilir. PR latest target ve queue state ile required checks'ten geçer. Manual branch update ihtiyacı azalır. Main stability artar. Queue wait ve failure metric'leri izlenmelidir.

Automatic Branch Deletion

Merge sonrası head branch otomatik silinebilir. Repository branch listesi temiz kalır. Stacked workflow behavior önceden test edilmelidir. Long lived branch'ler koruma altında kalır. Feature branch history commit üzerinden korunur.

GitLab Project İçin Önerilen Merge Policy

Production GitLab projesinde default branch protected tutulmalıdır. Required approval rules ve Code Owner approval riskli path'leri korur. Self approval ve committer approval davranışı kurum politikasına göre sınırlandırılabilir. Pipeline success ve resolved discussion merge şartı yapılabilir. Yoğun projelerde Merge Train ve source branch deletion güvenli entegrasyonla operasyon temizliğini birlikte sağlayabilir.

Protected Default Branch

Default branch doğrudan push'a karşı korunmalıdır. Merge permission belirli rol veya automation'a verilebilir. Force push kapalı tutulmalıdır. Code Owner approval gerekiyorsa branch rule içinde etkinleştirilmelidir. Rule değişiklikleri review edilmelidir.

Required Approval Rules

En az bir bağımsız approval temel policy olabilir. Database ve security için ayrı rule eklenebilir. Target protected branch'e göre farklı kural uygulanabilir. Rule sayısı developer experience'i bozmayacak düzeyde tutulmalıdır. Approval eligibility doğru ekipleri kapsamalıdır.

Code Owner Approval

Sensitive path değiştiğinde Code Owner approval zorunlu tutulabilir. CODEOWNERS doğru dosya pattern'lerini kapsamalıdır. Owner grupları yeterli review kapasitesine sahip olmalıdır. Push permission bypass riskine dikkat edilmelidir. Ownership değişiklikleri ayrıca korunmalıdır.

Prevent Self-Approval

Author'ın kendi MR'ını required approval olarak kullanması engellenebilir. Separation of duties güçlenir. Commit atan kişilerin approval davranışı da risk modeline göre sınırlandırılabilir. Küçük ekiplerde alternatif approver planlanmalıdır. Emergency istisna audit edilmelidir.

Pipeline Success Requirement

Pipeline green olmadan merge yapılmamalıdır. Critical test ve security jobs required olmalıdır. Merged results pipeline integration riskini azaltabilir. Flaky test'ler hızla sahiplenilmelidir. Merge Train kullanılan projede pipeline config train behavior'ını desteklemelidir.

Resolved Discussions

Blocking discussion'ların çözülmesi merge koşulu yapılabilir. Reviewer severity standardı kullanmalıdır. Non blocking improvement follow up issue'ya taşınabilir. Author discussion'ı neden çözdüğünü gerektiğinde açıklamalıdır. Review history audit için korunur.

Merge Train

Yoğun default branch'te Merge Train kullanılabilir. MR önündeki değişikliklerle combined state üzerinde test edilir. Parallel pipeline throughput sağlar. Failure yaşayan MR train'den çıkarılır. Runner kapasitesi merge hacmine göre planlanmalıdır.

Automatic Source Branch Deletion

Merge edilen feature branch otomatik silinebilir. Repository daha düzenli kalır. Long lived protected branch'ler istisnadır. Stack kullanılıyorsa dependent branch davranışı kontrol edilmelidir. Cleanup policy ek manual iş yükünü azaltır.

Küçük Ekipler İçin Basit PR/MR Politikası

Küçük ekiplerin enterprise seviyesinde onlarca approval rule ile başlaması gerekmez. Protected main, en az bir reviewer ve green CI güçlü temel oluşturur. PR'ları küçük tutmak review süresini azaltır. Squash merge history'yi sadeleştirebilir. Merge sonrası branch cleanup otomasyonu minimum operasyon yüküyle düzenli repository sağlar.

En Az Bir Reviewer

Author dışında en az bir kişi değişikliği görmelidir. Reviewer domain hakkında yeterli bağlama sahip olmalıdır. Küçük ekipte herkes tüm repository'yi zamanla öğrenebilir. Review SLA birkaç saat veya aynı gün olabilir. Self approval normal workflow olmamalıdır.

Green CI

Unit test, build ve lint minimum required check olabilir. CI başarısızken merge yapılmamalıdır. Flaky test sorunları hemen ele alınmalıdır. Pipeline kısa tutulmalıdır. Developer review istemeden önce lokal temel testleri çalıştırmalıdır.

Küçük PR

Her PR tek amaca hizmet etmelidir. Büyük feature feature flag ile parçalara ayrılabilir. Küçük diff hızlı review edilir. Conflict daha az olur. Revert daha kolaydır.

Squash Merge

Küçük ekipte squash history'yi temiz tutar. PR başlığı final commit mesajı olur. Conventional title kullanılabilir. Her feature tek commit halinde revert edilebilir. Büyük PR açma alışkanlığı squash ile gizlenmemelidir.

Protected Main

Main'e direct push kapatılmalıdır. Force push engellenmelidir. Required PR ve CI uygulanmalıdır. Emergency bypass yalnızca gerçekten gerektiğinde kullanılmalıdır. Repository ayarları ekip değiştikçe korunmalıdır.

Otomatik Branch Cleanup

Merge sonrası source branch otomatik silinebilir. Manuel temizlik ihtiyacı azalır. Kısa branch workflow desteklenir. Eski branch listesi kalabalıklaşmaz. Release branch'ler ayrı korunur.

Büyük Kurumlar İçin PR/MR Governance

Büyük kurumlarda yüzlerce repository'nin her birini manuel policy ile yönetmek sürdürülemez. Central ruleset veya group organization policy ortak minimum standardı oluşturabilir. CODEOWNERS domain review'u dağıtırken security approval yüksek riskli path'lerde devreye girer. Separation of duties, audit trail ve signed commits compliance gereksinimlerini destekler. Merge Queue veya Merge Train yüksek throughput repository'lerde main stability için güçlü kontrol sunar.

Central Ruleset

Merkezi ruleset minimum branch protection standardını birçok repository'ye uygulayabilir. Teams kendi repository'sinde ek kural tanımlayabilir. Baseline direct push ve required CI olabilir. Exception süreci belgelenmelidir. Policy drift otomatik raporlanmalıdır.

Group/Organization Policy

Organization seviyesinde approval, security ve repository ayarları standardize edilebilir. Yeni repository otomatik doğru baseline ile oluşturulmalıdır. Legacy repository migration planı gerekir. Policy platform plan özelliklerine göre uygulanabilir. Central governance ekip ihtiyaçlarını tamamen görmezden gelmemelidir.

CODEOWNERS

Domain ownership monorepo ve çok ekipli repository'lerde kritiktir. Team based pattern tercih edilebilir. Ownership source of truth service catalog ile entegre olabilir. CODEOWNERS dosyası korunmalıdır. Reviewer bottleneck metric'leri izlenmelidir.

Security Approval

Security approval yalnızca high risk change'lerde zorunlu tutulmalıdır. Path ve risk metadata otomatik routing sağlar. Security team tüm PR'ları manuel incelemek zorunda kalmaz. Critical finding merge'i block eder. Emergency bypass audit edilir.

Separation of Duties

Author, approver ve production deploy yetkileri riskli sistemlerde ayrılabilir. Finance veya regulated workload daha güçlü kontrol isteyebilir. Automation identity de bu modele dahil edilmelidir. Tek admin hesabına bağlı süreçten kaçınılmalıdır. Access review düzenli yapılmalıdır.

Audit Trail

PR review, approval, merge ve bypass olayları kayıt altında kalmalıdır. Kim hangi değişikliği onayladı görülebilmelidir. Repository policy değişiklikleri de audit edilmelidir. Retention compliance ihtiyacına göre belirlenmelidir. Audit data yalnızca incident sırasında aranacak pasif kayıt olmamalıdır.

Signed Commits

Signed commit source identity doğrulamasını güçlendirir. Central policy critical repository'lerde zorunlu kılabilir. Developer onboarding key setup içermelidir. Bot ve CI identities ayrı yönetilmelidir. Key revocation süreci bulunmalıdır.

Merge Queue/Train

Yüksek throughput repository'lerde queue integration conflict riskini azaltır. Combined CI stale base sorununu çözmeye yardımcı olur. Runner capacity planlanmalıdır. Queue latency engineering productivity metriği olarak izlenebilir. Flaky test'ler öncelikli teknik borç haline gelir.

Örnek Production-Ready PR/MR Akışı

Production ready PR akışı issue ile başlar ve deployment gözlemiyle tamamlanır. Küçük branch ve draft aşaması değişikliği erken görünür kılar. Author self review yaptıktan sonra CI ve security checks çalışır, CODEOWNERS doğru reviewer'ı yönlendirir ve human review gerçekleşir. Required approvals tamamlandıktan sonra queue veya train final combined validation yapabilir. Merge sonrasında deployment izlenir ve source branch temizlenir.

1. Issue Oluşturulur

Problem ve acceptance criteria issue içinde tanımlanır. Scope açık olmalıdır. Riskli alanlar erkenden işaretlenebilir. Owner belirlenir. PR daha sonra issue'ya bağlanır.

2. Feature Branch Açılır

Main'in güncel halinden kısa ömürlü branch oluşturulur. Branch adı task ile ilişkilendirilebilir. Tek iş amacı hedeflenir. Uzun branch planlanmaz. Feature flag gerekirse baştan düşünülür.

3. Küçük Commit'ler Yapılır

Değişiklik anlamlı adımlara bölünür. Commit mesajları niyeti açıklar. Debug code commit edilmemelidir. Test değişiklikle birlikte yazılır. Local checks düzenli çalıştırılır.

4. Draft PR/MR Açılır

Erken CI ve feedback için draft açılır. Description problem ve yaklaşımı anlatır. Architecture sorusu varsa reviewer erkenden çağrılır. Merge edilmemesi gerektiği açıktır. Work in progress görünür hale gelir.

5. Author Self-Review Yapar

Author diff'i baştan sona okur. Gereksiz dosya ve debug kodlarını temizler. Testleri çalıştırır. Description'ı günceller. Riskli bölümleri reviewer'a işaretler.

6. CI ve Security Kontrolleri Çalışır

Build, tests, lint ve type check tamamlanır. Security scanners ilgili riskleri kontrol eder. Failed pipeline düzeltilmeden formal review istenmez. Flaky result araştırılır. Required checks görünür olur.

7. CODEOWNERS Reviewer Atar

Değişen path'ler doğru domain owner'ı tetikler. Sensitive path security reviewer ekleyebilir. Reviewer workload gerekiyorsa dengelenir. Owner bulunamıyorsa repository metadata düzeltilir. Manual reviewer seçimi gerektiğinde eklenebilir.

8. Human Code Review Yapılır

Reviewer issue ve description'ı okur. Diff correctness, maintainability ve risk açısından incelenir. Testler değerlendirilir. Blocking ve suggestion yorumları ayrılır. Review summary paylaşılır.

9. Blocking Discussion'lar Çözülür

Author gerekli code change'leri yapar. Reviewer cevapları ve yeni diff'i kontrol eder. Non blocking konular follow up issue'ya taşınabilir. Blocking thread açık kalmaz. CI tekrar çalışır.

10. Required Approvals Tamamlanır

Minimum reviewer onayı alınır. Sensitive path varsa Code Owner approval tamamlanır. High risk change ek security veya database approval alabilir. Yeni commit approval'ı resetlemişse re review yapılır. Final diff bağımsız kişi tarafından görülür.

11. Merge Queue/Train'e Eklenir

Yoğun target branch'te change queue veya train'e alınır. Sıra otomatik yönetilir. Author sürekli rebase yapmak zorunda kalmaz. Combined state validation hazırlanır. Queue bypass normal workflow değildir.

12. Combined CI Başarılı Olur

Change latest target ve gerekli önceki queue değişiklikleriyle test edilir. Integration conflict varsa merge gerçekleşmez. Flaky failure araştırılır. Security checks gerektiğinde combined state üzerinde çalışır. Green sonuç final merge güvenini artırır.

13. Değişiklik Merge Edilir

Repository policy'ye göre squash, rebase veya merge commit kullanılır. Final commit message standardı korunur. Issue otomatik kapanabilir. Audit history review ve approval kayıtlarını tutar. Deployment pipeline tetiklenebilir.

14. Deployment İzlenir

Production rollout yalnızca job success ile bırakılmaz. Error rate, latency ve business metric izlenir. Feature flag kademeli açılabilir. Problemde revert veya disable uygulanabilir. Change ile telemetry arasında ilişki kurulmalıdır.

15. Source Branch Silinir

Merge edilen kısa branch otomatik temizlenir. Repository branch listesi sade kalır. Long lived protected branch'ler korunur. Stacked branch varsa dependency davranışı kontrol edilir. Issue ve deployment kaydı history'yi korumaya devam eder.

PR/MR Template İçin Önerilen Checklist

PR template checklist author'ın review öncesinde temel riskleri düşünmesini sağlar. Tek amaç, issue bağlantısı, test, breaking change ve migration gibi sorular önemli kontrol noktalarıdır. Security etkisi ve feature flag ihtiyacı da erken görünür hale gelir. Rollback ve documentation değişiklikleri unutulmamalıdır. Checklist mümkün olduğunca kısa ve gerçekten karar değiştiren maddelerden oluşmalıdır.

Değişiklik Tek Bir Amaca mı Hizmet Ediyor?

PR farklı üç requirement'ı aynı anda çözmeye çalışmamalıdır. Scope kolay açıklanabilmelidir. Unrelated refactor ayrılabilir. Küçük scope review ve revert'i kolaylaştırır. Büyük feature stacked change'e bölünebilir.

Issue Bağlandı mı?

Requirement kaynağı görünür olmalıdır. Reviewer acceptance criteria'ya ulaşabilmelidir. Closing keyword gerekiyorsa eklenir. Incident değişikliği incident kaydına bağlanır. Public repository'de hassas ticket bilgisi paylaşılmamalıdır.

Testler Eklendi mi?

Yeni davranış testle doğrulanmalıdır. Bug fix regression test içerebilir. Test eklenmediyse gerekçe açıklanır. Coverage tek kriter değildir. Failure path de düşünülmelidir.

Lokal Test Yapıldı mı?

Author hızlı temel testleri local çalıştırmalıdır. CI açık hatalar için gereksiz tüketilmez. Environment farkı varsa belirtilir. Manual test adımları description'a yazılır. Local success CI'ın yerine geçmez.

Breaking Change Var mı?

API veya schema compatibility bozuluyorsa açıkça işaretlenmelidir. Migration veya deprecation planı gerekir. Consumer ekipler bilgilendirilir. Extra approval gerekebilir. Release note oluşturulur.

Database Migration Var mı?

Migration schema ve data etkisini görünür hale getirir. Lock ve rollback riski değerlendirilir. Database owner review gerekebilir. Deployment sırası yazılır. Backfill ayrı planlanabilir.

Security Etkisi Var mı?

Authentication, permission veya sensitive data behavior değişiyor mu sorulmalıdır. Security path otomatik owner tetikleyebilir. Secret eklenmemelidir. Scan sonucu kontrol edilir. High risk change security approval alır.

Screenshot Eklendi mi?

UI change varsa görsel review süresini azaltır. Before ve after faydalı olabilir. Hassas data görünmemelidir. Interaction için video kullanılabilir. Screenshot testin yerine geçmez.

Feature Flag Gerekli mi?

Büyük veya riskli feature staged release ihtiyacı taşıyabilir. Incomplete feature main'e erken merge edilebilir. Kill switch incident riskini azaltır. Flag owner belirlenmelidir. Cleanup tarihi planlanmalıdır.

Rollback Planı Var mı?

Production riskli change için geri dönüş yolu bilinmelidir. Revert her zaman yeterli değildir. Database ve external contract etkisi değerlendirilmelidir. Feature flag alternatif olabilir. Plan reviewer tarafından doğrulanmalıdır.

Documentation Güncellendi mi?

API, runbook veya config behavior değişiyorsa documentation da güncellenmelidir. Kullanıcı ve operator etkisi ayrı düşünülebilir. Generated docs gerekiyorsa CI doğrular. Eski talimat bırakılmamalıdır. Documentation owner review'a dahil olabilir.

Merge Öncesi Kontrol Listesi

Merge öncesi son kontrol stale state ve eksik quality gate riskini azaltır. Pipeline'ın green olması, required review'ların tamamlanması ve Code Owner approval'ın bulunması temel adımlardır. Blocking discussion kalmamalıdır. Security ve database riskleri ayrıca doğrulanmalıdır. Rollback ile deployment planının anlaşılır olması change'in production'a gerçekten hazır olduğunu gösterir.

Pipeline Green mi?

Required jobs başarıyla tamamlanmalıdır. Son pipeline güncel commit üzerinde çalışmış olmalıdır. Blind retry sonucu gözden geçirilmelidir. Flaky failure varsa çözülmelidir. Queue final combined pipeline ayrıca green olmalıdır.

Required Review'lar Tamam mı?

Minimum reviewer sayısı karşılanmalıdır. Approval veren kişilerin eligible olduğu doğrulanmalıdır. Yeni commit stale approval oluşturmuş olabilir. High risk rule'lar ayrı kontrol edilir. Self approval tek gerekli onay olmamalıdır.

Code Owner Approval Var mı?

Sensitive path değiştiyse doğru owner review vermelidir. CODEOWNERS mapping güncel olmalıdır. Owner approval yeni diff için geçerli olmalıdır. Bypass kullanılmadığı doğrulanmalıdır. Ownership dosyasının kendisi değiştiyse ek dikkat gerekir.

Blocking Discussion Kaldı mı?

Request changes ve blocking thread'ler çözülmelidir. Sadece resolve düğmesine basılmış olması yeterli değildir. Reviewer final fix'i görmelidir. Non blocking fikir follow up'a taşınabilir. Conversation resolution policy uygulanmalıdır.

Branch Güncel mi?

Target branch değişmiş olabilir. Required up to date veya queue mekanizması bunu yönetebilir. Manual merge workflow'da rebase gerekebilir. Conflict çözümü yeni review isteyebilir. Stale CI sonucuyla merge yapılmamalıdır.

Security Scan Başarılı mı?

Required security checks green olmalıdır. Suppressed finding gerekçesi kontrol edilmelidir. New critical vulnerability merge edilmemelidir. Secret scan sonucu dikkate alınmalıdır. Sensitive change human security review da alabilir.

Database Migration Güvenli mi?

Migration backward compatible olmalıdır. Lock ve runtime etkisi değerlendirilmelidir. Rollback veya fix forward planı açık olmalıdır. Backfill kontrollü yapılmalıdır. Database owner gerekiyorsa approval vermelidir.

Rollback Planı Hazır mı?

Problemde ilk mitigation adımı bilinmelidir. Revert gerçekten uygulanabilir mi doğrulanmalıdır. Feature flag varsa erişim yetkisi hazır olmalıdır. Database geri dönüşü ayrıca düşünülmelidir. Incident sırasında plan aranmamalıdır.

Deployment Riski Anlaşılıyor mu?

Blast radius ve user impact açık olmalıdır. Staged rollout gerekiyorsa planlanmalıdır. Monitoring metric'leri bilinmelidir. High risk window'da on call availability kontrol edilebilir. Merge ile production release arasındaki ilişki ekip tarafından anlaşılmalıdır.

Reviewer Kontrol Listesi

Reviewer checklist her diff'i aynı mekanik sırayla onaylamak için değil önemli risk başlıklarını hatırlamak için kullanılır. Requirement doğruluğu ve scope ilk kontrol olmalıdır. Error handling, test, security ve performance etkileri değişikliğe göre değerlendirilir. Backward compatibility ve observability production change'lerde önemli iki alandır. Reviewer bilmediği domain konusunda gerekli owner'dan yardım istemekten çekinmemelidir.

Değişiklik Requirement'ı Karşılıyor mu?

Issue acceptance criteria okunmalıdır. Kod yalnızca bazı senaryoları çözmüş olabilir. Product behavior ile implementation karşılaştırılmalıdır. Eksik requirement blocking comment olur. Gereksiz ek behavior scope problemi oluşturabilir.

Gereksiz Scope Var mı?

PR unrelated refactor içeriyor mu kontrol edilmelidir. Büyük formatting change önemli diff'i gizleyebilir. Feature dışı iş follow up'a ayrılabilir. Küçük scope review kalitesini artırır. Author'ın tek PR ile her şeyi düzeltme isteği sınırlandırılmalıdır.

Kod Anlaşılır mı?

Naming ve control flow kolay takip edilmelidir. Gereksiz abstraction azaltılabilir. Comment karar gerekçesini açıklayabilir. Clever code yerine açık code tercih edilir. Ekip standardıyla tutarlılık önemlidir.

Error Handling Doğru mu?

Failure durumunda sistem kontrollü cevap vermelidir. Exception kaybolmamalıdır. Retry duplicate side effect üretmemelidir. Kullanıcıya sensitive error gösterilmemelidir. Monitoring hata durumunu görünür kılmalıdır.

Edge Case'ler Var mı?

Boundary input ve concurrency koşulları düşünülebilir. Null veya boş value behavior açık olmalıdır. High risk path'te failure testleri önemlidir. Her teori için test eklemek gerekli değildir. Kritik edge case kaçırılmamalıdır.

Testler Yeterli mi?

Yeni behavior test edilmelidir. Test yalnızca implementation detail'e bağlı olmamalıdır. Regression fix bug'ı yeniden üretmelidir. Integration effect gerekiyorsa uygun test katmanı kullanılmalıdır. Coverage yüzdesi tek karar olmamalıdır.

Security Riski Var mı?

Input, auth ve permission değişiklikleri kontrol edilir. Secret veya PII loglanıyor mu bakılır. Dependency riskleri scan sonucu üzerinden görülür. High risk path security reviewer ister. Reviewer bilmediği security konusunu tahminle approve etmemelidir.

Performance Regresyonu Var mı?

Yeni query veya network call hot path'i etkileyebilir. Loop içinde expensive işlem aranabilir. Büyük data set davranışı düşünülmelidir. Cache ve batching seçenekleri değerlendirilebilir. Gerçek risk varsa benchmark istenebilir.

Backward Compatibility Korunuyor mu?

Eski API consumer ve application version'ları dikkate alınmalıdır. Database migration rolling deploy ile uyumlu olmalıdır. Breaking change açıkça işaretlenmelidir. Deprecation planı gerekiyorsa eklenmelidir. Feature flag compatibility riskini azaltabilir.

Monitoring/Logging Yeterli mi?

Yeni failure production'da nasıl fark edilecek sorulmalıdır. Log yeterli context sağlamalıdır. Metric gerekliyse değişiklikle birlikte eklenmelidir. Sensitive data logging'den kaçınılmalıdır. Deployment dashboard'u yeni behavior'ı gösterebilmelidir.

Sık Yapılan PR/MR Yönetim Hataları

PR süreçlerinde en yaygın hata quality gate sayısını artırmanın otomatik olarak kalite sağlayacağını düşünmektir. Binlerce satırlık change, açıklamasız review request ve başarısız CI ile reviewer çağırmak cycle time'ı yükseltir. Domain expert olmadan approval alınması formal fakat zayıf kontrol oluşturur. CODEOWNERS ve branch protection bypass edilebiliyorsa görünürde güçlü policy gerçekte etkisiz kalır. Merge sonrasında production metric'lerini izlememek değişiklik yönetiminin son aşamasını eksik bırakır.

Binlerce Satırlık Tek PR/MR Açmak

Büyük diff reviewer dikkatini dağıtır. Review yüzeysel hale gelebilir. Conflict ve stale branch riski artar. Refactor, migration ve feature ayrılabilir. Stacked PR veya feature flag çözüm sağlayabilir.

Açıklamasız Review İstemek

Reviewer değişikliğin amacını diff'ten tahmin etmek zorunda kalır. Requirement yanlış anlaşılabilir. Test yöntemi bilinmez. Review süresi uzar. Kısa problem ve solution description büyük fark yaratır.

CI Başarısızken Review İstemek

Reviewer zaten otomatik testin bulduğu hatayla vakit kaybeder. Author pipeline'ı önce kontrol etmelidir. Bilinen infrastructure failure varsa açıklanabilir. Review ready state quality signal olmalıdır. Green CI human review'un yerine geçmez.

Her Reviewer Yorumunu Blocking Kabul Etmek

Nit ve suggestion'lar merge süresini gereksiz uzatır. Severity standardı kullanılmalıdır. Correctness ve security blocking olur. İyileştirmeler follow up'a taşınabilir. Reviewer niyetini açık yazmalıdır.

Domain Expert Atamamak

Genel reviewer kodu okuyabilir fakat business riskini kaçırabilir. Payment veya authentication owner gerekir. CODEOWNERS doğru routing sağlar. Tek domain expert bottleneck oluşturmamalıdır. Bilgi ekip içinde yayılmalıdır.

Approval Sonrası Kodu Değiştirip Doğrudan Merge Etmek

Reviewer görmediği kod final history'ye girebilir. Stale approval dismissal kullanılmalıdır. Son push bağımsız kişi tarafından görülmelidir. CI tekrar çalışmalıdır. High risk change için final review yapılmalıdır.

CODEOWNERS Dosyasını Korumasız Bırakmak

Author ownership rule'u değiştirip kendi review gate'ini kaldırabilir. CODEOWNERS için ayrı owner tanımlanmalıdır. Protected branch direct push'u engellemelidir. Policy dosyası security sensitive kabul edilmelidir. Audit değişiklikleri takip etmelidir.

Admin Bypass'ı Normal Workflow Olarak Kullanmak

Her acil görünen durumda admin merge kullanılırsa branch protection anlamını kaybeder. Bypass yalnızca break glass olmalıdır. Kullanım audit edilir. Sonradan full review yapılır. Tekrarlanan bypass process problemine işaret eder.

Merge Queue Olmadan Çok Yoğun main Branch Yönetmek

Günde çok sayıda merge stale CI riskini büyütür. Manual rebase developer zamanını tüketir. İki green PR birlikte main'i bozabilir. Queue veya train combined validation sağlar. CI kapasitesi buna göre planlanmalıdır.

Merge Edildikten Sonra Production Metriklerini İzlememek

Pipeline success gerçek production davranışını garanti etmez. Error rate ve latency değişebilir. Business metric bozulabilir. Deployment annotation ve monitoring kullanılmalıdır. Hızlı rollback için owner hazır olmalıdır.

PR/MR Management Maturity Model

PR veya MR maturity modeli direct push'tan risk bazlı, metric driven governance seviyesine kadar ilerleyen bir gelişim yolu sunar. Her ekip en üst seviyeye hemen çıkmak zorunda değildir. İlk güçlü adım protected branch ve human review'dur. Daha sonra CI, CODEOWNERS ve security gate eklenebilir. Yüksek throughput repository'lerde Merge Queue veya Merge Train, ileri aşamada ise risk bazlı policy ve analytics devreye girer.

Seviye 0: Direct Push to Main

Developer doğrudan main'e değişiklik gönderir. Human review zorunlu değildir. CI yalnızca merge sonrasında çalışabilir. Audit ve rollback bağlamı zayıftır. İlk hedef protected branch ile PR workflow'a geçmektir.

Seviye 1: PR/MR + Manuel Review

Değişiklik branch üzerinden PR veya MR ile gelir. En az bir kişi manuel review yapar. Kurallar teknik olarak enforced olmayabilir. Direct push hâlâ mümkün olabilir. Sonraki adım branch protection'dır.

Seviye 2: Protected Branch + CI

Main protected hale gelir. Direct push kapanır. Required test ve build check uygulanır. Review workflow technical gate olur. Flaky test yönetimi önem kazanır.

Seviye 3: Required Approval + CODEOWNERS

Minimum approval zorunlu hale gelir. Sensitive path doğru owner'a yönlendirilir. Self approval sınırlandırılabilir. Review ownership daha görünür olur. Bottleneck ve review SLA izlenmeye başlanır.

Seviye 4: Security Gates + Automated Policies

Security scan ve riskli path approval otomatik hale gelir. Policy organization seviyesinde uygulanabilir. Signed commit veya audit gereksinimi eklenebilir. Infrastructure ve database change özel template kullanabilir. Bypass kontrol altında tutulur.

Seviye 5: Merge Queue/Train + Progressive Governance

Yoğun repository queue veya train kullanır. Combined CI stale integration riskini azaltır. Risk seviyesine göre farklı gate uygulanır. Preview environment ve staged rollout workflow'a bağlanır. Main sürekli green hedeflenir.

Seviye 6: Risk-Based Review ve Metrics-Driven Optimization

Review policy change riskine göre otomatik şekillenir. Time to review, defect ve revert rate birlikte analiz edilir. Reviewer load ve ownership data ile optimize edilir. Quality gate sürekli incident öğrenmeleriyle güncellenir. Hız tek hedef olmadan developer experience ve reliability birlikte geliştirilir.

Sık Sorulan Sorular

GitLab ve GitHub Üzerinde Merge/Pull Request Yönetimi hakkında en sık sorulan konular review sayısı, CODEOWNERS, merge stratejisi ve queue yaklaşımı etrafında toplanır. Her repository için tek doğru policy yoktur. Küçük ekip ile payment sistemi geliştiren büyük kurum aynı approval modeline ihtiyaç duymaz. Bununla birlikte protected main, bağımsız review, green CI ve açık ownership hemen her production ortamında güçlü başlangıç noktalarıdır. Aşağıdaki yanıtlar bu temel prensipleri pratik kararlarla ilişkilendirir.

Pull Request nedir?

Pull Request bir branch'teki değişikliğin hedef branch'e alınması için oluşturulan review talebidir. GitHub bu terimi kullanır. Diff, comment, approval ve CI sonuçları aynı akışta görülebilir. Branch protection merge koşullarını zorunlu hale getirebilir. Merge sonrası PR değişiklik geçmişinin önemli kaydı olarak kalır.

Merge Request nedir?

Merge Request GitLab'da branch değişikliğini target branch'e almak için kullanılan review akışıdır. Reviewer ve approver atanabilir. Pipeline ve discussion sonuçları merge kararını etkiler. Approval rules ve Code Owners ek governance sağlar. Temel amaç Pull Request ile aynıdır.

GitHub Pull Request ile GitLab Merge Request arasındaki fark nedir?

Kavramsal amaç aynıdır. Fark terminoloji ve platformun policy implementation ayrıntılarında ortaya çıkar. GitHub branch protection, rulesets ve Merge Queue kullanabilir. GitLab protected branches, approval rules ve Merge Train sunar. Ekip seçim yaparken mevcut DevOps ve hosting ihtiyaçlarını değerlendirmelidir.

Pull Request nasıl açılır?

Önce target branch'ten feature branch oluşturulur. Değişiklik commit edilip remote'a push edilir. GitHub üzerinde source ve target branch seçilerek Pull Request oluşturulur. Description, issue ve test planı eklenir. Draft veya Ready for Review durumu işin hazırlık seviyesine göre seçilir.

Merge Request nasıl açılır?

GitLab projesinde feature branch remote'a push edilir. Yeni Merge Request oluşturularak source ve target branch seçilir. Description ve reviewer bilgileri eklenir. Pipeline otomatik tetiklenebilir. Required approval ve discussions tamamlandıktan sonra merge edilir.

Pull Request için kaç reviewer olmalı?

Çoğu normal application change için en az bir bağımsız reviewer iyi başlangıçtır. High risk değişiklik iki reviewer veya özel domain approval isteyebilir. Reviewer sayısı tek başına kalite sağlamaz. Doğru expertise daha önemlidir. Policy change riskine göre kademeli olmalıdır.

CODEOWNERS nedir?

CODEOWNERS repository path'lerini belirli kişi veya ekiplerle eşleştirir. Değişiklik ilgili path'e dokunduğunda reviewer otomatik atanabilir. Required Code Owner approval sensitive code'u koruyabilir. Ownership dosyasının kendisi de korunmalıdır. Team based ownership bottleneck riskini azaltır.

Protected branch nedir?

Protected branch direct push, force push veya kontrolsüz merge gibi işlemleri sınırlayan branch'tir. main için yaygın biçimde kullanılır. Required review ve CI ile birlikte güçlü quality gate sağlar. Admin bypass dikkatli yönetilmelidir. Production branch governance'ın temelidir.

Pull Request approval nasıl zorunlu hale getirilir?

GitHub branch protection veya ruleset üzerinden required approving reviews ayarlanabilir. Gerekli reviewer sayısı tanımlanır. Code Owner review ayrıca zorunlu tutulabilir. Stale review dismissal yeni commit riskini azaltır. Ruleset kapsamının doğru branch'i hedeflediği doğrulanmalıdır.

GitLab approval rules nasıl çalışır?

Approval rules belirli sayıda veya belirli kullanıcı ve gruplardan approval isteyebilir. Rules protected branch veya domain ihtiyacına göre uygulanabilir. Code Owners ayrıca approval kaynağı olabilir. Self approval ve committer approval davranışı policy ile yönetilebilir. Plan ve sürüme bağlı özellik ayrıntıları güncel dokümantasyondan doğrulanmalıdır.

PR/MR ne kadar küçük olmalıdır?

Sabit satır sayısı yerine review edilebilir scope hedeflenmelidir. PR tek amaçlı olmalıdır. Reviewer tek oturumda context'i anlayabilmelidir. Generated code gerçek boyuttan ayrılabilir. Büyük feature küçük bağımlı PR'lara bölünebilir.

Draft PR/MR ne zaman kullanılmalıdır?

Change henüz merge'e hazır değil fakat early feedback istendiğinde Draft kullanılabilir. Architecture veya interface kararı erkenden review edilebilir. CI ve preview environment çalıştırılabilir. Ready'ye geçmeden self review ve test tamamlanmalıdır. Draft uzun süre sahipsiz bırakılmamalıdır.

Squash merge nedir?

Squash merge PR içindeki commit'leri tek final commit olarak target'a ekler. History sade kalır. PR title final commit mesajına dönüşebilir. Revert kolaylaşabilir. Anlamlı individual commit geçmişi target'ta kaybolur.

Rebase merge nedir?

Rebase merge feature commit'lerini merge commit oluşturmadan target history'ye ekler. Linear history korunur. Individual commits kalabilir. Commit quality daha önemli hale gelir. Conflict çözümü ve history rewrite bilgisi gerekir.

Merge commit nedir?

Merge commit iki branch geçmişini birleştiren ayrı commit oluşturur. Feature branch history'si korunur. PR boundary history içinde görünür olur. Çok sık kullanım history'yi yoğunlaştırabilir. Ekip debugging ve audit ihtiyacına göre tercih yapmalıdır.

Hangisi daha iyi: squash mı rebase mi?

Evrensel tek cevap yoktur. Küçük feature PR'larında squash sade history sağlar. Temiz individual commit'leri korumak isteyen ekip rebase kullanabilir. Release ve bisect ihtiyaçları kararı etkiler. Repository genelinde tutarlı tek yaklaşım seçmek faydalıdır.

GitHub Merge Queue nedir?

GitHub Merge Queue yoğun branch'e giden PR'ları sıraya alır. Required checks target'ın güncel hali ve queue state üzerinde doğrulanabilir. PR conflict veya failed check nedeniyle queue'dan çıkarılabilir. Manual branch update yükünü azaltır. Main branch stability'yi güçlendirir.

GitLab Merge Train nedir?

GitLab Merge Train MR'ları sıraya alıp önündeki MR'ların değişiklikleriyle birlikte test eder. Merged results pipeline yaklaşımını queue seviyesine taşır. Pipeline'lar parallel çalışabilir. Failure yaşayan MR train'den çıkarılır. Yoğun default branch için güçlü entegrasyon kontrolüdür.

Merge Queue ile Merge Train arasındaki fark nedir?

İkisi benzer integration problemini farklı platform mekanizmalarıyla çözer. GitHub merge group ve required checks yaklaşımını kullanır. GitLab merged results pipeline ve train kombinasyonu kullanır. CI trigger ayrıntıları farklıdır. Seçim kullanılan platform ve repository throughput'a bağlıdır.

CI başarısızsa PR/MR merge edilebilir mi?

Production repository'lerinde required CI başarısızken normal merge yapılmamalıdır. Failure gerçek regression veya flaky test olabilir. Önce nedeni araştırılmalıdır. Emergency bypass ayrı ve audit edilen süreç olmalıdır. Required check branch policy ile teknik olarak enforce edilmelidir.

Approval sonrası yeni commit gelirse yeniden review yapılmalı mı?

High risk repository'lerde evet. Reviewer'ın görmediği code final merge'e girmemelidir. Stale approval dismissal kullanılabilir. Küçük change'ler için policy daha esnek olabilir. En az bir reviewer final diff'i görmelidir.

Author kendi PR/MR'ını approve edebilir mi?

Formal required approval açısından çoğu production akışında bağımsız reviewer tercih edilmelidir. Self approval human review hedefini zayıflatır. Küçük personal repository farklı policy kullanabilir. Regüle sistemlerde separation of duties daha önemlidir. Platform ayarları self approval'ı sınırlandıracak şekilde yapılandırılabilir.

Büyük PR'lar nasıl küçük parçalara ayrılır?

Refactor feature'dan ayrılabilir. Database migration önce gönderilebilir. Backend ve frontend change ayrı yapılabilir. Feature flag incomplete behavior'ı gizleyebilir. Stacked PR bağımlı küçük değişiklikler için kullanılabilir.

Stacked pull request nedir?

Stacked PR birbirini base alan küçük Pull Request zinciridir. Büyük feature incremental diff'lere bölünür. Review genellikle bottom up yapılır. Alt PR merge olduğunda üst branch yeniden base edilir. Queue desteği integration'ı kolaylaştırabilir.

Merge sonrası hata çıkarsa revert mi fix-forward mı yapılmalıdır?

Değişikliğin yapısına göre karar verilmelidir. Reversible application change için revert hızlı olabilir. Irreversible database değişikliğinde fix forward daha güvenli olabilir. Feature flag disable üçüncü seçenek sunar. Öncelik kullanıcı etkisini en düşük riskle azaltmaktır.

Sonuç: Etkili Merge/Pull Request Yönetimi Nasıl Kurulur?

GitLab ve GitHub Üzerinde Merge/Pull Request Yönetimi başarılı olduğunda repository yalnızca kod saklanan alan olmaktan çıkar ve kontrollü değişiklik yönetimi sistemine dönüşür. Küçük PR'lar, doğru reviewer, güçlü CI ve korunmuş main branch bu yapının temelini oluşturur. CODEOWNERS domain bilgisini doğru kişilere yönlendirirken Merge Queue veya Merge Train yoğun repository'lerde stale integration riskini azaltır. Risk bazlı governance düşük riskli değişiklikleri gereksiz yere yavaşlatmadan kritik değişikliklere daha güçlü kontrol uygular. En önemli hedef merge sayısını artırmak değil, değişiklikların hızlı, anlaşılır ve güvenli biçimde production'a ulaşmasını sağlamaktır.

PR/MR'ı Merge Butonundan İbaret Görmeyin

PR değişikliğin tasarım, review ve test kaydıdır. Issue ile requirement bağını korur. CI ve security gate'leri tek süreçte birleştirir. Production incident sonrası karar geçmişini gösterir. Merge yalnızca yaşam döngüsünün bir aşamasıdır.

Küçük ve Tek Amaçlı Değişiklikleri Tercih Edin

Küçük change daha hızlı review edilir. Conflict riski azalır. Revert kolaylaşır. Reviewer dikkatini gerçek riskte tutar. Büyük feature feature flag veya stacked PR ile bölünebilir.

Author, Reviewer ve Approver Rollerini Netleştirin

Author change kalitesinden sorumludur. Reviewer teknik ve domain review yapar. Approver formal gate'i tamamlar. High risk sistemlerde roller ayrılabilir. Sorumluluk belirsiz bırakılmamalıdır.

CODEOWNERS ile Review'u Doğru Uzmanlara Yönlendirin

Path ownership manuel reviewer seçimini azaltır. Sensitive code doğru domain'e gider. Required approval teknik gate oluşturur. CODEOWNERS dosyasının kendisi korunmalıdır. Ownership ekip değiştikçe güncellenmelidir.

Protected Branch ile Kuralları Teknik Olarak Zorunlu Kılın

Dokümantasyon tek başına yeterli değildir. Direct push ve force push sınırlandırılmalıdır. Required review ve CI branch policy'ye bağlanmalıdır. Bypass yalnızca kontrollü exception olmalıdır. Audit gerçek kullanımın policy ile uyumunu göstermelidir.

CI ve Security Kontrollerini Merge Quality Gate'e Dönüştürün

Build, test ve lint human reviewer'ın mekanik yükünü azaltır. Security scan bilinen riskleri erken yakalar. Required check failure merge'i engelleyebilir. Flaky test'ler quality gate güvenini bozduğu için hızla düzeltilmelidir. Test selection change riskine göre optimize edilebilir.

Approval Sonrası Değişiklikleri Yeniden Doğrulayın

Approval belirli diff'e verilmiştir. Yeni commit geldiğinde reviewer'ın görmediği code merge edilmemelidir. Stale approval reset kullanılabilir. CI yeniden çalışmalıdır. High risk repository final diff review'u zorunlu tutabilir.

Yoğun Repository'lerde Merge Queue veya Merge Train Kullanın

Tek başına green PR target değiştiğinde stale hale gelebilir. Queue veya train combined state'i yeniden doğrular. Main branch'in sürekli green kalmasına yardımcı olur. CI compute maliyeti artabilir. Yüksek merge hacminde reliability avantajı çoğu zaman bu maliyeti karşılar.

Review Hızını ve Kalitesini Birlikte Ölçün

Time to first review developer wait time'ı gösterir. Defect ve revert rate quality sonucunu gösterir. İki metric birlikte değerlendirilmelidir. Reviewer distribution bottleneck'i ortaya çıkarabilir. Rakamlar insanları puanlamak yerine workflow'u geliştirmek için kullanılmalıdır.

PR/MR Yönetimini Kod Birleştirme Değil Yazılım Kalitesi ve Değişiklik Riski Yönetimi Süreci Olarak Ele Alın

En güçlü PR süreçleri en çok approval isteyen süreçler değildir. Doğru değişiklikte doğru review ve doğru otomatik kontrolü isteyen süreçlerdir. Risk bazlı yaklaşım developer experience ile governance arasında daha sağlıklı denge kurar. Kurumsal GitLab GitHub merge request ve code review süreç danışmanlığı değerlendirilirken yalnızca platform ayarlarına değil branch modeli, review SLA, security gate, queue ve deployment bağlantısına birlikte bakılmalıdır. Diyarbakır Yazılım Topluluğu'nun teknik proje yaklaşımını https://www.diyarbakiryazilim.com.tr/projects ve topluluk hakkındaki bilgileri https://www.diyarbakiryazilim.com.tr/about adreslerinden inceleyebilirsiniz.

GitLab GitHub ve DevOps danışmanlığı yakınımda şeklinde çözüm ararken ilk sorunuz hangi aracın kurulacağı değil, hangi değişikliğin hangi kontrol olmadan production'a girememesi gerektiği olmalıdır. İyi danışmanlık mevcut repository akışını analiz eder, bottleneck'leri ölçer ve ekip büyüklüğüne uygun governance seviyesi önerir. Branch protection, CODEOWNERS, CI quality gate ve merge queue gibi teknik mekanizmalar organizasyonun gerçek risk modeliyle eşleştirilmelidir. GitLab ve GitHub Üzerinde Merge/Pull Request Yönetimi için süreç tasarımı, eğitim veya DevOps uygulama desteği hakkında iletişim kurmak isterseniz https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz. Amaç daha fazla kural eklemek değil, güvenilir değişiklik akışını ekip için doğal çalışma biçimi haline getirmektir.

GitLab ve GitHub Merge/Pull Request Yönetimi Hakkında Ek Sık Sorulan Sorular

Merge ve review süreçleri büyüdükçe ekiplerin soruları araç kullanımından governance tasarımına doğru kayar. Kaç reviewer gerektiği, hangi CI job'ının blocking olması gerektiği ve branch protection'ın nasıl uygulanacağı repository riskine bağlıdır. GitHub ile GitLab benzer temel modeller sunsa da policy ve queue davranışlarının uygulama ayrıntıları farklıdır. Bu nedenle internetten hazır bir ayar listesini kopyalamak yerine mevcut development ve deployment akışını değerlendirmek gerekir. Aşağıdaki yanıtlar uygulamaya geçerken en sık karşılaşılan beş soruyu özetler.

GitLab ve GitHub üzerinde Merge Request (MR) ve Pull Request (PR) süreçleri nasıl yönetilir?

Öncelikle main branch protected hale getirilmeli ve normal direct push kapatılmalıdır. Geliştirici kısa ömürlü branch üzerinde çalışıp açıklaması ve test planı bulunan PR veya MR açmalıdır. CI kontrolleri otomatik çalışmalı, CODEOWNERS gerekli domain reviewer'ları yönlendirmeli ve en az bir bağımsız human review tamamlanmalıdır. Approval sonrasında yeni commit gelirse gerekli re review politikası uygulanmalı ve yoğun repository'lerde Merge Queue veya Merge Train final combined validation için kullanılmalıdır. Merge sonrası deployment metric'leri gözlenmeli ve source branch temizlenmelidir.

Merge Request ile Pull Request arasındaki farklar nelerdir?

Temel amaç açısından büyük fark yoktur. Pull Request GitHub terminolojisi, Merge Request ise GitLab terminolojisidir. Farklılık branch protection, approval rules, CI entegrasyonu ve queue mekanizmalarının platform tarafından nasıl sunulduğunda ortaya çıkar. GitHub rulesets ve Merge Queue kullanabilirken GitLab protected branch, approval rules ve Merge Train yaklaşımını sunar. Araç seçimi yapılırken terminolojiden çok self hosted ihtiyacı, enterprise governance, CI altyapısı ve ekip deneyimi değerlendirilmelidir.

Kod inceleme sürecinde reviewer, approval ve Code Owners kuralları nasıl yapılandırılmalıdır?

Normal application change için en az bir bağımsız reviewer iyi başlangıçtır. Authentication, payment, database veya infrastructure gibi yüksek riskli path'lerde Code Owner ve gerektiğinde ikinci domain approval zorunlu tutulabilir. Author'ın kendi required approval'ına güvenilmemeli ve yeni commit geldiğinde stale approval riskine karşı re review uygulanmalıdır. CODEOWNERS dosyasının kendisi de owner ve protected branch kurallarıyla korunmalıdır. Reviewer sayısını artırmak yerine doğru uzmanı doğru change'e otomatik yönlendirmek hedeflenmelidir.

Merge/Pull Request süreçlerinde branch protection, CI/CD kontrolleri ve merge stratejileri nasıl uygulanmalıdır?

main veya default branch direct push ve force push'a karşı korunmalıdır. Build, test, lint ve gerekli security scan sonuçları required check olarak merge öncesinde green olmalıdır. Küçük ekiplerde squash merge sade history sağlayabilirken bazı projeler rebase veya merge commit tercih edebilir. Yoğun main branch'te GitHub Merge Queue veya GitLab Merge Train stale CI sonucunu azaltmak için kullanılabilir. Seçilen merge yöntemi repository genelinde tutarlı hale getirilmeli ve hotfix bypass süreçleri ayrıca audit edilmelidir.

GitLab ve GitHub Merge/Pull Request yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Danışmanlık veya eğitim seçerken yalnızca GitHub ya da GitLab arayüzünü anlatan içerik yerine gerçek production değişiklik yönetimini kapsayan yaklaşım tercih edilmelidir. Branch protection, CODEOWNERS, approval policy, CI quality gate, security scanning, merge queue ve deployment gözlemi aynı bütün içinde değerlendirilmelidir. Diyarbakır Yazılım Topluluğu'nun teknik çalışmaları hakkında https://www.diyarbakiryazilim.com.tr/projects adresinden bilgi alabilirsiniz. Topluluk ve çalışma yaklaşımı için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Eğitim, süreç analizi veya uygulama desteği için https://www.diyarbakiryazilim.com.tr üzerinden iletişim kurulabilir.