Chapters ā–¾ 2nd Edition

3.1 Git Dalları - Dallar

Neredeyse her sĆ¼rĆ¼m kontrol sisteminin (VCS) bir tĆ¼r dal desteği vardır. Dal oluşturmak, ana geliştirme hattından ayrılıp, bu ana hatla oynamadan Ƨalışmalarımıza devam etmek anlamına gelir. BirƧok sĆ¼rĆ¼m kontrol sistemi aracında bu, genellikle kaynak kodu dizininin yeni bir kopyasını oluşturmanızı gerektiren ve bĆ¼yĆ¼k projeler iƧin uzun zaman alabilen, maliyetli bir sĆ¼reƧtir.

Bazı insanlar Gitā€™in dalma modelini "ƶlĆ¼mcĆ¼l ƶzellik" olarak adlandırır ve kuşkusuz Gitā€™i VCS topluluğunda ƶne Ƨıkarır. Peki bu neden bu kadar ƶzeldir? Gitā€™in dallanma şekli son derece hafiftir, bu da dallandırma işlemlerinin neredeyse anlık hale gelmesini sağlar ve genellikle dallar arasında hızlı bir şekilde geƧiş yapılabilir. Diğer birƧok sĆ¼rĆ¼m kontrol sisteminin aksine, Git iş akışlarında sık sık dal aƧma ve birleştirmeyi teşvik eder, hatta gĆ¼n iƧerisinde bir Ƨok kez. Bu ƶzelliği anlamak ve ustalaşmak size gĆ¼Ć§lĆ¼ ve benzersiz bir araƧ sağlar ve geliştirme şeklinizi tamamen değiştirebilir.

Dallar

Gitā€™in dallanma yƶntemini gerƧekten anlamak iƧin bir adım geriye Ƨekilip Gitā€™in verileri nasıl sakladığını incelememiz gerekiyor.

BaşlangıƧ bƶlĆ¼mĆ¼nden hatırlayabileceğiniz gibi Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi poz olarak saklar.

Git, bir katkı işlediğinizde, izleme (stage) aldığınız iƧeriğin pozunun işaretƧisini iƧeren bir katkı nesnesi saklar. Bu nesne aynı zamanda yazarın adını ve e-posta adresini, katkı mesajını ve ƶncel katkı veya katkılara ilişkin işaretƧileri iƧerir. Ä°lk katkı (first commit) iƧin sıfır; normal bir katkı iƧin bir; ve birden fazla dalın birleşmesinden kaynaklanan bir katkı iƧinse Ƨoklu ƶncel katkı bulunur.

Bunu gƶrselleştirmek iƧin, Ć¼Ć§ dosya iƧeren bir dizine sahip olduğumuzu ve bunların hepsini izleme alıp, katkı olarak işlediğinizi varsayalım. Dosyaları izlemlemek, her bir dosya iƧin bir sağlama toplamı (checksum) hesaplar (BaşlangıƧ bƶlĆ¼mĆ¼nde bahsettiğimiz SHA-1 karması), dosyanın bu sĆ¼rĆ¼mĆ¼nĆ¼ Git reposunda saklar (Git bunlara blobs olarak atıfta bulunur)(Binary Large OBject: ikilik geniş nesne), ve bu sağlama toplamını izlem alanına ekler:

$ git add README test.rb LICENSE
$ git commit -m 'The initial commit of my project'

git commit komutunu Ƨalıştırarak bir katkı oluşturduğunuzda, Git her alt dizinin (bu durumda sadece kƶk (root) proje dizini) doğrular ve bunları Git reposunda bir ağaƧ nesnesi (tree object) olarak saklar. Git daha sonra meta verileri ve kƶk proje ağacının işaretƧisini iƧeren bir katkı nesnesi oluşturur. Bƶylece gerektiğinde pozu yeniden oluşturabilir.

Git reponuz artık beş nesne iƧeriyor: - Her biri Ć¼Ć§ dosyadan birinin iƧeriğini temsil eden Ć¼Ć§ blob - Dizinin iƧeriğini ve hangi dosya adlarının hangi blob olarak depolandığını listeleyen bir ağaƧ - Kƶk ağacın işaretƧisini ve tĆ¼m katkı metaverisini iƧeren bir katkı

Bir katkı ve onun ağacı.
Gƶrsel 9. Bir katkı ve onun ağacı

Eğer bazı değişiklikler yaparsanız ve tekrar katkı olarak işlerseniz, sonraki katkı, kendinden hemen ƶnceki katkıya işaret eden bir işaretƧiyi depolar.

Katkı ve ƶncel katkılar.
Gƶrsel 10. Katkı ve ƶncel katkılar

Gitā€™teki bir dal, temel olarak Ć¼zerindeki katkılardan birinin hafif ve taşınabilir bir işaretƧisidir. Gitā€™te varsayılan dal master adıyla ifade edilir (anadal). Katkıları işlemeye başladığınızda, en son işlediğiniz katkıyı gƶsteren bir master dalı alırsınız. Her katkı işlediğinizde, master dalı işaretƧisi otomatik olarak ileri hareket eder.

Not

Gitā€™teki master dalı ƶzel bir dal değildir. Tam olarak diğer diğer dallar gibi davranır. Hemen hemen her repoda bulunmasının tek nedeni, git init komutunun varsayılan olarak onu oluşturması ve Ƨoğu insanın bunu değiştirmeye uğraşmamasıdır.
Bir dal ve katkı geƧmişi.
Gƶrsel 11. Bir dal ve katkı geƧmişi

Yeni bir Dal AƧma

Yeni bir dal oluşturduğunuzda ne olur? Ɩncelikle, bu size etrafında dolaşabileceğiniz yeni bir işaretƧi oluşturur. Diyelim ki testing adında yeni bir dal oluşturmak istiyorsunuz. Bunu git branch komutu ile yaparsınız:

$ git branch testing

Bu, şu anda işlediğiniz katkı iƧin yeni bir işaretƧi oluşturur.

Aynı katkı dizisine işaret eden iki dal.
Gƶrsel 12. Aynı katkı dizisine işaret eden iki dal

Git, şu anda hangi dalda olduğunuzu nasıl bilir? Bunu HEAD adlı ƶzel bir işaretƧiyi kullanarak yapar. Yalnız bu Subversion veya CVS gibi alışkın olduğunuz diğer sĆ¼rĆ¼m denetleyicilerindeki (VCS) HEAD kavramından Ƨok farklıdır. Gitā€™te bu, şu anda Ć¼zerinde Ƨalıştığınız yerel dalın bir işaretƧisidir. Mevcut senaryomuzda halen master dalındasınız. git branch komutu sadece yeni bir dal oluşturdu ama henĆ¼z o dala geƧiş yapmadı.

Bir dala işaret eden HEAD.
Gƶrsel 13. Bir dala işaret eden HEAD

Dal işaretƧilerinin nereye işaret ettiğini gƶrmek iƧin en basitinden bir git log komutu Ƨalıştırabilirsiniz. Bu seƧenek, --decorate olarak adlandırılır.

$ git log --oneline --decorate
f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to the central interface
34ac2 Fixed bug #1328 - stack overflow under certain conditions
98ca9 The initial commit of my project

f30ab katkısının hemen yanında master ve testing dallarını gƶrebilirsiniz.

Dallararası GeƧiş

Var olan bir dala geƧmek iƧin git checkout komutunu Ƨalıştırırsınız. Hadi yeni oluşturduğumuz testing dalına geƧelim:

$ git checkout testing

Bu komut HEAD işaretƧisinin yƶnĆ¼nĆ¼ testing dalına Ƨevirir.

Mevcut dalı gƶsteren HEAD işaretƧisi.
Gƶrsel 14. Mevcut dalı gƶsteren HEAD işaretƧisi

Peki bunun ƶnemi nedir? Hadi şimdi başka bir katkı işleyelim:

$ vim test.rb
$ git commit -a -m 'made a change'
Bir katkı işlendiğinde `HEAD` ileriye doğru hareket eder.
Gƶrsel 15. Bir katkı işlendiğinde HEAD 'in işaret ettiği dal ileriye doğru hareket eder.

Ä°lginƧ bir şekilde, testing dalınız ileri hareket etti ancak master dalınız halen en son bıraktığımız halde (testing dalına geƧiş yaptığınız anda Ć¼zerinde bulunduğunuz katkıya işaret ediyor). Hadi master dalımıza tekrar geƧelim:

$ git checkout master
Başka dala geƧtiğinizde HEADā€™in yƶnĆ¼ değişir.
Gƶrsel 16. Başka dala geƧtiğinizde (git checkout) HEADā€™in yƶnĆ¼ değişir

Bu komut iki şey yaptı: Ä°lk olarak, HEAD işaretƧisini tekrar master dalına Ƨevirdi ve ikinci olarak, Ƨalışma dizinindeki dosyaları master 'ın işaret ettiği poza geri dƶnderdi. Bu aynı zamanda, şu andan itibaren yapacağınız değişikliklerin projenin eski bir sĆ¼rĆ¼mĆ¼nden sapacağı anlamına gelir. Bu testing dalındaki yaptığınız Ƨalışmayı geri sararak daha farklı bir yƶne gidebilmenizi sağlar.

Not
Dallar arasında geƧiş yapmak Ƨalışma dizinindeki dosyaları değiştirir

Gitā€™te dallar arasında geƧiş yaparken, Ƨalışma dizininizdeki dosyaların değişeceğini unutmamalısınız! Eğer daha eski bir dala geƧerseniz, Ƨalışma dizininiz o dalda son katkı işlediğiniz ana geri dƶner. Eğer Git bunu temiz bir şekilde gerƧekleştiremezse, geƧiş yapmanıza hiƧ izin vermez.

Hadi bir kaƧ değişiklik yapalım ve katkı işleyelim:

$ vim test.rb
$ git commit -a -m 'made other changes'

Şimdi projenizin geƧmişi sapmış durumda (bakınız Ayrık geƧmiş (Divergent history)). Bir dal oluşturdunuz, ona geƧtiniz, Ć¼zerinde Ƨalıştınız, ardından ana dalınıza geri dƶndĆ¼nĆ¼z ve bambaşka bir iş yaptınız. Her iki değişiklik farklı dallarda yalıtılmış durumdadır: Dallar arasında geƧiş yapabilirsiniz ve istediğinizde onları birleştirebilecek durumdasınız. Bunların hepsini basit branch, checkout ve commit komutları ile yaptınız.

Ayrık geƧmiş.
Gƶrsel 17. Ayrık geƧmiş (Divergent history)

Bu durumu git log komutuyla kolayca gƶrebilirsiniz. Eğer git log --oneline --decorate --graph --all komutunu Ƨalıştırırsanız; katkı geƧmişiniz, dal işaretƧilerinin nereye baktığı ve geƧmişinizin nasıl ayrıldığı ekranda yazacaktır.

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project

Gitā€™teki bir dal, aslında işaret ettiği katkının 40 karakterlik SHA-1 sağlamasını tutan basit bir dosya olduğu iƧin, dalları oluşturmak ve yok etmek Git iƧin Ƨok kolaydır. Yeni bir dal oluşturmak, bir dosyaya 41 bayt yazmak kadar hızlı ve basittir (40 karakter ve bir satırbaşı).

Bu, yƶntem olarak projenin tĆ¼m dosyalarını ikinci bir dizine yedeklemeyi seƧen, Ƨoğu eski VCS aracının kullandığı yolun kesin bir zıttıdır. Yedekleme yƶntemi, projenin boyutuna bağlı olarak birkaƧ saniye veya hatta dakika bile sĆ¼rebilir. Oysa Gitā€™te katkı işlemi her zaman anlık olarak gerƧekleşir. Ayrıca, katkı işlerken ƶncel katkıları da kaydettiğimiz iƧin, birleştirmek iƧin uygun bir nokta bulma işlemi otomatik olarak yapılır ve genellikle Ƨok kolaydır. Bu ƶzellikler, geliştiricileri sık sık dallar oluşturmaları ve kullanmaları yƶnĆ¼nde cesaretlendirir.

Haydi, neden bunu yapmanız gerektiğini gƶrelim.

Not
Tek komutla dal oluşturmak ve o dala geƧiş yapmak

Yeni bir dal oluşturmak ve aynı anda o yeni dala geƧmek sık karşılaşılan bir durumdur. Bunu tek komutla gerƧekleştirebiliriz: git checkout -b <newbranchname>.
scroll-to-top