Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
Henüz base branch'e eklenmemiş değişiklikleri ekip için adreslenebilir ve güncellenebilir bir öneriye dönüştürür. Böylece ekip hangi commitlerin ve dosya farklarının önerildiğini görebilir, bağlamı konuşabilir ve merge kararını ayrı olarak verebilir. Onay koşulları ve merge sonucu repository ayarlarına ve ekip sürecine bağlıdır.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-002'de branch'ini uzak repository'ye gönderdikten sonra head olarak kendi branch'ini, base olarak değişikliğin eklenmesini istediğin hedef branch'i seçersin.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Commit listesini ve dosya farklarını kontrol eder, değişikliğin nedenini açıklayıp Pull Request'ı açarsın. Daha sonra aynı head branch'e gönderdiğin yeni commitler açık öneriyi günceller. Review sırasında değişiklik istenirse ne yapacağın SCN-003'ün konusudur.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “PR'ın base branch'ini ve değişen dosyaları tekrar kontrol et; sonra review'a açabiliriz.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: PR, base branch, head branch, draft, open, merged ve closed ifadelerini GitHub bağlamında tanır.
- Açıkla: Pull Request'ın branch ve commitlerden yararlanan fakat Git'in kendi nesnesi olmayan bir değişiklik önerisi olduğunu açıklar.
- Uygula: Doğru base/head aralığını seçer, commit ve diff kapsamını kontrol eder, niyeti açıklayan temel bir Pull Request hazırlar.
- Şimdilik bilmesi gerekmeyen: Branch protection yönetimi, merge queue, approval policy tasarımı ve merge stratejisi seçimi.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Git, branch'leri ve commit history'sini yönetir; fakat değişikliğin neden önerildiğine ilişkin bir Pull Request kaydı oluşturmaz.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
GitHub bu amaçla açıklama, konuşma, commitler, dosya farkları ve kontrolleri aynı işbirliği yüzeyinde toplar. Başka platformlar benzer ihtiyacı farklı ad ve davranışlarla karşılayabilir.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
GitHub kullanan ekipler bir değişikliği merge öncesinde görünür kılmak, bağlamını tek yerde konuşmak ve sonraki commitleri aynı öneri üzerinde izlemek için Pull Request kullanabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Bu yöntem bütün Git kullanan ekipler için zorunlu değildir. Örneğin GitLab benzer işbirliği kaydı için Merge Request terimini ve source/target branch ifadelerini kullanır.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Pull Request değişiklik bağlamını görünür kılar; aynı zamanda inceleme ve koordinasyon için zaman gerektirebilir. Uygun kapsam, reviewer sayısı, zorunlu kontroller ve merge yöntemi ekip ile repository ayarlarına göre değişir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Draft durumu ile merge, squash veya rebase seçenekleri GitHub'ın sunduğu davranışlardır; Git'in bütün ekipler için zorunlu tuttuğu bir politika değildir.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- Pull Request bir Git komutu veya Git object türü değildir.
- Pull Request açmak değişikliği otomatik olarak merge etmez.
- Pull Request tek bir commit değildir; head branch'e eklenen birden fazla commit aynı öneride görünebilir.
git pullile Pull Request aynı işlem değildir.- Pull Request ile Code Review aynı kavram değildir; review, Pull Request üzerinde yürüyebilen etkinliklerden biridir.
Merge Requestbaşka bir platformun terimidir; GitHub arayüzündeki kanonik adPull Requestolarak korunmalıdır.
Gerilim ve çözüm1. bölüm
