Git versiyonlama sistemi kullanılan yazılım projelerine katkıda bulunurken genellikle main (stable, master, dev vs.) branşına doğrudan commit atmayız. Onun yerine yaptığımız değişiklikleri içeren bir Pull Request (PR) göndeririz. Bu PR ile repo sahibinden kodumuzu değerlendirmesini (code review), varsa değişiklikleri bildirmesini (request changes), yoksa da değişiklikleri kabul etmesini yani hedefteki branş ile birleştirmesini (merge) talep ederiz.
Pull Request (PR): Contributions to a source code repository that uses a distributed version control system are commonly made by means of a pull request, also known as a merge request. The contributor requests that the project maintainer pull the source code change, hence the name “pull request”. The maintainer has to merge the pull request if the contribution should become part of the source base.
Açık kaynak ve Github (Gitlab, Bitbucket…) dünyasına ilk kez adım atan yazılımcılar bir projeye katkıda bulunmak için büyük bir heyecanla gözlerine kestirdikleri projeyi kendi hesaplarına çekiyor (fork), istedikleri değişiklikleri yapıyor ve değerlendirilerek kabul edilmesi için PR gönderiyorlar. Peki sizce sonuç ne oluyor? Çok büyük ihtimalle red (reject)! Peki neden sorusunun cevabını aşağıdaki maddelerde bulabilirsiniz.
1. Ön bilgilendirme yapın ve onay alın
Sürekli kullandığınız açık kaynak projede bir bug tespit ettiniz diyelim. İlk yapmanız gereken şey tespit ettiğiniz bu bug ile ilgili bir issue açmaktır. Bu issue’da bug’ın hangi süreçleri takip etmeniz sonucunda ortaya çıktığını bildirir ve muhtemel çözüm metodunu sunarsınız. Issue’nun sonunda da uygun görülmesi halinde bu konu üzerinde çalışmak istediğinizi belirtirsiniz.
Repo sahibi issue’yu değerlendirir ve teklif ettiğiniz çözümü uygun görürse bu konunun atamasını size yapar (assign). Buradaki assign işleminin amacı başka geliştiricilerin de aynı konu üzerinde çalışıp zaman kaybetmesini önlemektir.
Meselenin esas konumuz olan PR ile bağlantısına gelirsek, herhangi bir issue’ya dayandırılmayan, repo sahibi tarafından onay alınmadan ve görevlendirilmeden yapılan PR’ların kabul edilmesi çok zordur.
2. Her PR’ın tek amacı olmalı
İlk aşama olan issue açma ve görevlendirilme işini tamamladınız diyelim. Bu dakikadan itibaren artık kodda yapacağınız değişikliğe odaklanabilirsiniz. Burada ilk dikkat etmeniz gereken husus her PR’ın tek bir amacının olmasıdır. Issue’da görevlendirildiğiniz konu dışında değişiklik yapmaktan kaçınmalısınız.”Yapmışken şunu da yapayım” dediğiniz anda karanlık tarafa geçmeye başladınız demektir.
3. Repo sahibini ürkütmeyin
PR içerisinde yapmış olduğunuz değişiklikler en fazla iki veya üç dosyayı içermelidir. Satır sayısı olarak da 20, 30’u aşmamanızı tavsiye ederim. Elbette bunlar çok genel rakamlar, issue’ya göre mutlaka değişir ancak konunun özü aynı. Kötü bir örnek sunmak gerekirse; resimdeki gibi 40 dosya değişikliği, 1468 yeni ekleme, 744 silme bulunan bir PR’ın hiç okunmadan reddedileceğinin garantisini verebilirim.
Esasında burada kendinizi repo sahibi yerine koymalısınız. Özel bir yaşamınız, aileniz ve işiniz var, zamanınız da kısıtlı ve bu kısıtlı zamanda açık kaynak projeniz ile ilgileniyorsunuz. Siz olsanız verdiğim kötü örnekteki PR’ı kabul eder misiniz? Aslında okur musunuz diye sormalıyım.
4. Testi olmayan kod göndermeyin
Yapmış olduğunuz değişiklik kod olarak düzgün görünüyor olabilir ancak test yazmadan doğru bir şekilde çalıştığından emin olmak mümkün değildir. Bu nedenle mutlaka PR’ınızda testlerinizin de bulunmasına dikkat edin. Hatta çoğu katkı (contribution) süreçlerinde özellikle PR gönderildiği anda tüm testler çalıştırılır ve eğer testleri başarıyla geçiyorsa PR incelenmek üzere kabul edilir.
5. Dokümantasyon yazın
Nasıl ki testler günümüzde her projenin olmazsa olmazı ise, dokümantasyon da aynı şekildedir. Bu nedenle gönderdiğiniz PR’ın içinde mutlaka dokümantasyon güncellemesine de yer verin. Basit ancak hep atlanan bir husus olarak sırf bu yüzden PR’ınızın beklemesi can sıkıcı olabilir.
6. Commit’lerinize dikkat edin
Commit konusu biraz uzun olduğu için başka bir yazımda değinmeyi düşünüyorum ancak PR ile doğrudan ilgili olduğunu söyleyebilirim. Repo sahibi bazen sadece yazdığınız koda değil, PR’ınızdaki değişiklik sürecine yani commitlerinize bakarak sizin yapmaya çalıştığınız şeyi anlamaya çalışır. Diğer bir deyişle PR’ın hikayesi nasıl bir issue ile başlıyorsa, atmış olduğunuz commit’lerle gelişir. Bu hikayeyi akıcı ve mantıklı kılmak daha sağlıklı bir süreç oluşturmanızı sağlar.
7. Çatışmaları çözün
Siz bug üzerinde çalışırken ana repoda başka değişiklikler yapılıyor olabilir. Bu durumda PR gönderdiğiniz zaman conflict (çatışma) yaşayabilirsiniz. Böyle durumlarda bu çatışmaları çözmek PR’ı gönderen kişinin sorumluluğundadır. Çatışmalar çözülmeden de PR esas kod reposu ile birleşmeyecektir (merge).
8. Her şeyi yaptım, yine de red yedim
Burada bir Code Review sürecinde olduğunuzu bilmeniz lazım. Karşınızda bir insan var ve reposunun kendi istediği şekilde gelişmesini istiyor olabilir. Tüm insanlar code review yazısında anlattığım gibi kibar ve egosuz değildir. Tam aksine acımasızca yorumlar alabilirsiniz. Öyle yorumlar ki sizi yazılıma küstürürler. İşte tam bu noktada pes etmeyenler, yapılan yorumun kendisine değil de koduna yapıldığını bilenler, kodunu daha iyi yazarsa başarıya ulaşacağına inanlar ve inatla, azimle tekrar tekrar deneyenler başarılı olacaktır.
Outliers (Çizginin Dışındakiler) kitabında da yazıldığı gibi;
Başarı, çoğu insanın 30 saniyede vazgeçebildiği bir şeyi anlamak için 22 dakika uğraşacak kadar inatçı, azimli ve istekli olmanın bir işlevi.
