Bir yazılım projesinde zaman içinde yüzlerce, hatta binlerce commit birikir. Bu commit'lerin hepsi geliştirme sürecinin parçasıdır ama hangi commit'in kullanıcıya sunulan bir sürüme karşılık geldiğini anlamak, sadece commit geçmişine bakarak kolay değildir. Git etiketleri (tag) tam olarak bu ihtiyacı karşılamak için vardır. Bu yazıda etiketlerin ne işe yaradığını, nasıl kullanıldığını ve sürüm numaralandırma mantığıyla nasıl bir arada çalıştığını sade bir şekilde ele alıyoruz.
Bir bakışta
- Git etiketleri belirli commit'leri sabit sürüm noktaları olarak işaretleyerek sürüm takibini kolaylaştırır.
- Annotated etiketler tarih, yazar ve mesaj gibi meta veriler taşıdığı için sürüm yönetiminde tercih edilir.
- Etiketler semantik versiyonlama ve değişiklik günlükleriyle birleşince sürüm geçmişi şeffaf ve izlenebilir hale gelir.
Git Etiketi (Tag) Nedir ve Commit'ten Farkı Ne?
Git'te her commit, kod tabanındaki bir değişikliği temsil eder ve geliştirme süreci ilerledikçe sürekli yeni commit'ler eklenir. Bu akış doğası gereği dinamiktir; bir branch üzerindeki commit geçmişi büyümeye devam eder.
Etiket ise bu akışın içinde belirli bir commit'e iliştirilen sabit bir işarettir. Commit'ler "geliştirme sürecinin adımları" ise, etiket "burada bir sürüm yayınlandı" anını işaretleyen bir referans noktasıdır. Bir etiket oluşturulduğunda, o an işaret ettiği commit değişmez; proje ilerlese bile etiket hep aynı noktayı gösterir.
Burada akla gelen doğal bir soru şudur: Neden her commit'i değil de sadece belirli anları etiketliyoruz? Çünkü her commit bir sürüm anlamına gelmez. Bir commit küçük bir düzeltme, deneme amaçlı bir değişiklik veya henüz tamamlanmamış bir özellik olabilir. Etiketleme, "bu noktadaki kod, kullanıcıya sunulmaya hazır ya da resmi olarak yayınlanmış bir sürümdür" demenin bir yoludur. Bu sayede proje geçmişinde sürüm anları, sıradan geliştirme adımlarından ayrışır.
Lightweight ve Annotated Etiket Arasındaki Fark
Git'te iki tür etiket bulunur ve aralarındaki fark, taşıdıkları bilginin miktarıyla ilgilidir.
Lightweight (hafif) etiket, belirli bir commit'e verilmiş basit bir isimden ibarettir. Ek bir açıklama, tarih bilgisi ya da yazar bilgisi taşımaz; sadece bir işaretçi gibi çalışır. Hızlı, geçici referanslar için pratik olabilir ama sürüm yönetimi açısından yeterli bağlam sunmaz.
Annotated (açıklamalı) etiket ise Git veritabanında kendi başına bir nesne olarak saklanır. Etiketi kimin oluşturduğu, hangi tarihte oluşturulduğu ve etiketle birlikte eklenmiş bir mesaj gibi meta verileri içerir. Bu bilgiler, sonradan "bu sürüm ne zaman ve kim tarafından işaretlendi, neden bu sürüm çıkarıldı" sorularına cevap ararken önemli olabilir.
Sürüm yönetimi söz konusu olduğunda genellikle annotated etiketler tercih edilir. Çünkü bir yazılım sürümü sadece bir kod anlık görüntüsü değildir; o sürümün ne zaman ve hangi bağlamda yayınlandığına dair bilgi de değerlidir. Lightweight etiketler daha çok kişisel, geçici işaretlemeler için uygundur.
Etiketlerin Semantik Versiyonlama ile İlişkisi
Sürüm numaralandırmada yaygın kullanılan mantık, major.minor.patch şeklindeki üç parçalı yapıdır. Major kısmı geriye dönük uyumsuz büyük değişiklikleri, minor kısmı yeni özellikleri, patch kısmı ise hata düzeltmelerini temsil eder.
Git etiketleri, bu numaralandırma mantığının kod tabanına yansıtıldığı yerdir. Bir sürüm numarası belirlendiğinde, bu numara doğrudan bir etiket ismi olarak kullanılır. Yaygın bir biçim, sürüm numarasının başına "v" harfi eklenerek v1.0.0, v1.2.3 gibi isimler oluşturmaktır. Bu "v" öneki zorunlu değildir ama pek çok projede sürüm etiketlerini diğer etiketlerden (örneğin geçici test etiketlerinden) ayırt etmeyi kolaylaştırır.
Burada önemli olan nokta, etiketleme biçiminin proje genelinde tutarlı bir sürüm numaralandırma stratejisiyle uyumlu olmasıdır. Eğer proje semantik versiyonlama mantığını benimsiyorsa, etiketlerin de bu mantığı birebir yansıtması beklenir. Aksi halde etiket isimleri ile sürüm numaraları arasında bir kopukluk oluşur ve bu da kafa karışıklığına yol açabilir.
Temel Git Tag Komutlarının Mantığı
Git'te etiketleme işlemleri birkaç temel komutla yürütülür. Burada komutların birebir sözdizimine girmek yerine, mantığını anlamak daha faydalıdır.
Yeni bir etiket oluşturma: Lightweight bir etiket oluşturmak, mevcut commit'e sadece bir isim vermek anlamına gelir. Annotated bir etiket oluşturmak içinse, isimle birlikte bir mesaj da eklenir; bu mesaj genellikle o sürümle ilgili kısa bir açıklama içerir. Annotated etiket oluşturma işlemi, aslında Git'e "bu bir sürüm işaretidir, sadece geçici bir referans değildir" demenin bir yoludur.
Etiketleri listeleme: Bir projede o ana kadar oluşturulmuş tüm etiketleri görmek mümkündür. Bu, projenin sürüm geçmişine hızlı bir bakış sağlar. Belirli bir etiketin detayına bakıldığında ise, eğer annotated bir etiketse, oluşturulma tarihi ve mesajı gibi bilgiler de görüntülenebilir.
Uzak sunucuya (remote) gönderme: Etiketler varsayılan olarak yerel depoda oluşturulur ve normal commit gönderme işlemiyle otomatik olarak uzak sunucuya aktarılmaz. Bunun ayrı bir adım gerektirmesinin nedeni, etiketlerin sürüm anlarını temsil etmesi ve bu nedenle bilinçli bir şekilde paylaşılması gerekmesidir. Bir etiketin uzak sunucuya gönderilmesi, o sürümün artık ekip veya kullanıcılar tarafından erişilebilir hale geldiği anlamına gelir. Bu ayrım, yanlışlıkla yarım kalmış veya test amaçlı etiketlerin herkesle paylaşılmasını önler.
Etiketleri Değişiklik Günlükleri ve Release Notlarıyla İlişkilendirme
Bir etiket, tek başına yalnızca bir sürüm numarasından ibaret değildir; aynı zamanda o sürümde nelerin değiştiğine dair bir referans noktasıdır. İki etiket arasındaki commit farkına bakıldığında, bir sürümden diğerine hangi değişikliklerin yapıldığı görülebilir.
Bu ilişki, değişiklik günlükleri (changelog) hazırlarken doğrudan kullanılabilir bir temel oluşturur. Örneğin v1.1.0 ile v1.2.0 etiketleri arasındaki commit'ler incelendiğinde, bu iki sürüm arasında eklenen özellikler, düzeltilen hatalar ve yapılan değişiklikler bir araya getirilebilir. Etiketler olmadan bu karşılaştırmayı yapmak, hangi commit'in hangi sürüme ait olduğunu manuel olarak takip etmeyi gerektirir ki bu da hataya açık bir yöntemdir.
Bu ilişkilendirme aynı zamanda şeffaflık sağlar. Hem ekip içinde hem de yazılımı kullanan kişilere karşı, "bu sürümde tam olarak ne değişti" sorusuna net bir cevap verilebilir. Release notları, genellikle iki etiket arasındaki farkın okunabilir bir özeti olarak hazırlanır.
Yanlış veya Eksik Etiketlemenin Yol Açabileceği Sorunlar
Etiketleme sürecinin ihmal edilmesi veya tutarsız yapılması, görünürde küçük bir eksiklik gibi görünse de zamanla ciddi sorunlara dönüşebilir.
İlk sorun, hangi commit'in hangi sürümde yayınlandığının karışmasıdır. Etiketler eksik veya yanlış yerlere konulduğunda, geçmişe dönüp "kullanıcıya sunulan sürüm tam olarak hangi kod durumuydu" sorusuna cevap vermek zorlaşır.
İkinci sorun, geri dönüş (rollback) veya hata ayıklama süreçlerinde ortaya çıkar. Üretimde bir sorun tespit edildiğinde, genellikle "bir önceki sağlıklı sürüme dönelim" gibi bir ihtiyaç doğar. Etiketler düzgün tutulmadığında, hangi commit'in o "sağlıklı sürüm" olduğunu bulmak zaman kaybettirici ve riskli hale gelir.
Üçüncü sorun ise otomasyon araçlarıyla ilgilidir. Pek çok CI/CD (sürekli entegrasyon/sürekli dağıtım) sistemi, belirli bir etiket isimlendirme kalıbını tanıyarak otomatik derleme veya dağıtım süreçlerini tetikler. Etiket isimlendirmesi tutarsız olduğunda, bu otomasyon araçları beklenen etiketleri tanıyamayabilir veya yanlış sürümleri işleme alabilir. Bu da sürüm yönetiminin manuel müdahale gerektiren, hataya açık bir sürece dönüşmesine neden olur.
Ekip İçinde Tutarlı Etiketleme Kuralı Oluşturmanın Faydaları
Bu sorunların büyük bir kısmı, aslında baştan belirlenen ve herkesin uyduğu ortak bir etiketleme kuralıyla önlenebilir. Bu kural; hangi biçimde isimlendirme yapılacağını (örneğin v önekli semantik versiyonlama), hangi durumlarda annotated etiket kullanılacağını ve etiketlerin ne zaman uzak sunucuya gönderileceğini net bir şekilde tanımlar.
Böyle bir standardın en somut faydalarından biri, projeye yeni katılan ekip üyelerinin sürüm geçmişini kolayca takip edebilmesidir. Tutarlı bir etiketleme düzeni sayesinde, yeni biri projenin commit ve etiket geçmişine baktığında hangi sürümün ne zaman yayınlandığını rahatça anlayabilir.
Ayrıca, otomatik derleme ve dağıtım süreçleriyle uyumlu bir etiketleme kuralı, sürüm yayınlama sürecinin büyük ölçüde otomatikleştirilebilmesini sağlar. Etiketleme kuralı net olduğunda, bir etiket oluşturulduğu anda ilgili otomasyon sistemleri bunu tanıyıp gerekli derleme, test veya dağıtım adımlarını güvenilir bir şekilde başlatabilir.
Sonuç olarak Git etiketleri, basit görünen ama sürüm yönetiminin temel taşlarından birini oluşturan bir mekanizmadır. Doğru ve tutarlı kullanıldığında hem geliştirme ekibi için hem de yazılımı kullanan kişiler için sürüm geçmişini anlaşılır, izlenebilir ve güvenilir hale getirir.
