Yazılımcıların olmazsa olmazlarından biri de versiyon kontrol sitemlerinden biri olan git. Küçükten projelerden büyük hacimli projelere kadar uygulama kodlarınızı verimlilikle idare etmek için kullanıyoruz. Tabii git kullanırken de Git-flow, Github Flow ve Trunk-Based Development gibi farklı yöntemler branch yönetimini oldukça kolaylaştırıyor. Farklı branch’lerde yaptığınız değişiklikleri merge veya rebase ile ana branch’lerinize (dev, master, main vb.) birleştirip hayatımıza devam edebiliyoruz. Buraya kadar herşey çok güzel!
Peki ya hemen canlıya çıkılması beklenmeyen ama çok sayıda developer’ın katkıda bulunduğu feature’lar ne olacak? Hem de belki birkaç ay sonrasına çıkılmasını planlanan işler.
Burada long-lived Git branches yani uzun ömürlü branch’ler karşımıza çıkıyor. Bundan mümkün mertebe kaçınmamız gerekiyor. Zararlarına geçmeden önceden nasıl kaçınabiliriz ona göz atalım.
Toggle Kullanımı
Yaşam süresi uzun branch’lerden kaçınmanın en doğru ve akıllıca yöntemi uygulama içinde toggle kullanmak. Biraz tecrübe ve dikkat isteyen bir iş olsa da günün sonunda sizi saatlerinizi belki de günlerinizi karmaşık merge operasyonlarından kurtaracak bir yöntem.
Yeni feature’ın içerdiği kontrolü properties dosyasında bir toggle’a bağlayın ve toggle’ın deaktif (false) olduğundan emin olun. Geliştirmesi tamamlanmamış yarım işlerin canlıya çıkmasını istemezsiniz.
Bu yöntemle hali hazırda geliştirdiğiniz ya ad fix’lediğiniz diğer işleri de uzun ömürlü bu feature’da test etme imkanınız olacak. Sadece bir parametreyi değiştirerek yeni feature’ı test etmeniz mümkün. Ayrıca paketi canlıya çıktığınızda bazı sebeplerden dolayı geliştirmeleri geri almak istediğinizde true olan bir parametreyi false’a çekmek yeterli olacaktır.
Uzun ömürlü branch’leri toggle’la çözmek mümkün görünmüyor. O zaman bu zorlukla da nasıl daha iyi savaşabiliriz.
Sık sık merge/rebase almak
Şöyle ki ana branch’inden aldığınız yeni feature’ın geliştirmelerini yaparken belli aralıklarla dev branch’inden merge -daha temiz bir history için rebase öneririm- almanız gerekiyor. Uzun süre merge almadığınız durumda büyük conflict’ler yaşamanız mümkün. Ayrıca conflict aldığınız takım arkadaşınızla pair programing ya da code review yaparken sorunları çok daha hızlı çözebilirsiniz. Çünkü conflict olunan yerde takım arkadaşınız geliştirmeleri yeni yaptığından ilave bir adaptasyon süresinden kurtulmuş olursunuz.
Burada dikkat çekilmesi gereken bir konu da mümkün mertebe büyük refactor’lerin yeni gelişmekte olan branch’e değil de dev’de yapmanız ve üzerinde çalıştığınız branch’e merge etmeniz. Böylece yaptığınız değişiklikler yakın zamandaki bir release’de test edilecek ve uzun süreli feature’ların olduğu branch dev’e merge edildiğinde test maliyetlerini oldukça düşürecektir.
Eğer code review süreçlerini iyi yönettiğiniz bir takımınız varsa 2. yöntemi öneremeyeceğim. Çünkü code review’ları ana branch üzerinden yapılması daha doğru olacaktır. Uzun ömürlü branch’iniz için de PR (pull-request) açarsanız -ki bu önerilen birşey değil- maliyetler giderek katlanacaktır.
Uzun ömürlü branch’lerden kaçınmanın diğer bir faydası da eğer Jira gibi araçların kullanımında kod takibinin de kolayca yapılabilmesi. Jira maddeleriyle eşleştirdiyseniz commit’lerinizi oradan her iş için ayrı ayrı hangi geliştirmelerin yapıldığını rahatlıkla takip edebilirsiniz. Bunu aşmak için de uzun ömürlü branch’lerden başka bir branch oluşturmak. Bu sadece sorunları hasır altı etmeye yönelik bir hareket olur.
Kısaca uzun ömürlü branch’lerden kaçabildiniz kadar kaçın onun yerine toggle kullanın. Toggle kullanımının mümkün olmadığı ve birden fazla uzun ömürlü branch’lerin olduğu yerde feature branch’inize ana branch’ten sık sık merge/rebase alın.
