Git yapılandırma yönetimini iyi yapmanın yolları

1. Tek bir branch stratejisi belirleyin

   • Farklı uzmanlık alanlarına sahip ekip üyeleri birlikte çalıştığında iş akışı yaklaşımları çakışabilir
   • Bunu önlemek için lider, tek bir branch stratejisi oluşturup bunu herkese yaymalıdır
   • Branch iş akışına karar vermek ekip büyüklüğü, deneyim seviyesi, ölçeklenme gereksinimi ve iş kısıtları gibi çeşitli etkenlere göre değişebilir
   • Geliştirme ekibi önceden belirlenmiş bir iş akışını izleyebilir, ancak ekip ihtiyaçlarına uygun bir iş akışı da oluşturabilir
   • İş akışının kapsadıkları
     • Merkezi iş akışı: Tek bir depo ve tek bir master branch vardır. Değişikliklerin üzerine yazılma riski bulunur
     • Feature branch: Her yeni özellik eklendiğinde yeni bir branch oluşturulur. Özellikle ilgili commit'ler o feature branch'e yapılır
     • Git Flow: Feature branch'in uç bir biçimidir. Git Flow kullanılan geliştirmede master'a ek olarak ayrı bir development branch bulunur. Feature, release ve hotfix branch'lerini destekler. Geliştirme development branch'inde yapılır, ardından release branch'ine taşınır ve master branch'e merge edilir
     • Task-branch geliştirme: GitLab Flow, bu geliştirme türüne bir örnektir. Özellik odaklı geliştirmeyi, feature branch'i issue tracking ile birleştiren bir yapıyla sunar. GitLab Flow, staging, prodüksiyon testi ve prodüksiyon gibi farklı ortamları ayrı özel branch'lerle yönetir. Commit edilen değişikliklerin tüm ortamlarda test edilmesini sağlar
   • İş birliğine etkileri:
     • Herkes aynı iş akışında uyum içinde çalıştığında kodun üzerine yazma ya da master branch'i bozma ihtimali azalır
     • Tüm çalışanlar geliştirme ve dağıtım süreçlerine aşina hale geldiğinde ekip üyeleri birbirlerinin çalışmalarına daha kolay katkı sağlar
     • Net ve sade bir branch stratejisi, yeni kodun merge edilmesi ve projenin ilerlemesi için olumlu bir döngü yaratır
     • Böyle bir ortam, ekip üyelerinin toplantı düzenlemesine, son tarihleri ve iş yükünü yönetmesine yardımcı olur
     • Her iş akışının iş birliğine etkisi
       • Merkezi iş akışı: İki geliştiricinin aynı kod üzerinde aynı anda yinelenen çalışma yapmaması için iyi iletişim kurabilen küçük ekipler (5 geliştiriciden az) için etkilidir
       • Feature branch ve GitFlow: Daha fazla code review, push kuralları, code owner'lar ve daha kapsamlı testler gerektirerek farklı ekipleri birbirine bağlar
       • Task-branch geliştirme: Ekip üyelerinin gereksinimleri task branch'lere taşınan küçük özellik parçalarına ayırmasını sağlar. Bu iş akışı, code snippet, code review ve unit test gibi iş birliği uygulamalarını içerir. Test başarısız olduğunda ekip üyeleri neyin yanlış gittiğini anlamak için birlikte çalışır

2. Küçük parçalar halinde sık commit yapın

   • Mükemmelliği önceliklendirmek, yalnızca proje neredeyse tamamlandığında büyük ölçekli commit'ler yapmaya yol açabilir
   • Basit özellik doğrulamalarını ve küçük adımları atlarsanız hatalı işlevler geliştirebilir, yanlış yönde zaman harcayabilirsiniz
   • Çalışan testleriniz ve kodunuz oldukça commit yapın
   • Projeyi küçük adımlara indirgemeli ve sık commit'lerle büyük hedefe ulaşmanın yolunu bulmalısınız
   • İş birliğine etkileri:
     • Sık commit kültürü oluştuğunda herkes kod deposunda görünürlük kazanır ve diğer ekip üyelerinin ne yaptığını kolayca görebilir
     • Feature branch veya merge request üzerinden iş paylaşmak, diğer ekip üyelerinin aynı işi tekrar yapmasını önleyebilir
     • Henüz incelemeye hazır olmasa bile feature branch'e sık sık push yapılmalıdır
     • İş tamamlanmadan paylaşılması, tartışma ve geri bildirimi canlandırır; böylece code review öncesinde bile kalite artırılabilir
     • İşi birden fazla commit'e bölmek, geliştiricilerin ve diğer ekiplerin gelecekte kodu incelerken kullanabileceği faydalı bilgiler sağlar
     • Bir özelliğin nasıl geliştirildiği commit bazında açıkça izlenebilir
     • İlgisiz değişiklik geçmişini olduğu gibi bırakıp istenen belirli bir noktaya rollback yapılabilir veya yalnızca belirli kod değişiklikleri seçici olarak geri alınabilir

3. Ayrıntılı commit mesajları yazın

   • Commit mesajı yalnızca commit'in içeriğini değil, geliştiricinin niyetini de yansıtmalıdır
   • Commit mesajı, değişikliğin neden yapıldığını açıklamalıdır
   • İyi bir commit mesajı örneği: “Kullanıcı ekranındaki tekrar eden kodu azaltmak için şablonları birleştirdim”
   • Commit mesajlarında geçen “değişiklik”, “iyileştirme”, “düzeltme”, “yeniden yapılandırma” gibi sözcükler faydalı bilgi vermez
   • İş birliğine etkileri:
     • Ayrıntılı commit mesajları şeffaflığı artırır ve ilerleme görünürlüğü sağlayarak ekip arkadaşlarının, müşterilerin ve gelecekte katkı sunacak kişilerin geliştirme sürecini anlamasına yardımcı olur
     • Code review sırasında commit mesajları, tekrar eden prosedürlerin izlenmesine ve release, mutabakat veya gereksinim değişikliklerinden sonra ortaya çıkan farklılıkların görülmesine yardımcı olur
     • Ayrıntılı commit mesajları, QA ve güvenlik ekiplerinin kodu incelerken sorunlu alanları belirlemesine ve belirli değişiklikleri geri almasına yardımcı olur
     • Commit mesajlarını ayrıntılı yazmak, diğer ekip üyelerinin yinelenen iş yapmasını önler, iş gecikmelerini en aza indirir ve proje ilerleyişini istikrarlı tutar

4. Geliştirme için branch kullanın

   • Bir branch'te geliştirme yapmak, belirli bir andaki durumu o branch üzerinde kopyalayıp çalışmak gibidir
   • Branch kullanarak ana codebase'i etkilemeden kod değişiklikleri yapabilirsiniz
   • Değişiklik geçmişi branch içinde yönetilir
   • Kod hazır olduğunda master branch'e merge edilebilir
   • Branch üzerinde kod yazmak, geliştirmeye daha sistematik bir yaklaşımla ilerleme imkanı verir
   • Geliştirme aşamasındaki taslakları, istikrarlı testlerden geçmiş master kodundan ayrı tutup yönetebilirsiniz
   • İş birliğine etkileri:
     • Ekip üyelerinin karmaşık sorunları çözmek için yenilikçi çözümler ve deneyler denemesine olanak tanır
     • Geliştirme ekibi, master branch'i etkileme kaygısı olmadan yaratıcı denemeler yapabilir
     • Çözümün düzgün çalıştığını doğrulamak için master branch'e merge etmeden önce birlikte çalışabilirler
     • Operasyon, QA ve güvenlik ekipleri dağıtımdan önce kodu inceleyebilir; tüm üyelerin release öncesinde fikir sunma ve olası sorunları tartışma fırsatı olur

5. Düzenli code review yapın

   • Sürekli iyileştirmeyi güvence altına alır ve istikrarsız kodu önler
   • İncelenecek kod oluştuğunda, projeyi iyi bilen bir meslektaştan, ekip üyesinden veya ilgili alan uzmanından code review istenmelidir
   • Code review yaparken dikkat edilmesi gerekenler:
     • Hangi değişikliklerin gerektiğini açıklayın
     • Alternatifler sunun, ancak geliştiricinin bunları zaten değerlendirmiş olabileceğini varsayın
     • Sorun çözme sürecinde de kodu sadeleştirmenin yolları aranmalıdır
   • İş birliğine etkileri:
     • Code review, sorun çözümü ve uygulama konusunda farklı bakış açıları sunar
     • Hataları, mantık sorunlarını veya olası corner case'leri yakalayan ek bir göz olur
     • Zor meseleler aşılırken ve release'e ilerlenirken ortaya çıkabilecek sorunları hafifletir
     • Çözüm yolları gözden geçirilebilir, görüş paylaşılabilir ve ekip üyeleri birlikte review yapabilir
     • Farklı kodlama yöntemleri, iş akışı pratikleri ve yeni problem çözme yaklaşımları öğrenilebilir