Merge Request (MR): nedir, nasıl oluşturulur ve inceleme süreci

Merge Request (MR) nedir?

Merge Request (MR) — bir Git dalından diğerine değişiklikleri entegre etme isteği olup, kod incelemesi ve otomatik kontroller sürecini başlatır. Konsol üzerinden doğrudan birleştirmenin aksine, MR resmi bir prosedür oluşturur: geliştirici değişiklikleri açıklar, inceleyicileri atar, CI/CD'yi başlatır ve değişiklikler uygulanmadan önce geri bildirim alır. Bu, GitLab'ın temel bir öğesidir, ancak GitHub'daki eşdeğer mekanizma Pull Request (PR) olarak adlandırılır.

GitLab Documentation, 2026'ya göre, GitLab'da yıllık 80 milyondan fazla Merge Request oluşturulmaktadır. Her MR dört ana bileşen içerir: değişiklik bağlamı ile açıklama, commit listesi, kod farkı (diff) ve tartışma (tartışma dizisi). Bu öğelerden biri olmadan MR eksik kabul edilir.

Merge Request (MR) üç görevi çözer: korumalı dallarda (main, develop) doğrudan değişiklikleri önler, inceleme yoluyla kalite kontrolü sağlar ve gelecekteki geliştiriciler için tartışma geçmişini korur. GitLab'da MR durumu arayüzde renk göstergeleriyle görüntülenir: Draft için gri, beklemede için turuncu, Approved için yeşil, Merged için mor ve Closed için kırmızı.

Terminoloji: MR, PR ve CR

Farklı Git platformlarında, Merge Request farklı şekilde adlandırılır. GitLab “Merge Request” (MR), GitHub “Pull Request” (PR) kullanır. Benzer şekilde Gerrit'te Change Request (CR) bulunur. Her üçü de aynı süreci belirtir: kod incelemesi yoluyla değişiklikleri entegre etme isteği. Terim seçimi yalnızca projede kullanılan platforma bağlıdır.

# Değişikliklerle bir dal oluşturun
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# GitLab/GitHub arayüzü veya CLI üzerinden MR oluşturabilirsiniz:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: GitLab ve GitHub arasındaki fark

GitLab'da Merge Request ve GitHub'da Pull Request, işlevsel olarak aynı mekanizmalardır ancak farklı adlara sahiptir. Fark tarihsel nedenlerden kaynaklanır: GitLab başlangıçta kendini GitHub'a Self-Hosted bir alternatif olarak konumlandırdı ve birleştirme süreci için “merge request” terimini seçti. Daha önce başlatılan GitHub, ana dala değişiklikleri “çekmek” (pull) için “pull request” terimini kullandı.

GitHub Docs, 2024'e göre, her iki araç da aynı özellik kümesini destekler: Markdown açıklaması, inceleyici atama, belirli kod satırlarında yorum yapma, kontrol durumları ve koşullar karşılandığında otomatik birleştirme. Farklılıklar arayüz ve ek yeteneklerle ilgilidir.

Merge Request nasıl oluşturulur: adım adım kılavuz

Merge Request (MR) oluşturma, değişikliklerin bulunduğu bir dalın uzak depoda yayınlanmasıyla başlar. GitLab veya GitHub'a push yapıldıktan sonra arayüzde “Create Merge Request” veya “Compare & Pull Request” butonu görünür. Geliştirici açıklamayı doldurur, hedef dalı (genellikle develop veya main) belirtir, inceleyicileri atar ve etiketler ekler.

GitLab Documentation, 2025'e göre, standart bir MR 72 karaktere kadar başlık, şablonlu açıklama ve issue bağlantısı içerir. Açıklama şu soruları yanıtlamalıdır: ne yapıldı, neden, nasıl test edildi. GitLab, Closes, Fixes, Resolves anahtar kelimeleri ile birleştirme sırasında otomatik issue kapatmayı destekler.

# .gitlab/merge_request_templates/default.md şablonu örneği
## What does this MR do?

[Değişikliklerin kısa açıklaması: ne ve neden]

## How to test

1. Çalıştır ./gradlew test
2. Kontrol et LoginActivity test jetonuyla
3. Regresyon olmadığından emin olun: AuthManager

## Related issues

Closes #142

MR yaşam döngüsü: Draft'tan Merged'a

Merge Request (MR) GitLab'da beş durumdan geçer. İlki Draft (taslak) olup, başlıkta “Draft:” öneki ile işaretlenir ve birleştirmeyi engeller. Hazır olduğunda geliştirici Draft'ı kaldırır ve MR Opened durumuna geçer — kod incelemesi başlar ve CI/CD hattı başlatılır.

GitLab Docs, 2024'e göre, Opened durumunda inceleyiciler diff'i inceler, yorum bırakır ve Resolve Threads aracılığıyla değişiklik talep eder. Tüm dizeler çözüldüğünde ve CI/CD başarılı olduğunda, sorumlu geliştirici Approve ayarlar. Bundan sonra MR, Merge butonu kullanılarak birleştirilebilir veya otomatik birleştirme (Auto-merge) beklenebilir.

GitLab üç son durum seçeneğini destekler: Merged (başarıyla birleştirildi), Closed (birleştirilmeden kapatıldı, örn. bir özellikten vazgeçildiğinde) ve Reopened (kapandıktan sonra yeniden açma). Denetim için her durum MR Etkinlik Zaman Çizelgesi'nde kaydedilir.

Otomatik durumlar ve tetikleyiciler

GitLab, olaylar üzerine Merge Request durumunu otomatik olarak günceller: yeni commit'lerin push'u Approvals'ı sıfırlar, başarılı CI hattında durum Pipeline passed, başarısızlıkta — Pipeline failed (birleştirme engellenir) olur. Auto-merge yapılandırılabilir: başarılı CI ve gerekli tüm onaylar alındıktan sonra MR otomatik olarak birleştirilir.

• Draft — taslak, CI çalışır ancak birleştirme engellenir
• Opened — incelemeye hazır, inceleyiciler atanmış, hat aktif
• Approved — gerekli sayıda onay alındı
• Merged — değişiklikler hedef dala birleştirildi
• Closed — birleştirilmeden kapatıldı

Merge Request'te kod inceleme kuralları

Merge Request (MR)'da kod incelemesi çoğu ticari projede zorunlu bir aşamadır. SmartBear, 2023 araştırmasına göre, MR ile kod incelemesi hata sayısını %30–60 azaltır ve yeni geliştiricilerin oryantasyonunu hızlandırır. Temel kural, her MR'ın kod yazımına katılmamış en az bir, tercihen iki geliştirici tarafından kontrol edilmesidir.

MR kontrolü beş kriter içerir: mantıksal doğruluk, kod stiline uygunluk, test kapsamı, güvenlik ve performans. GitLab'da Required Approvals yapılandırılabilir — birleştirme öncesi zorunlu onay sayısı, örneğin main için 2 onay ve develop için 1 onay.

MR'da tartışma Dizeler (Threads) halinde yürütülür — belirli kod satırlarına yapılan yorumlar. Birleştirmeden önce her dize çözülmelidir. İncelemeleri hızlandırmak için MR boyutunun sınırlandırılması önerilir: 200–400 satır değişiklik. Google Research (2022)'e göre, 400 satırdan büyük MR'lar %30 daha az etkili incelenir.

Merge Request'te CI/CD hattı

Merge Request (MR) oluşturulduğunda, CI/CD hattı otomatik olarak başlar. GitLab'da bu .gitlab-ci.yml dosyası aracılığıyla, GitHub'da GitHub Actions iş akışı aracılığıyla gerçekleşir. Hat, proje derlemesi, birim testleri, lint'ler, statik analiz (SAST) ve kod kapsamı kontrolünü içerir.

GitLab Blog, 2024'e göre, hat durumu doğrudan MR'da görüntülenir: yeşil onay işareti (passed), kırmızı çarpı (failed) veya sarı daire (running). Hat başarısız olursa, GitLab düzeltilene kadar Merge butonunu engeller. Ayarlarda, “Merge when pipeline succeeds” etkinleştirilebilir — başarılı hattan sonra otomatik birleştirme.

# .gitlab-ci.yml — Android projesi için örnek
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

Birleştirme yöntemleri: Squash, Merge Commit, Fast-Forward

GitLab ve GitHub Merge Request için üç birleştirme yöntemi sunar. Seçim ekip politikasına ve istenen geçmiş temizliğine bağlıdır. Merge Commit ayrı bir birleştirme commit'i oluşturarak tüm özellik dalı geçmişini korur. Squash tüm dal commit'lerini hedef dalda tek bir commit'te birleştirir. Fast-Forward birleştirme commit'i olmadan commit'leri doğrusal olarak uygular.

GitLab Docs, 2025'e göre, yüksek commit yoğunluğuna sahip projelerde (bir özellik dalında 20+ commit) Squash tercih edilir. Fast-Forward, Trunk-Based Development için zorunludur. Merge Commit, Git Flow'da dallanma anlambilimini korumak için kullanılır.

• Merge Commit — geçmişi korur, birleştirme commit'i oluşturur, Git Flow için uygun
• Squash — tüm commit'leri tek bir commit'te birleştirir, temiz geçmiş, ara commit'leri kaybeder
• Fast-Forward — birleştirme commit'i olmadan doğrusal geçmiş, TBD'de zorunlu

En iyi uygulamalar: iyi bir MR nasıl yazılır

Kaliteli bir Merge Request (MR) inceleme süresini ve hata sayısını azaltır. İlk kural, bir MR'ın bir görevi çözmesidir. Değişiklikler birden çok ilgisiz özelliği etkiliyorsa, bunlar ayrı MR'lara bölünmelidir. İkinci olarak, MR başlığı bilgilendirici olmalıdır: “Fix stuff” veya “Update code” yerine “Add OAuth2 authentication with Google provider” gibi.

Google Engineering Practices, 2024'e göre, iyi bir MR bağlam açıklaması içerir: değişikliklerin neden gerekli olduğu, nasıl test edildiği ve hangi risklerin bulunduğu. MR boyutu 400 satır değişikliği geçmemelidir. Hacim daha büyükse, görev alt görevlere ayrılmalıdır. Dokümantasyon ve testler için istisnalar kabul edilebilir ancak açıklama ile birlikte.

Merge Request (MR) yeni işlevsellik için otomatik testler içermelidir. GitLab'da Coverage Check politikası yapılandırılabilir — kod kapsamı bir eşiğin (örneğin %80) altına düşerse MR otomatik olarak engellenir. Bu, yeni işlevselliğin genel proje kalitesini düşürmemesini sağlar.

• Bir MR — bir görev: büyük değişiklikleri birkaç küçük MR'a ayırın
• Şablonlu açıklama: tutarlılık için .gitlab/merge_request_templates kullanın
• 400 satıra kadar boyut: büyük MR'lar daha yavaş ve daha fazla hatayla incelenir
• Testler zorunludur: yeni özellikler birim testlerle kapsanmalıdır

MR açıklama şablonları

GitLab, .gitlab/merge_request_templates/ dosyaları aracılığıyla Merge Request şablonlarını destekler. Şablon şu bölümleri içerir: ne yapıldığı, nasıl test edileceği, ilgili görevler ve kontrol listesi. Şablon kullanımı MR oluşturmayı hızlandırır ve geliştiricilerin önemli bilgileri eklemeyi unutmamasını sağlar. MR açıklamasında, birleştirme sırasında otomatik görev kapatma için ilgili issue'lar (Closes #N) belirtilmelidir.