Git‘te Branching(Dallanma) Nedir?

Neredeyse her VCS’(version kontrol sistemi)nin bir farklı dallanma(branch) destekleri vardır. Branching(dallanma), ana geliştirme çizgisinden ayrılmanız ve bu ana çizgiyi bozmadan çalışmaya devam etmeniz anlamına gelir.Birçok VCS aracında, bu biraz pahalı bir süreçtir ve genellikle büyük projeler için uzun zaman alabilen kaynak kod dizininizin yeni bir kopyasını oluşturmanızı gerektirir. Bazı insanlar Git’in dallanma modelini “öldürücü özelliği” olarak adlandırıyor ve Git’i VCS topluluğunda kesinlikle farklı kılıyor. Neden bu kadar özel? Git dallarının inanılmaz derecede hafif olması, dallanma işlemlerini neredeyse anlık hale getirmesi ve dallar arasında genel olarak aynı hızla geçiş yapmasını sağlıyor. Diğer birçok VCS’den farklı olarak Git, günde birden çok kez olsa bile sık sık dallanan ve birleşen iş akışlarını teşvik eder. Bu özelliği anlamak ve ustalaşmak size güçlü ve benzersiz bir araç sağlar ve geliştirme şeklinizi tamamen değiştirebilir.

Kısaca Dallanma(Branching)

Git’in dallanma şeklini gerçekten anlamak için bir adım geri atıp Git’in verilerini nasıl depoladığını incelememiz gerekiyor.

Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi anlık görüntü olarak depolar.

Commit yaptığınızda Git, hazırladığınız içeriğin anlık görüntüsüne yönelik bir pointer(işaretçi) içeren bir commit nesnesi depolar.

Bu nesne ayrıca yazarın adını ve e-posta adresini, yazdığınız mesajı ve doğrudan bu committen önce gelen commit veya commitlere işaret eden alt pointerları içerir.

Bunu görselleştirmek için, üç dosya içeren bir dizininiz olduğunu ve hepsini sahneye koyduğunuzu ve commit ettiğinizi varsayalım.

Dosyaları hazırlama, her biri için bir sağlama toplamı hesaplar, dosyanın bu sürümünü Git deposunda saklar (Git bunlara blob olarak tutar).

$ git add README

$ git commit -m ‘Initial commit’

git commit’i çalıştırarak commit oluşturduğunuzda, Git her alt dizini kontrol eder (bu durumda, sadece kök proje dizini) ve bunları Git deposunda bir ağaç nesnesi olarak saklar.

Git daha sonra meta verileri ve kök proje ağacına yönelik bir işaretçiyi içeren bir commit nesnesi oluşturur, böylece gerektiğinde bu anlık görüntüyü yeniden oluşturabilir.

Bazı değişiklikler yapıp tekrar Commit ederseniz, bir sonraki Commit, ondan hemen önce gelen Commit için bir işaretçi saklar.

Git’teki bir dal, bu Commitlerin birine ait değişken bir işaretçi tutar.

Git’teki varsayılan dal adı master’dır.

Her committe bulunduğunuzda, ana dal(master) pointer otomatik olarak ileriye doğru hareket eder.

Yeni Dal(Branch) Oluşturma

Yeni bir dal oluşturduğunuzda ne olur? Bunu yapmak, hareket etmeniz için size yeni bir pointer oluşturmanız demektir.

Test adında yeni bir dal oluşturmak istediğinizde git branch komutuyla ismini vermeniz yeterlidir.

git branch testing

Bu komut ile, şu anda üzerinde bulunduğunuz aynı commit için yeni bir pointer oluşturdu.

Peki Git şu anda hangi dal’da olduğunuzu nasıl biliyor?

Git HEAD adlı özel bir pointer tutarak bunu yapıyor. Bu kavram Subversion veya CVS gibi alışık olabileceğiniz diğer VCS’lerdeki HEAD kavramından çok farklı.Branch oluşturma komutunu çalıştırdığımızda hala aktif branchimiz masterdir.

git branch komutu yalnızca yeni bir dal oluşturdu, bulunduğunuz dalı değiştirmedi.

Branch’da pointer(işaretçilerin)ların hangi branch’a işaret ettiğini gösteren basit bir git log komutu çalıştıralım.Bunu log komutuna ek olarak — decorate ile yapabiliriz.

$git log — oneline — decorate

7273b90 (HEAD -> main, origin/main, testing) son halim

97849a7 (origin/master) son deploy

e103709 son testetere

ba0f018 testlere devam

7273b90 commitinin hemen yanında bulunan head ve testing dallarını görebilirsiniz.

Branch değiştirmek

Mevcut bir dalı değiştirmek için git checkout komutunu çalıştırmalıyız.

Şimdi oluşturduğumuz test dalına geçelim.

$ git checkout testing

Bu sayede , HEAD’in pointeri testing branch pointeri ile değiştirir

Burada dikkat etmemiz gereken,artık testing branch’ı ilerledi, ancak master branch’ı hala üzerinde bulunduğunuz commiti gösteriyor.

Branch‘ları değiştirmek için git checkout’u çalıştırıyoruz.şimdide Master branch a geri dönelim.

$ git checkout master

Bu komut iki şey yaptı. HEAD işaretçisini ana dalı işaret edecek şekilde geri taşıdı ve çalışma dizininizdeki dosyaları ana öğenin işaret ettiği görüntüye geri döndürdü.

Bu aynı zamanda, bu noktadan sonra yaptığınız değişikliklerin, projenin eski bir versiyonunda olduğu anlamına gelebilir.Esasen, önceki yazdığımız koda geri sardırdık :)

Birkaç değişiklik yapalım ve tekrar commit edelim.

$ vim test
$ git commit -a -m ‘değişiklik yapıldı.’

Artık proje geçmişiniz farklılaştı.Branch(Dal) oluşturup ordan devam ediyorsunuz, üzerinde biraz çalıştınız ve ardından testing branchına geri döndünüz ve or branchdada ayrı işler yaptınız.

Bu değişikliklerin her ikisi de ayrı branchlarda izole edilmiş olucaktır. Branchlar arasında geçiş yapabilir ve hazır olduğunuzda bunları birleştirebilirsiniz(merging).

Tüm bunları basit branch, commit komutlarıyla yapıyoruz.

Bunu git log komutuyla da kolayca görebilirsiniz. git log — oneline — decorate — graph — all komutunu çalıştırırsanız, branhınızın(dallınızın) pointerının nerede olduğunu ve branchın geçmişinin nasıl olduğunu Commitlerinizin detaylı geçmişini yazdırır.

$ git log — oneline — decorate — graph — all

* c2b9e (HEAD, master) değişiklik

| * 87ab2 (testing) teste geçti

|/

* f30ab Add feature #32 — alışkanlık

* 34ac2 Fix bug #1328 — sonraki iş

* 98ca9 ilk commit

Version kontrol sistemlerinden Gitin en önemli konusu Branching(dallanma) konusunu detaylı anlatmaya çalıştım.Bu ve benzeri yazılarımızı sitemizden takip edebilirsiniz.