Git Tag ile commit’leri Etiketleme

Merhabalar, bir önceki derslerimizde uzak depolarla nasıl çalışılır konusunu işlemiştik. Bu dersimizde git’in temel özelliklerinden birini ‘git tag’ komutu ile commit’leri nasıl etiketleyebilieceğimizi göreceğiz.

Etiketler

Aşağıdaki resimde örnek bir git tag kullanımını görüyorsunuz.

Anlayacağınız gibi c1 den c8 e kadar bir commit sıramız var. 6. commit’e yani c6 da bir v1.0.0 adında bir etiket görüyorsunuz. Aynı şekilde c8‘de de v1.0.1. Kısacası bu projede semantik bir versiyonlama yapılmış. c6 anında 1.0.0, c8 anında ise 1.0.1 versiyonu yayınlanmış.

Detaylara geçmeden önce hemen ‘git tag’ komutunun ne işe yaradığını ve nasıl kullanabileceğimizi görelim.

Git checkout

Önceki derslerimizden hatırlarsanız checkout komutunu görmüştük. Herhangi bir commit’in id’sini parametre olarak verdiğimizde deponun o anki haline dönebiliyorduk. Örneğin chapter3 ü merge ettiğimiz ana geri dönelim.

Git Tag

git checkout komutu herhangi bir commit id’si verdiğinizde o ana geri döner. Bildiğiniz gibi aynı zamanda branch’leri de parametre olarak verebiliyoruz. master‘a geri dönmeden hemen bu commit’i etiketleyelim.

İlk etiketimizi oluşturduk. Artık o ana dönmek için commit id kullanmak yerine doğrudan etiketi kullanabiliriz.

Anladığınız gibi oluşturduğumuz tag chapter3 ü merge ettiğimiz andaki commit’e gitmemizi sağlıyor. Yani eğer tag varsa o commit’in id’sini bulmak zorunda değiliz.

Bu arada etiketler bir commit’i değil aslında o commit’deki deponun durumunu etiketler. Yani yukardaki örnek resimde v1.0.0 etiketi c1 den c6 ya kadar olan bütün commit dizisini etiketler. Depoda c6 commit’lendiğinde dosyalar ne durumdaysa o ana dönmüş olursunuz. Anlamanız açısından etiketleri branch’lerin salt okunur bir türü olarak da düşünebilirsiniz.

Git Yardım Menüsü

Git de herhangi bir komutun dökümanına ulaşmak isterseniz git help <komut>komutunu çalıştırabilirsiniz. Örneğin git tag için

• Depoda kayıtlı tag’leri listelemek için git tag -l ya da git tag --list
• Bir tag’i depodan silmek için git tag -d <tag-adi>

gibi komutları kullanabilirsiniz.

Etiketleri Push’lamak

git push komutunu kullansanız da tag’lerin uzak depoya gitmediğini farketmişssinizdir. Bunu bulmanız zor değil. İpucu: git help push

Etiketlerin Kullanım Alanları

Muhtemelen bu soruyu siz de sormuşsunuzdur. Neden git tag kullanmalısınız? Tahmin ettiğiniz gibi en önemli sebep projenin güncel versiyonu dışında geçmişe dönebilmektir. Özellikle büyük bir projede günde herkesin sürekli commit yaptığı bir depoda bir commit’i aramak samanlıkta iğne aramaya benzer. Sizin için önemli olabilecek bir commit’i etiketleyip o ana geri dönebilmeyi kolaylaştırabilirsiniz. Tabiki verdiğiniz etiketin adı ve mesajı da önemlidir. Aklıma gelen bazı senaryoları örnekleyelim:

• Ticari veya Teknik hatalar: Bir projede geliştirilen güncel versiyonda işler yolunda gitmeyebilir. Bunun sebebi ticari olabileceği gibi teknik de olabilir. Bu genelde küçük veya orta ölçekli projelerde olur. Geriye dönüp geliştirmeye ordan devam edebilirsiniz.

• Eski kod üzerinde çalışmak: Projede bir değişiklik yaptınız ve üzerinden zaman geçti. Günün birinde geriye dönüp acaba burda nasıl bir implementasyon yapmıştık ya da başkası soruna nasıl yaklaşmış yine tag ile geriye dönüp bakabilirsiniz. Burdaki en büyük olay bunu zamanında buraya dönüp bakabilirim diye düşünüp etiketi yapıştırmak. Projenizde çok önemli ve birçok yeri etkileyen kodunuzun kalitesini arttıracak veya yeni bir uygulama çatısına geçiş yaptınız diyelim ve aradan uzun bir zaman geçti. Geriye dönmek istediğinizde oluşturduğunuz etiket size yardımcı olacaktır.

• Versiyonlama: Bir yazılım geliştiriyorsanız mutlaka o yazılımın yeni ihtiyaçları yeni özellikleri yani yeni bir versiyonu olacaktır. Örneğin semantik versiyonlama yapıyorsanız 1.0.1, 2.25.123 gibi versiyonlarınız olacaktır. Ya da tarih bilgisini versiyon olarak kullanabilirsiniz. Her versiyona yeni bir tag eklemek işinizi oldukça kolaylaştıracaktır. Gitlab, Github gibi sistemlerde ilgili etikete derlenmiş dosyaları da ekleyip diğer geliştiricilere sunabilirsiniz. On-premise tarzı bir ürün kullanıyorsanız. Hata bildirimi aldığınızda geriye dönüp onu düzeltme zamanınız oldukça hızlanacaktır. Yukardaki grafikte oluşturulan iki etiketi görebilirsiniz.

• Müşteriye özel versiyon: Diyelim ki on-premise bir ürün geliştiriyorsunuz. Müşteri de size gelip sizden kendisine özel bir özellik geliştirmenizi istedi. Bunu yaptınız ve müşteriye teslim ettiniz. Fakat aradan bir süre geçtikten sonra müşteri bir problem yaşadığını size bildirdi. Etiketi kullanarak geriye dönüp müşterinin o sorununu çözmeniz daha kolay olur. Teslim ettiğiniz yeni versiyonu da etiketlemeyi unutmayın. Farklı bir senaryo müşteriye özel bir versiyon verdiniz ama aynı zamanda müşteri yeni çıkardığınız son özellikleri de istedi. Etiketler burda da işinize yarayacaktır. Bu tür senaryolarda branch oluşturmak da bir yöntem olabilir. Bu konuya değineceğiz.

İşin özeti geriye dönmek istediğinizde bunu daha kolay yapabilmek için etiketleri kullanabilirsiniz.

Tag vs Branch

Bu soru da muhtemelen aklınıza gelmiştir. Bir commit’i etiketlemek yerine o durumdan yeni bir branch açıp bunu uzak depoya gönderebilirsiniz. Bu da sorununuzu büyük ihtimal çözecektir. Hatta etiketleri salt okunur (read-only) branch olarak da düşünebilirsiniz. Fakat bu ikisi birbirinden farklı araçlardır. Branch’lerin etiketlere göre kullanım alanı daha farklıdır. Genellikle branch’ler sürekli kodu değiştirmek için oluşturulmuş birimlerdir. Ana branch’ler dışında kalan branch’ler silinmeye musaittir. Ana branch’e merge olduktan sonra branch’in hayatı sona erer. Branch’ler sürekli eklenip silinirler.Etiketler ise sonsuza kadar kalma eğilimindedir.

Bir depoda çok fazla branch olması bir kargaşaya sebep olabilir. Çünkü geliştirmeleri bir branch üzerinde yapıp, bitirdiğimiz işleri commit’leriz. Bir branch’te geliştirme yapıp bitirdikten sonra ana branch’e merge ederiz. Yani aslında ana branch’ler dışında kalan branch’ler bireysel, etiketler ise global’dir. Etiketlere çok nadir göz atılır hatta bazen varlıkları bile unutulur. Fakat branch’ler ile sürekli etkileşim halinde oluruz. Branch’ler dinamik, etiketler ise sabittir. Yani kısacası branch’ler bir süreç için varlar. Etiketler ise bir geliştirmenin sonucunu işaretlemek için varlar.

Bir depoda branch’ler ve etiketler ayrı ayrı listelenir. Branch’lerle çok haşır neşir olacağımızdan çok fazla branch olması karmaşıklığa sebep olur. Ayrıca bir etiketten branch yaratmak oldukça kolaydır. Etikete gidip git checkout -b <branch-adi>komutu yeterlidir.

Özet

Bir dersimizin daha sonuna geldik. Bu dersimizde yine temel özelliklerden birini etiketleri gördük. Bir commit’i nasıl etiketleyeceğimizi, etiket kullanımı için bazı senaryoları öğrendik.

Konu hakkında görüş ve sorularınızı yorum kısmından veya Soru & Cevap sitemizden sorabilirsiniz.

Bir sonraki derste görüşmek üzere…

Git derslerinin tamamı için tıklayınız.