Başarılı Bir Git Branch Modeli Nasıl Oluşturulur?

GIT; yazılım geliştirme süreçlerinde kullanılan, hız odaklı, dağıtık çalışan bir sürüm kontrol ve kaynak kod yönetim sistemidir. İlk sürümü Linux Çekirdeği’nin geliştirilmesinde kullanılmak üzere 2005 yılında bizzat Linus Torvalds tarafından tasarlanıp geliştirilmiş, son Eclipse kullanıcı topluluğu anketi verilerine göre 2013 yılı itibariyle %30 pazar payına ulaşmıştır. [1]

Bu yazının konusu herhangi bir projenin detayından bahsedilmesinden ziyade, branch stratejilerinin belirlenmesi ve uygulama release yönetimi üzerine olacaktır.

Neden Git?

Yıllardır geliştiriciler arasında tartışılan konulardan bir tanesi de Git’ in avanatjları ve dezavantajlarıdır. Bu konuda internette pek çok kaynağa rastlayabilirsiniz. Bunlardan bir tanesi ise; https://git.wiki.kernel.org/index.php/GitSvnComparsion

Burada kendi adıma konuşacak olursam, benim için Git aslında bir tercih meselesi olmadı. Ben zaten bu kısa geliştiricilik kariyerim boyunca versiyon kontrol sistemleri arasında doğrudan Git’i kullanmaya başladım. O yüzden Git’ in tercih sebebi, diğer sistemlere göre avantajlı ve dezavantajlı durumlarını kıyaslayamıyorum. Ancak kesin olarak söyleyebilirim ki, Git geliştiricilerin merge ve branch kavramlarına bakış açılarını değiştirdi. İnternetten gördüğüm kadarıyla CVS/Subversion dünyasından gelen geliştiriciler açısından merge ve branch kavramları hep korkutucu olmuştur. Ancak git ile birlikte bu iki kavram oldukça kolaylaşmış ve basitleşmiştir. Bununda doğal sonucu olarak, artık korkulacak kavramlar olmaktan çıkmışlardır.

Bu kadar araçlardan bahsettikten sonra sanırım sıra geliştirme modelinden bahsetmeye geldi. Bu yazı boyunca bahsedilecek model, genel olarak bütün yazılım takımları tarafından kullanılabilecek bir modeldir.

İlk olarak branch modelimizde temel olarak belirlediğimiz noktaya Git kullananların zaten bildiği gibi “origin” olarak isimlendireceğiz. Burada ki en genel kurallardan bir tanesi, her bir geliştirici origin’e push ve pull yapabilir. Bütün bu push-pull ilişkisinin yanında, her bir geliştirici diğer gruplarda ki değişiklikleri alabilir. Yukarıda paylaştığım figürden de anlaşılabileceği gibi, iki veya daha fazla geliştiricinin üzerinde çalıştığı bir özelliğin geliştirilmesi durumunda, değişimlerin origin’ e gönderilmesinden önceki evrelerde böyle bir yaklaşım sergilenebilir.

main branch yapısının oluşturulması

Temel anlamda merkezi repo bu sonsuz yaşam döngüsü boyunca iki ana branch’ den meydana gelir. Bu iki branch sırasıyla master ve develop (dev) olarak isimlendirilir.

origin’ de bulunan master branch’ i bütün Git kullanıcılarına tanıdık gelecektir. Bu master branch’ ine paralel olarak develop veya dev olarak isimlendirebileceğimiz başka bir branch bulunacaktır.

Burada temel anlamda origin/master ana branch olarak düşünülmelidir. Bu branch içerisinde bulunan kaynak kodumuz (HEAD)her zaman için projemizin yayınlanmaya hazır halidir. Diğer branch olan origin/develop ise, geliştirme evresinde olan ve gelecek sürümde yayınlanacak olan projemizin son halinin kaynak kodlarını içerisinde barındırır.

develop branch’ inde bulunan kodun artık tamamen test edilmiş ve düzgün bir şekilde çalıştığına karar verildiği an, develop branch’ i master branch’ ine merge edilmelidir. Burada dikkat etmemiz gereken bir başka önemli durum ise her bir güncellemeden sonra master branch’ de bulunan kodumuzun son halinin tag’ lenmesi olmalıdır.

main branch’i destekleyen branch yapılarının oluşturulması

master ve develop(dev) olarak kullandığımız ana branch yapılarının dışında, geliştirme evresine paralel olacak şekilde destekleyici branch modellerine ihtiyacımız bulunmaktadır. Burada ki temel amaç takım üyelerinin paralel olarak kodlama yapmasının yanı sıra, geliştirilen özelliklerin izlenmesini kolaylaştırmak, gelecek güncellenme versiyonun geliştirilmesini düzenlemek ve uygulamamızın canlı versiyonunda meydana gelen problemleri çözme olarak belirtilebilir.

Bu belirtilen durumlara göre oluşturulması gereken 3 temel branch tipinden bahsedebiliriz.: Feature, Release, Hotfix. Bu belirtilen branch tiplerinin her birinin kendi amaçları vardır. Teknik bakış açısından uzaklaşarak bakacak olursak, bu branch isimlenlendirmelerin tek bir anlamı vardır. O da yapılması gereken task’ ın amacıdır. Bu branch türlerinin hepsinin kısıtlı bir yaşam döngüsü bulunmaktadır.

Feature branches

Feature branch uygulamamızın gelecek versiyonunda eklemeyi plandığımız özellikleri geliştiriğimiz branch modelidir. Feature branch kesinlikle develop (dev) branch’ inden çıkmalı ve tekrardan işlem tamamlandıktan sonra develop(dev) branch’ine merge edilmelidir. Kısıtlı bir yaşam döngüsüne sahip olan bu branch modeli, kesinlikle develop reposunda bulunmalıdır.

Bu branch modelinin bir başka yararlı durumu ise, burada geliştirilen yapılar sonuçta bir nevi deneme amaçlı olduğundan, sonuçta ortaya çıkan ürün veya özellik beklenileni vermediğinde veya proje yöneticileri tarafından iptal edildiğinde projenin orjinal yapısı bundan etkilenmemiş olacaktır.

Release branches

Release branch modeli ise, gelecek versiyonda yayınlacak yeni güncellemeyi desteklemek amacıyla kullanılır. Bu branch içerisinde son minor bug fix’ ler, güncelleme için meta-data’ ların hazırlanması vb durumlar gerçekleştirilir. Bu branch modeli develop(dev)’ den çıkar ve tekrardan develop(dev) veya master’ a merge edilebilir.

Hotfix branches

Bu branch modeli de release branch yapısına benzemenin yanında, canlı uygulama da bulunan kritik bir bug’ u çözmek amacıyla oluşturulur ve ilgili tag numarasından çıkar ve geri merge edilir.

Bu branch modelinin en önemli yararı diğer geliştiriciler develop branch’ inde geliştirmeye devam ederken, bir başka geliştirici ise bu bug çözümünü yapabilir.

Branch isimlendirme modeli nasıl olmalıdır?

Bahsedilen branch modellerinden yola çıkarak release branch modeline uygun branchler için release-*, hotfix branch modeline uygun branchler için hotfix-* gibi bir isimlendirme yöntemi izlenebilir. Bu ikisinin dışında feature branch modeline uygun branchler için, master, develop, release-*, or hotfix-* dşında ekip içerisinde belirlenen herhangi bir isimlendirme yöntemi kullanılabilir. Burada öneri olarak sunabileceğim yöntem ise task_no/geliştirici_adi/task_min_des şeklinde kodlanabilecek bir yapıdır.

Sonuç olarak,

Bu yazı boyunca anlatılan branch model yapısı geliştiriciler için daha anlaşılabilir bir uygulama geliştirme süreci oluşturacaktır.

Kaynak:

[1] http://tr.wikipedia.org/wiki/Git_%28yaz%C4%B1l%C4%B1m%29

Bu yazı yazılırken http://nvie.com/posts/a-successful-git-branching-model/ temel alınmıştır.