Merge ve PR Politikası

Merge Politikası

Merge işlemi, yeni özelliklerin veya hata düzeltmelerinin ana branch'lere entegre edilmesi sırasında dikkatli bir şekilde yönetilmelidir. Aşağıda merge politikası ile ilgili detaylar verilmiştir:

• Pull Request (PR) Açılmadan Merge Yapılmamalıdır: Herhangi bir feature (özellik) veya bugfix (hata düzeltme) branch'i, development veya main (veya master) branch'lerine merge edilmeden önce bir PR açılmalıdır. PR, merge işlemi öncesinde bir kod inceleme sürecinin tamamlanmasını sağlar.

• Kod İncelemesi ve Onay: PR açıldığında, en az bir takım üyesi tarafından incelenmeli ve onaylanmalıdır. Bu, kodun kalite standartlarına uygun olup olmadığını kontrol etmek ve olası hataları önceden tespit etmek için önemlidir. Kod inceleme süreci, kodun anlaşılırlığını, sürdürülebilirliğini ve projenin genel yapısına uyumunu değerlendirir.

• Test Senaryolarının Doğrulanması: PR sırasında yapılan değişikliklerin, ilgili test senaryoları ile birlikte doğrulanması gerekmektedir. Bu, yapılan değişikliklerin mevcut sistemde herhangi bir olumsuz etkiye yol açmadığını garanti altına alır. Özellikle main veya production branch'lerine yapılan merge işlemleri öncesinde, tüm testlerin başarılı bir şekilde tamamlanmış olması zorunludur.

• Yönetici Onayı: development, test ve production branch'lerine yapılacak olan merge işlemleri, yalnızca yönetici onayı ile gerçekleştirilebilir. Bu, özellikle kritik sistemlerde kod kalitesini ve güvenliğini sağlamak için önemlidir.

PR Süreci

PR süreci, yeni kod değişikliklerinin ana branch'lere entegre edilmeden önce dikkatli bir inceleme sürecinden geçirilmesini sağlar. PR süreci aşağıdaki adımları içerir:

1. Yeni Branch'inizi Oluşturun:

   • Yeni bir özellik geliştirmek veya bir hatayı düzeltmek için, development branch'inden bir branch oluşturun. Bu branch, yapacağınız değişikliklerin izole edilmesini sağlar.

   • Örnek:

     git checkout -b feature/login-page development

2. Değişikliklerinizi Yapın ve Commit Edin:

   • Branch üzerinde gerekli değişiklikleri yapın ve bu değişiklikleri Conventional Commits kurallarına uygun olarak commit edin. Commit mesajları, yapılan değişikliklerin ne olduğunu ve neden yapıldığını net bir şekilde ifade etmelidir.

   • Örnek:

     git commit -m "feat: kullanıcı giriş sayfası eklendi"

3. Değişikliklerinizi Remote Branch'e Push'layın:

   • Yapılan değişiklikleri remote repository'ye push'layın. Bu, diğer ekip üyelerinin değişikliklerinizi incelemesine olanak tanır.

   • Örnek:

     git push origin feature/login-page

4. GitHub/GitLab Gibi Bir Platformda PR Açın:

   • Remote branch'e push'ladıktan sonra, GitHub, GitLab veya benzeri bir platformda PR açın. PR açıklamasında, yapılan değişikliklerin amacını, hangi dosyaların değiştirildiğini ve bu değişikliklerin projeye nasıl katkıda bulunduğunu belirtin.

   • PR açıklamasında şunlara dikkat edin:

     • Amaç: Değişiklik neden yapıldı? (Örneğin, yeni bir özellik eklemek, bir hatayı düzeltmek veya performansı artırmak için)

     • Değişiklikler: Hangi dosyalar ve kod bölümleri değiştirildi?

     • Test Durumu: Değişiklikler test edildi mi? Testlerin sonuçları nedir?

     • Bağlantılar: İlgili iş takip sistemi kartları veya diğer referanslar.

5. PR'ın Kod İncelemesini Tamamlayın:

   • PR açıldıktan sonra, diğer ekip üyeleri veya yönetici tarafından kod incelemesi yapılır. İnceleme sırasında, kodun genel yapıya uyumu, anlaşılabilirliği, performansı ve güvenliği değerlendirilir. Kod inceleme sürecinde yapılan geri bildirimler, kodun iyileştirilmesine yardımcı olur.

6. PR Onaylandıktan Sonra Branch'i Ana Branch'e Merge Edin:

   • PR süreci tamamlandıktan ve tüm incelemeler yapıldıktan sonra, branch'i development veya main branch'ine merge edin. Merge işlemi, yapılan değişikliklerin ana kod tabanına entegre edilmesi anlamına gelir.

   • Örnek:

     git checkout development git merge feature/login-page

PR Sürecinde Dikkat Edilmesi Gerekenler

• Kod Kalitesi: PR açılmadan önce kodun belirli kalite standartlarına uygun olduğundan emin olun. Kodun anlaşılabilir, sürdürülebilir ve projeye uygun olması gerekir.

• Geri Bildirimlere Açık Olma: Kod inceleme sürecinde gelen geri bildirimlere açık olun. Bu geri bildirimler, kodunuzu iyileştirmenize ve daha iyi bir sonuca ulaşmanıza yardımcı olabilir.

• Testlerin Başarıyla Geçmesi: Değişikliklerin tüm ilgili testlerden geçtiğinden emin olun. Testler başarısız olursa, bu sorunlar düzeltilene kadar merge işlemi yapılmamalıdır.

• Dokümantasyon: Yapılan değişikliklerle ilgili dökümantasyonun güncel olduğundan emin olun. Özellikle yeni özellikler eklenmişse veya mevcut işlevsellikte büyük değişiklikler yapılmışsa, dökümantasyonun bu değişiklikleri yansıtması gerekir.

PR ve Merge Politikalarının Faydaları

• Kod Kalitesini Artırır: PR süreci, kodun birden fazla göz tarafından incelenmesini sağlar. Bu, kodun kalitesini artırır ve olası hataları önceden tespit eder.

• İşbirliğini Teşvik Eder: PR'lar, ekip üyeleri arasında işbirliğini teşvik eder. Herkes, projeye katkıda bulunabilir ve birbirlerinin çalışmalarını destekleyebilir.

• Proje Yönetimini Kolaylaştırır: PR ve merge politikaları, proje yönetiminin daha düzenli ve öngörülebilir olmasını sağlar. Bu politikalar, sürüm kontrolünü ve yazılımın genel kalitesini artırır.

• Geriye Dönük Takip Edilebilirlik: PR süreçleri, yapılan her değişikliğin neden ve nasıl yapıldığını geriye dönük olarak takip edebilme olanağı sağlar. Bu, özellikle büyük projelerde önemli bir avantajdır.

Bu detaylı açıklamalar, Merge ve PR politikasını kapsamlı bir şekilde ele alır ve sürecin nasıl yönetilmesi gerektiğine dair ayrıntılı bilgi sağlar. PR sürecinin adımları, dikkat edilmesi gereken noktalar ve bu sürecin proje yönetimine katkıları hakkında bilgiler sunulmuştur.