Ana içeriğe geç

Git’te Pull Request: Nasıl Çalıştığına Dair Kılavuzunuz

Pull request’lerin kod incelemelerini nasıl kolaylaştırdığını, işbirliğini güçlendirdiğini ve geliştirme iş akışınızı nasıl düzenli ve verimli tuttuğunu öğrenin.
· 8 dk. oku

Yapay Zeka ile Keşfedin

Pull request’ler ekiplerimin hatalardan kaçınmasına, uygulama kararlarında hizalanmasına ve birbirimizin kodundan öğrenmemize yardımcı oldu. Bu kılavuzda, Git tabanlı platformlarda pull request’leri güvenle kullanarak kodunuzu nasıl inceletebileceğinizi göstereceğim.

Git’e yeni başlıyorsanız, sürüm kontrolünü ve Git ile GitHub arasındaki farkları öğrenmek için Introduction to Git ve Introduction to GitHub Concepts kurslarımızı öneririm. Ayrıca indirilebilir Git Cheat Sheet, en yaygın Git terimleri ve komutlarını içerdiği için kullanışlı bir başvuru kaynağıdır.

Pull Request Nedir?

Pull request aslında koda değişiklik önermenin bir yoludur. Bir özellik üzerinde ya da ayrı bir dalda (branch) çalıştığınızı düşünün; pull request, bu değişikliklerin ana kod tabanına alınmasını talep etmenizi sağlar. Genellikle bu, başkalarının değişiklikleri incelemesinin ardından yapılır. Pull request’ler, özellikle ekip çalışmalarında, ortak geliştirme sürecinin temel bir parçasıdır.

GitLab’de aynı sürecin “Merge Request” olarak adlandırıldığını belirtmekte fayda var. 

Pull Request Nasıl Çalışır?

Aşağıdaki adımlar bir pull request’in temel iş akışını özetler:

  1. Bir özellik dalında betikte (kodda) değişiklik yapın.
  2. Bu değişiklikleri yerel deponuzda commit’leyin.
  3. Dalınızı GitHub gibi uzak depoya push’layın.
  4. Değişiklikleri ana dala önermek için bir pull request açın.
  5. Önerilen değişiklikler için inceleme talep edin.
  6. Birleştirin (merge edin) veya sonuca bağlı olarak pull request’i kapatın.

Bu iş akışı, her geliştiriciye kodu gözden geçirme ve canlı ortama alınmadan önce potansiyel sorunları belirleme fırsatı sunar.

Pull request sürecindeki temel roller şunlardır:

  • Katkıda bulunan (Contributor): Değişiklikleri yapan ve pull request’i açan geliştirici.
  • İnceleyici (Reviewer): Önerilen kod değişikliklerini inceleyerek iyileştirmeler öneren ve kod kalitesini güvence altına alan geliştirici.
  • Bakımcı (Maintainer): Projeyi sahiplenen ve pull request’leri onaylama veya reddetme yetkisine sahip proje yöneticisi. 

Git’te dal oluşturmayı ve ekip üyeleriyle uzaktan nasıl işbirliği yapacağınızı öğrenmek için Intermediate Git kursumuzu öneririm.

Pull Request Oluşturma (Örnekli)

Diyelim ki projenizin README dosyasının giriş satırında bir hata fark ettiniz. Bu sorunu ana dala etki etmeden düzeltmek istiyorsunuz. Aşağıdaki adımları izleyin:

Adım 1: Yeni bir dal oluşturun

Projenizin klasörüne gidin ve aşağıdaki komutu çalıştırmak için terminali açın. Bu satır yeni bir dal oluşturur.

git checkout -b fix-readme-typo

Adım 2: Değişikliğinizi yapın

Dosyayı düzeltmek için README.md dosyasını kod düzenleyicinizde açın, yazım hatasını düzeltin ve dosyayı kaydedin.

Adım 3: Değişiklikleri commit’leyin

Aşağıdaki komutla değişiklikleri aşamaya alın ve commit’leyin:

git add README.md
git commit -m "Fix typo in README"

Adım 4: Dalı GitHub’a push’layın

Dalınızı depoya yükleyin.

git push origin fix-readme-typo

Adım 5: GitHub’ı açın ve bir pull request oluşturun

Şimdi GitHub hesabınızı açın ve şunları yapın:

  • GitHub’daki deponuza gidin.

  • Push’ladığınız dal için Compare & pull request istemini seçin.

Karşılaştır ve pull request.

  • Fix typo in README gibi bir başlık ekleyin ve isterseniz kısa bir açıklama yazın.

  • Temel dalınızı (genellikle main) seçin ve özellik dalınızla karşılaştırın.

Özellik dalıyla pull request karşılaştırması.

Adım 6: İnceleme isteyin ve gönderin

Projenizde başka geliştiriciler yer alıyorsa, inceleyici talep edebilir veya proje kullanıyorsa etiketler ekleyebilirsiniz. Ardından Create pull request düğmesine tıklayın.

Pull request oluşturma.

Üretime kod göndermeden önce nasıl inceleme yapacağınızı ve değişiklikleri yöneteceğinizi anlamak için Performing a Code Review projemize göz atın.

Pull Request En İyi Uygulamaları

Pull request oluştururken kaliteli bir geliştirme süreci için aşağıdaki en iyi uygulamaları izleyin:

  • Pull request’lerinizi sıkı ve sade tutun: Önerdiğiniz her özellik için tek bir pull request ile başlayın. Bu, inceleyicinin değişikliklerinizi takip edip test etmesini kolaylaştırır ve hata sokma olasılığını azaltır.
  • Açık commit mesajları ve açıklamalar yazın: Düzenlemeleri açıklayan betimleyici commit mesajları sağlayın. Bu bağlam, inceleyicilerin niyetinizi koda dalmadan anlamasına yardımcı olur.  
  • Erken geribildirim için taslak pull request’lerden yararlanın: Çalışmanız tamamlanmadıysa ancak geribildirim istiyorsanız bir taslak pull request oluşturun. Bu, kodunuzun devam eden bir iş olduğunu belirtir ve hemen birleştirme zorunluluğu olmadan tartışmayı teşvik eder.
  • Kapsamlı test edin ve bağlam paylaşın: Her şeyin beklediğiniz gibi çalıştığından emin olmak için değişikliklerinizi mutlaka iki kez kontrol edin.

Git İş Akışlarında Pull Request’ler

Farklı ekip ayarlarında pull request’lerin nasıl kullanıldığına hızlı bir bakış:

  • Özellik dallandırma (Feature branching): Küçük ekiplerde ve özel depolarda yaygındır. Bu iş akışı, her özellik için yeni bir dal oluşturmayı içerir. 

  • Fork iş akışı: Açık kaynak projelerde kullanılır. Fork iş akışında katkıda bulunanların ana depoyu kendi hesaplarına fork’laması (kopyalaması) gerekir. Değişiklikleri kendi fork’larında yaparlar ve ardından orijinaline pull request açarlar.

  • GitFlow: main, develop, release ve hotfix gibi uzun ömürlü dalları kullanan yapılandırılmış bir iş akışıdır. Daha kapsamlı sürüm döngülerine sahip büyük ekipler tarafından kullanılır.

Pull Request Görgü Kuralları

Kötü nezaket mümkündür; bu nedenle pull request’lerin de kendine özgü görgü kuralları vardır:

  • Saygılı ve somut olun: Bireye değil, koda odaklanın.
  • Pull request’leri odaklı tutun: İlgisiz değişiklikleri tek bir pull request’te karıştırmaktan kaçının. Bunu göz ardı etmek incelemeyi ve geribildirimi zorlaştırır.
  • Geribildirime düşünerek yanıt verin: İyi yazılmış kodu ve iyileştirme önerilerini takdir edin.
  • Pull request’leri çok bekletmeyin: Güncellemeleri geciktirmemek için pull request’leri mümkün olduğunca hızlı inceleyip sonuçlandırmaya çalışın.
  • Soru sorun: Bir şey net değilse, yanlış anlamaları önlemek için niyet varsaymak yerine açıklama isteyin.
  • İyileştirmeler önerin: Uygun olduğunda yalnızca sorunları işaret etmek yerine uygulanabilir öneriler veya alternatif yaklaşımlar sunun.

Gelişmiş Pull Request İş Akışları ve En İyi Uygulamalar

Eğer işbirliğini daha sorunsuz hale getirmek, kod kalitesini artırmak ve pull request sürecinizi ölçeklemek isteyen deneyimli bir geliştiriciyseniz, iş akışınızı keskinleştirecek bazı pratik ipuçları burada.

Daha akıllı iş akışları

Çeşitli Git iş akışları pull request’leri farklı ele alır. Daha önce tartıştığımız gibi, özellik dallandırma basitliği nedeniyle küçük ekipler için idealdir. Ancak ekibiniz büyüyorsa sürdürmesi zorlaşabilir.

Fork’lama açık kaynak projeler için önerilir, ancak harici katkıları senkronize etme ve incelemede ek yük oluşturabilir. Benzer şekilde, GitFlow hızlı geliştirme ortamlarında önerilir, ancak karmaşıklığı süreci yavaşlatabilir. 

Otomasyon ve entegrasyon

Modern pull request’lerde, her PR’da testleri ve linter’ları çalıştıran ve önizleme dağıtımları yapan sürekli entegrasyon araçlarını entegre ederek kalite eşiklerini otomatikleştiren CI/CD Kontrolleri bulunur. Bu, yalnızca tanımlı standartları geçen kodların birleştirilmesini sağlar.

GitHub Actions ve GitLab Pipelines gibi platformlar da otomasyona imkân tanır. Bu süreçler, birim testlerini çalıştırma, önizleme ortamlarını oluşturup dağıtma gibi adımları içererek manuel çabayı azaltır ve sorunları erken yakalar.

İncelemeleri optimize etme

Pull request’leri küçük ve odaklı tutun ki hızlı ve kapsamlı şekilde incelenebilsinler. “Neler değişti” ve “Nasıl test edilir” gibi net alanlara sahip şablonlar kullanmak, katkıda bulunanların özlü ve ilgili bilgiler sunmasını sağlar ve incelemeleri verimli kılar.

Ayrıca talimat vermek yerine soru sormanın yapıcı diyalog ve öğrenmeyi teşvik ettiğini unutmayın. İncelemeler için dönüş süreleri belirlerseniz, süreci öngörülebilir tutar ve gecikmeleri önlersiniz.

Metri̇kler ve modern araçlar

Ayrıca darboğazları belirlemek ve iş akışı verimliliğini artırmak için PR boyutunu, inceleme süresini ve birleştirme oranını takip etmenizi öneririm. İncelemeleri ve birleştirmeleri kolaylaştırmak için stacked pull request kullanmayı deneyin. Bu, büyük özellikleri birbirini tamamlayan daha küçük PR’lara bölmeyi sağlar. 

Bunun yanı sıra, pull request kullanırken GitHub Copilot veya CodeWhisperer gibi yapay zekâ araçlarını entegre edebilirsiniz. Bu araçlar potansiyel sorunları erken vurgulamanıza ve düzeltme önerileri almanıza yardımcı olur.

Pull Request’ler ve Merge Request’ler

GitHub ve GitLab’de Pull Request (PR) ve Merge Request (MR) terimleri birbiri yerine kullanılır. Aynı amaca hizmet etseler de her platform bunları farklı şekilde ele alır.

Aşağıdaki tablo, bu farklılıkları vurgulamak için PR ve MR’ları karşılaştırır.

Boyut

Pull Request (GitHub)

Merge Request (GitLab)

Terminoloji

Değişikliklerin çekilmesini talep etme

Değişikliklerin birleştirilmesini talep etme

Birincil Kullanım

Kod değişikliklerini önermek, incelemek ve birleştirmek

Kod değişikliklerini önermek, incelemek ve birleştirmek

Tipik Kullanıcılar

Açık kaynak geliştiricileri, küçük ve orta ölçekli ekipler

DevOps ağırlıklı ekipler, kurumsal yapılar ve özel depolar

CI/CD Entegrasyonu

GitHub Actions (isteğe bağlı, kurulum gerekir)

Varsayılan olarak yerleşik CI/CD

Taslak Desteği

Taslak PR’lar için yerel destek

“Draft” etiketi veya WIP önekleriyle desteklenir

Birleştirme Onayları

Temel inceleyici ve onay ayarları

Gelişmiş kurallar: birden çok onaylayıcı, onay hatları

Birleştirme Stratejileri

Merge commit, squash veya rebase

Benzer seçenekler, yapılandırılabilir birleştirme yöntemi kısıtlamalarıyla

İş Akışı Felsefesi

Geliştirici odaklı, esnek

Geliştirme ve operasyonlar arasında sıkı entegrasyonla DevOps odaklı

Sonuç

Pull request’ler ciddi herhangi bir proje için mutlaka bilinmesi gereken bir konudur. Gördüğünüz gibi (ve umarım artık takdir ediyorsunuzdur) ekiplerin kodu birlikte incelemesine, tartışmasına ve geliştirmesine olanak tanırlar.

Geliştirici olarak becerilerinizi geliştirmeye devam edin. Git ile ilgili her konuda uzmanlaşmak için Git Fundamentals ve GitHub Foundations beceri yollarımıza göz atın.

Allan Ouko

Yazar

Allan Ouko

Veri analitiği, iş zekâsı ve veri bilimi alanlarında pratik deneyime sahip Veri Bilimi Teknik Yazarı. SQL, Python, Power BI, Databricks ve veri mühendisliği üzerine, gerçek dünya analitik çalışmalarına dayanan, uygulamaya dönük ve sektöre odaklı içerikler yazıyorum. Yazılarım teknik derinlikle iş etkisi arasındaki köprüyü kurarak profesyonellerin veriyi güvenle karara dönüştürmelerine yardımcı olur.

Pull Request SSS

Pull request ile merge request aynı şey mi?

GitHub buna “pull request” derken, GitLab “merge request” kullanır; ancak ikisi de aynı görevi yerine getirir.

Pull request’i açtıktan sonra değişiklik yapabilir miyim?

Evet, aynı dala yeni commit’ler push’larsanız pull request otomatik olarak güncellenir.

Bir pull request birleştirildikten sonra dalı silebilir miyim?

Evet, deponuzu düzenli tutmak için pull request birleştirildikten sonra dalı silmeniz önerilir.

Taslak pull request nedir?

Taslak pull request, “devam eden çalışma” niteliğinde bir istektir. Henüz birleştirmeye hazır olmadığınızda ancak erken geribildirim istediğinizde kullanabilirsiniz.

Pull request ile branch arasındaki fark nedir?

Dal (branch) ayrı bir geliştirme çizgisidir; pull request ise o dalın değişikliklerinin başka bir dala birleştirilmesine yönelik resmî bir tekliftir.

Konular

İlgili