Git'te pull request nedir: GitHub'da PR nasıl oluşturulur

Pull request (PR), bir dalın değişikliklerini başka bir dala aktarma önerisidir ve GitHub gibi bir platformda yazılır. Dalınızı sunucuya gönderir, PR'ı açarsınız; ekip diff'i görür, satırlara yorum yazar, otomatik kontrolleri çalıştırır ve ancak ondan sonra birleştirme düğmesine basılır. GitLab'da aynı mekanizma merge request (MR) olarak adlandırılır. Kısaca, «git pull request nedir» sorusunun cevabı şudur: «kodu yazdım» ile «kod main dalına girdi» arasındaki kontrol noktasıdır.

Git pull request nedir ve adı nereden geliyor

Adın ortaya çıkışı tarihseldir. Değişiklikleri yapan kişi, repository sahibinden kendi dalını «çekmesini» (pull) ister; buradan pull request adı gelir. GitLab bu özelliği sonucuna göre adlandırmayı tercih etmiş ve merge request, yani birleştirme talebi demiştir. Bitbucket ve Azure DevOps «pull request» terimini kullanır. Özünde hepsi aynıdır: kaynak dal, hedef dal, açıklama, tartışma, kontroller ve birleştirme düğmesi.

Önemli olan şu: pull request Git'in bir parçası değildir. Git'te «PR» adında bir nesne yoktur; commit ile oluşturulamaz ve .git klasöründe bulunamaz. Bu bir platform varlığıdır: GitHub açıklamayı, yorumları ve kontrol durumlarını kendi sisteminde tutar, Git ise yalnızca PR'ın içerdiği dalları ve commit'leri yönetir.

Geliştiricilerin dilinde PR kısaltması neredeyse her zaman pull request anlamına gelir: «PR atayım», «PR incelemede», «PR'ı birleştirdim». GitLab için MR denir.

Pull request ile git pull arasındaki fark

Benzer kelimeler yüzünden bu iki kavram sık sık karıştırılır. git pull komutu uzak repository'deki yeni commit'leri indirir ve doğrudan mevcut dalınıza ekler: bu terminalde yapılan yerel bir işlemdir. Pull request ise bir dalı diğerine birleştirme önerisi içeren, GitHub üzerindeki bir web sayfasıdır.

Git'te «git pull request» diye bir komut yoktur. Eski bir araç olan git request-pull vardır, ancak o yalnızca değişikliklerin özetini içeren bir e-posta metni üretir ve GitHub'daki PR'larla ilgisi yoktur.

Pull request'ler neden gereklidir

Projeyi tek kişi yürütüyorsa, doğrudan main dalına commit atabilirsiniz. Repository'de iki veya daha fazla kişi çalışmaya başlayınca, ana dala doğrudan yapılan push'lar bozuk build'lerin ve kaybolan işlerin kaynağı olur. Pull request birkaç sorunu birden çözer:

• kod incelemesi — ikinci bir kişi değişiklikleri main'e girmeden önce görür ve yazarın gözden kaçırdığı hataları yakalar;
• otomatik kontroller — GitHub Actions veya başka bir CI her PR'da testleri ve linter'ları çalıştırır, kırmızı durum çalışmayan kodun birleştirilmesini engeller;
• kararların geçmişi — bir yıl sonra PR'a bakarak sadece neyin değiştiğini değil, neden değiştiğini de tartışmasıyla birlikte görebilirsiniz;
• başkalarının projelerine katkı — açık kaynak projelerde yazma yetkiniz yoktur ve bir düzeltmeyi önermenin tek yolu fork'tan gelen PR'dır;
• dal koruması — GitHub'ın dal koruma kuralları main'e doğrudan push'u yasaklayabilir ve onaylı bir PR isteyebilir.

GitHub'da bir daldan pull request nasıl oluşturulur

Bu, tüm üyelerin repository'ye yazma yetkisine sahip olduğu bir ekip için temel senaryodur. Çalışma bir özellik dalında yapılır ve main yalnızca PR yoluyla değişir.

Adım 1. Güncel main'den bir dal oluşturun

git switch main
git pull
git switch -c feature/login-form

Dal adını anlaşılır seçmek iyi olur: feature/…, fix/…, görev numarası. İnceleyici neyin konuşulacağını hemen anlar.

Adım 2. Commit'leri oluşturun

git add src/login.js
git commit -m "Giriş formunu ekle"

Bir PR bir göreve karşılık gelmelidir. 100–300 satırlık küçük bir PR hızlı ve dikkatli incelenir; 3000 satırlık bir PR ise inceleyici tarafından neredeyse bakılmadan onaylanır.

Adım 3. Dalı sunucuya gönderin (pull request için git push)

git push -u origin feature/login-form

Bayrak -u, yerel dalı uzak dalla eşler; bundan sonra yalnızca git push yeterlidir. GitHub'ın yanıtında PR oluşturma bağlantısı zaten yer alır:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

Adım 4. PR'ı web arayüzünde açın

Terminaldeki bağlantıyı açın ya da repository'yi GitHub'da görüntüleyin: yeni bir push'tan sonra «Compare & pull request» düğmeli bir şerit çıkar. Bir diğer yol «Pull requests» sekmesi ve «New pull request» düğmesidir.

1. Dal çiftini kontrol edin: base birleşeceği yer (genellikle main), compare ise sizin dalınızdır.
2. Başlığı yazın: ne yapıldığını emir kipiyle ya da kısa bir açıklamayla belirtin.
3. Açıklamada neden yapıldığını, nasıl test edileceğini ve kapsam dışında bırakılanları anlatın. Repository'de bir PR şablonu varsa alanlar otomatik dolar.
4. Sağda incelemecileri (Reviewers), sorumluyu ve ekip kullanıyorsa etiketleri atayın.
5. «Create pull request» düğmesine basın ya da taslağı seçin (aşağıda anlatılır).

Terminalden PR oluşturmak: GitHub CLI

Tarayıcıya geçmek istemiyorsanız resmi gh aracını kullanabilirsiniz. Bu bir Git komutu değil, GitHub'ın programıdır, ama PR işleri için çok uygundur:

gh pr create --base main --title "Giriş formunu ekle" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

«Git pull request komutları nelerdir» sorusunun dürüst cevabı şudur: Git dalları, commit'leri ve push işlemlerini yönetir; PR ise platformda oluşturulur: tarayıcıda, gh ile ya da API üzerinden.

Fork üzerinden başka bir repository'ye pull request gönderme

Açık kaynak projelerde yazma yetkiniz yoktur. Bu yüzden önce bir fork oluşturursunuz: GitHub'da repository'nin kendi kopyanız. Orada çalışır ve değişikliklerinizi orijinal projeye önerirsiniz.

1. Proje sayfasında «Fork» düğmesine basın; github.com/you/project adresinde kendi kopyanız oluşur.
2. Fork'unuzu klonlayın ve orijinali ikinci bir remote olarak ekleyin; genellikle adı upstream olur.
3. Bir dal oluşturun, commit'lerinizi yapın ve dalı kendi fork'unuza gönderin.
4. GitHub'da PR'ı açın: base repository orijinal proje, head repository ise sizin fork'unuz ve dalınızdır.

git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "README'deki yazım hatasını düzelt"
git push -u origin fix/typo-readme

Başlamadan önce CONTRIBUTING.md dosyasına bakın: genellikle commit kuralları, testler ve önce bir issue açılıp açılmayacağı orada yazar. Fork'unuzu güncel tutun: kendi dalınızda git fetch upstream ve git rebase upstream/main çalıştırarak PR'ın orijinalin gerisinde kalmasını önleyin.

GitLab'da merge request: nedir ve nasıl oluşturulur

GitLab'ın merge request'i, GitHub'ın pull request'inin birebir karşılığıdır. Adları ve arayüz ayrıntıları farklıdır, ama süreç aynıdır: dal, push, birleştirme talebi, inceleme, birleştirme.

MR birkaç şekilde oluşturulabilir:

• yeni bir dalı push ettikten sonra GitLab'ın terminalde yazdırdığı bağlantıyla;
• projenin Merge requests bölümünde «New merge request» düğmesiyle, kaynak ve hedef dalı seçerek;
• push sırasında GitLab'ın push seçenekleriyle, tarayıcıya geçmeden.

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

GitLab'ın terminolojisi biraz farklıdır: onay approve olarak adlandırılır, birleştirmeden sorumlu kişi assignee'dir ve GitHub Actions yerine .gitlab-ci.yml dosyasıyla GitLab CI/CD çalışır. MR taslakları da vardır; bunlara Draft denir.

Pull request incelemesi

İnceleyici «Files changed» sekmesini açar ve diff'i görür. Herhangi bir satıra yorum yazabilir ya da yazarın tek tıkla uygulayabileceği hazır bir düzeltme önerebilir (suggestion). Yorumlar bir inceleme (review) altında toplanır ve üç karardan biriyle birlikte gönderilir:

• Comment — karar vermeden yalnızca gözlemler;
• Approve — değişiklikler onaylandı;
• Request changes — ek değişiklik gerekli, birleştirme uygun değil.

İyi bir inceleme mantığa, okunabilirliğe, testlere ve sınır durumlara bakar; zevk meselelerinde tartışmaz: biçimlendirmeyi CI'daki bir linter'a bırakmak daha iyidir. Yazar her yoruma yanıt vermelidir: düzelttim, tartıştık, ya da açıklamasıyla olduğu gibi bıraktık.

Başkasının PR'ını yerelde denemek (git checkout pull request)

Bazen kodu kendi bilgisayarınızda çalıştırmanız gerekir. Dal aynı repository içindeyse git fetch ve git switch yeterlidir. Fork'tan gelen PR'lar için GitHub özel pull/<numara>/head referansları sunar:

git fetch origin pull/57/head:pr-57
git switch pr-57

GitLab'da benzer referanslar merge-requests/<numara>/head adını taşır. Ya da GitHub CLI kuruluysa doğrudan gh pr checkout 57 kullanabilirsiniz.

Yorumlardan sonra pull request'i güncelleme

PR bir dala bağlıdır, tek tek commit'lere değil. Aynı dalda yeni commit'ler yapıp gönderdiğinizde PR kendiliğinden güncellenir; yeni bir PR açmanız gerekmez.

git commit -am "İnceleme yorumlarını uygula"
git push

Pull request için git rebase: güncel main'i alma

PR incelemedeyken main ilerleyebilir. GitHub dalın geride olduğunu veya çakışma bulunduğunu bildirirse dalı güncelleyin. Rebase ile geçmiş doğrusal kalır:

git fetch origin
git rebase origin/main
# çakışmaları çöz, git add, git rebase --continue
git push --force-with-lease

Rebase sonrası commit hash'leri değişir, bu yüzden normal push reddedilir ve zorlamalı push gerekir. --force-with-lease kullanın: dalda başkalarının yeni commit'leri varsa üzerine yazmayı reddeder. Dalda birden fazla kişi çalışıyorsa, geçmişi yeniden yazmadan git merge origin/main ile main'i dâhil etmek daha güvenlidir.

Pull request nasıl birleştirilir: merge, squash ve rebase

İnceleme onaylandığında ve kontroller yeşil olduğunda PR birleştirilebilir. GitHub üç yöntem sunar; repository yöneticisi bunlardan yalnızca bazılarını bırakabilir.

Arayüzden PR birleştirmek özünde sunucuda çalışan aynı git merge işlemidir. Birleştirmeden sonra GitHub dalı silmeyi önerir: kabul edin, artık gerekmez. Yerelde de temizlik yapın:

git switch main
git pull
git branch -d feature/login-form

PR'ı terminalden elle de birleştirebilirsiniz: dalı yerelde main'e birleştirip push edersiniz. GitHub dalın commit'lerinin base'e girdiğini fark eder ve PR'ı otomatik olarak birleştirilmiş olarak işaretler. Ancak böylece kontroller ve dal koruma kuralları atlanır; bu yüzden ekiplerde genellikle düğmeyle birleştirme yapılır.

Auto-merge ve merge queue

Kontroller uzun sürüyorsa otomatik birleştirmeyi açabilirsiniz: tüm koşullar sağlandığında PR kendiliğinden birleşir. Büyük repository'lerde, sırada bekleyen PR'ların üzerine oturularak kontrol yapan birleştirme kuyruğu (merge queue) kullanılır; böylece birbiriyle uyumsuz değişiklikler main'i bozmaz.

Pull request taslakları (Draft)

Taslak, henüz inceleme için hazır olmayan bir PR'dır. Birleştirilemez ve inceleyicilere onay isteği gitmez. Taslaklar yönü erken göstermek, CI'ı başlatmak ya da mimari konusunda görüş almak için kullanışlıdır. GitHub'da PR oluştururken düğmenin açılır menüsünden taslak seçeneğini seçin ya da gh pr create --draft komutunu kullanın. İş hazır olduğunda «Ready for review» düğmesine basın. GitLab'da taslak MR, başlığın başına eklenen Draft: ön ekiyle belirtilir.

Pull request'i issue'larla ilişkilendirme

PR açıklamasına bir anahtar kelime ve görev numarası yazarsanız, birleştirmeden sonra GitHub varsayılan dalda ilgili issue'yu otomatik kapatır:

Closes #42
Fixes #17
Resolves #8

Close, fix ve resolve kelimeleri farklı biçimlerde (closes, fixed, resolves) çalışır. Anahtar kelime olmadan yalnızca #42 yazmak bağlantı oluşturur ama görevi kapatmaz. GitLab'da da Closes #42 ve benzeri ifadeler aynı şekilde çalışır.

Pull request veya merge request silinebilir mi

GitHub'da sıradan bir katılımcı PR'ı silemez; yalnızca «Close pull request» düğmesiyle kapatabilir. Kapatılan PR geçmişte kalır ve yeniden açılabilir. Dalı kapattıktan sonra ayrıca silmeniz gerekir. PR'ı kalıcı olarak silmek yalnızca GitHub desteği üzerinden mümkündür; örneğin PR'a gizli anahtarlar sızdıysa.

GitLab'da MR, yazarı veya yeterli yetkiye sahip bir katılımcı tarafından kapatılabilir; silme işlemi proje sahibine ya da yöneticiye aittir. PR'a bir parola ya da token girdiyse, yalnızca kapatmak yetmez: gizli bilgiyi hemen iptal edin, çünkü commit'ler zaten sunucudaydı.

Pull request'lerde sık yapılan hatalar

• main'den PR açmak. Yerel main'inize commit atıp oradan PR açtınız. Sonraki PR eski değişiklikleri de içerir. Her zaman ayrı bir dalda çalışın.
• Yanlış base dalı. PR, main yerine develop'a veya tersine açılmış. Base, PR başlığının yanındaki Edit düğmesiyle değiştirilebilir.
• Diff'e gereksiz dosyalar girmiş. Build çıktıları, node_modules, .env. Bunları .gitignore'a ekleyin ve git rm --cached ile indeksten çıkarın.
• Çok büyük PR. İşi birbirini izleyen birkaç PR'a bölün.
• Rebase sonrası normal push. rejected (non-fast-forward) hatası. --force değil, git push --force-with-lease gerekir.
• Çakışmaları körlemesine çözmek. Web editöründe çözmeyin: main'i yerelde güncelleyin, çözün ve testleri çalıştırın.

Git flow ve diğer süreçlerde pull request

Pull request her ekip sürecine uyar. GitHub Flow'da süreç basittir: main'den dal, PR, inceleme, birleştirme, dağıtım. Git flow'da PR'lar özellik dallarından develop'a açılır; release ve hotfix dalları da PR ile main'e gider. Trunk-based geliştirmede PR'lar kısadır ve günler değil saatler içinde biter. Hangi süreç olursa olsun kural tektir: ortak dallara yapılan değişiklikler yalnızca pull request ile girer.

Sonuç

Pull request, Git komutu değil platform mekanizmasıdır: sunucuya gönderilmiş bir dal, üstüne tartışma, inceleme ve kontrollerin eklendiği bir sayfa. GitLab'da merge request adını alır; günlük dilde PR ve MR denir. PR'ı ayrı bir dalda açın, küçük tutun, güncellemeyi aynı dala push ederek yapın ve birleştirme yöntemini projenin geçmişine göre seçin. Fork'lar, özellik dalları ve pull request'ler Git kursunda uygulamalı olarak ele alınmaktadır.