Git
Chapters ▾ 2nd Edition

1.3 Başlangıç - Git’in Temelleri

Git’in Temelleri

Peki Git özünde nedir? Bu, özümsenmesi gereken önemli bir alt bölüm; çünkü Git’in ne olduğunu ve temel çalışma ilkelerini anlarsanız, Git’i etkili biçimde kullanmanız çok daha kolay olacaktır. Git’i öğrenirken, Subversion ve Perforce gibi diğer SKS’ler hakkında bildiklerinizi aklınızdan çıkarmaya çalışın; bu, aracı kullanırken yaşanabilecek kafa karışıklıklarını önlemenize yardımcı olacaktır. Git’in, kullanıcı arayüzü, söz konusu sistemlerle benzerlik gösterse de bilgiyi depolama ve yorumlama biçimi çok farklıdır; bu farklılıkları anlamak, aracı kullanırken kafa karışıklığı yaşamamanızı sağlamaya yardımcı olacaktır.

Farklar Değil, Bellek Kopyaları

Git ile diğer SKS’ler (Subversion ve ahbapları dahil) arasındaki esas fark, Git’in bilgiyi yorumlayış biçimiyle ilgilidir. Kavramsal olarak, diğer sistemlerin çoğu, bilgiyi dosya-tabanlı bir dizi değişiklik olarak depolar. Bu sistemler (CVS, Subversion, Perforce, Bazaar ve saire) bilgiyi, kayıt altında tuttukları bir dosya kümesi ve zamanla her bir dosya üzerinde yapılan değişikliklerin listesi olarak yorumlarlar (bu genellikle değişiklik-tabanlı (delta-based) versiyon kontrolü olarak açıklanır).

Storing data as changes to a base version of each file.
Figure 4. Storing data as changes to a base version of each file.

Git, veriyi böyle yorumlayıp depolamaz. Bunun yerine, Git, veriyi, bir mini dosya sisteminin bellek kopyaları olarak yorumlar. Her commit yapışınızda ya da projenizin konumunu her kaydedişinizde, Git o anda dosyalarınızın nasıl göründüğünün bir fotoğrafını çekip o bellek kopyasına bir referansı depolar. Verimli olabilmek için, değişmeyen dosyaları yeniden depolamaz, yalnızca halihazırda depolanmış olan bir önceki özdeş kopyaya bir bağlantı kurar. Git’in veriyi yorumlayışı daha çok fotoğraf akışı gibidir.

Git stores data as snapshots of the project over time.
Figure 5. Storing data as snapshots of the project over time.

Bu, Git’le neredeyse bütün diğer SKS’ler arasında ciddi bir ayrımdır. Bu ayrım nedeniyle Git, sürüm kontrolünün, diğer sürüm kontrol sistemlerinin çoğu tarafından önceki kuşaklardan devralınan neredeyse bütün yönlerini yeniden gözden geçirmek zorunda bırakır. Bu ayrım Git’i basit bir SKS olmanın ötesinde, etkili araçlara sahip bir mini dosya sistemi gibi olmaya iter. Veriyi bu şekilde yorumlamanın yararlarından bazılarını dallanmayı (branching) işleyeceğimiz Git Branching'de ele alacağız.

Neredeyse Tüm İşlemler Yerelde Yapılır

Git’teki işlemlerin çoğu, yalnızca yerel dosyalara ve kaynaklara ihtiyaç duyar — genellikle bilgisayar ağındaki başka bir bilgisayardaki bilgilere ihtiyaç yoktur. Eğer çoğu işlemin ağ gecikmesi maliyetiyle gerçekleştiği bir MSKS kullanmışsanız, Git’in bu yönünü görünce, onun hız tanrıları tarafından kutsanmış olduğunu düşünebilirsiniz. Projenin bütün tarihçesi orada, yerel diskinde bulunduğu için işlemlerin çoğu anlık gerçekleşiyor gibi görünür.

Örneğin, projenin tarihçesini taramak için Git bir sunucuya bağlanıp oradan tarihçeyi indirdikten sonra görüntülemekle uğraşmaz — bunu basit bir şekilde yerel veritabanınızdan okur. Bu da proje terihçesini neredeyse anında görünteleyebilmeniz anlamına gelir. Bir dosyanın şimdiki haliyle bir ay önceki hali arasındaki farkları görmek isterseniz, Git, bir sunucudan fark hesaplaması yapmasını talep etmek ya da karşılaştırmayı yerelde yapabilmek için dosyanın bir ay önceki halini indirmek zorunda kalmak yerine, dosyanın bir ay önceki halini yerelde bulup fark hesaplamasını yerelde yapar.

Bu aynı zamanda, eğer bağlantınız kopmuşsa ya da VPN bağlantını yoksa yapamayacağınız şeylerin de sayıca oldukça sınırlı olduğu anlamına geliyor. Uçağa ya da trene binmiş olduğunuz halde biraz çalışmak istiyorsanız, yükleme yapabileceğiniz bir ağ bağlantısına kavuşana kadar güle oynaya commit yapabilirsiniz (yerel koypa, hatırladınız mı?). Eve vardığınızda VPN istemcinizin olması gerektiği gibi çalışmıyorsa, yine de çalışmaya devam edebilirsiniz. Pek çok başka sistemde bunları yapmak ya imkansız ya da zahmetlidir. Söz gelimi Perforce’ta, bir sunucuya bağlı değilseniz fazlaca bir şey yapamazsınız; Subversion ve CVS’te dosyaları değiştirebilirsiniz; ama veritabanına commit yapamazsınız (çünkü veritabanına bağlantınız yoktur). Bu, çok önemli bir sorun gibi görünmeyebilir; fakat ne kadar fark yaratabileceğini gördüğünüzde şaşırabilirsiniz.

Git Bütünlüğe Sahiptir

Git’te her şey depolanmadan önce sınama toplamından geçirilir (checksum) ve daha sonra bu sınama toplamı kullanılarak ifade edilir. Bu da demek oluyor ki, Git fark etmeden bir dosyanın ya da klasörün içeriğini değiştirmek mümkün değildir. Bu işlev Git’in merkezi işlevlerinden biridir ve felsefesiyle bir bütünlük oluşturur. Transfer sırasında veri kaybı ya da doysa arızası olmuşsa, Git bunu mutlaka fark edecektir.

Git’in sınama toplamı için kullandığı mekanizmaya SHA-1 özeti denir. Bu, on altılı sayı sisteminin (hexadecimal) sembolleriyle gösterilen (0-9 ve a-f) ve dosya ve klasör düzenini temel alan bir hesaplamayla elde denilen 40 karakterlik bir karakter dizisidir. Bir SHA-1 özeti şuna benzer:

24b9da6552252987aa493b52f8696cd6d3b00373

Bu özetler sıklıkla karşınıza çıkacak; çünkü Git onları yaygın biçimde kullanyor. Hatta, Git her şeyi dosya adıyla değil, içeriğinin özet değeriyle adreslenen veritabanında tutar.

Git Genellikle Yalnızca Veri Ekler

Git’te işlem yaptığınızda neredeyse bu işlemlerin tamamı Git veritabanına veri ekler. Sistemin geri döndürülemez bir şey yapmasını ya da veri silmesini sağlamak çok zordur. Her SKS’de olduğu gibi henüz kaydetmediğiniz değişiklikleri kaybedebilir ya da bozabilirsiniz; ama Git’e bir commit yaptıktan sonra veri kaybetmek çok zordur, özellikle de veritabanınızı düzenli olarak başka bir demoye push ediyorsanız.

Bu Git kullanmayı keyifli hale getirir; çünkü işleri ciddi biçimde sıkıntıya sokmadan denemeler yapabileceğimizi biliriz. Git’in veriyi nasıl depoladığı ve kaybolmuş görünen veriyi nasıl kurtarabileceğiniz hakkında daha derinlikli bir inceleme için bkz. Undoing Things.

Üç Aşama

Şimdi dikkatinizi verin — öğrenme sürecinizin pürüzsüz ilerlemesini istiyorsanız, aklınızda bulundurmanız gereken esas şey bu. Git’te, dosyalarınızın içinde bulunabileceği üç aşama (state) vardır: kaydedilmiş (committed), değiştirilmiş (modified) ve hazırlanmış (staged):

  • Committed, verinin güvenli biçimde veritabanında depolanmış olduğu anlamına gelir.

  • Modified, dosyayı değiştirmiş olduğunuz fakat henüz veritabanına kaydetmediğiniz anlamına gelir.

  • Staged ise, değiştirilmiş bir dosyayı bir sonraki commit işleminde bellek kopyasına alınmak üzere işaretlediğiniz anlamına gelir.

Bu da bizi bir Git projesinin üç ana bölümüne getiriyor: Git klasörü (the Git directory), çalışma klasörü (the working tree) ve hazırlık alanı (the staging area).

Working tree, staging area, and Git directory.
Figure 6. Working tree, staging area, and Git directory.

Git klasörü, Git’in üstverileri (metadata) ve nesne veritabanını depoladığı yerdir. Bu, Git’in en önemli parçasıdır ve bir yazılım havuzunu bir bilgisayardan bir başkasına klonladığınızda kopyalanan şeydir.

Çalışma klasörü projenin bir sürümünden yapılan tek bir seçmedir (checkout). Bu dosyalar Git klasöründeki sıkıştırılmış veritabanından çıkartılıp sizin kullanımınız için sabit diske yerleştirilir.

Hazırlık alanı (the staging area), genellikle Git klasörünüzde bulunan ve bir sonraki commit işlemine hangi değişikliklerin dahil olacağını tutan sade bir dosyadır. Buna bazen “indeks (index)” dendiği de olur; ama “staging area” ifadesi de bir o kadar iyidir.

Git işleyişi temelde şöyledir:

  1. Çalışma klasörünüzdeki (the working directory) dosyalar üzerinde değişiklik yaparsınız.

  2. Dosyaları, hangi değişikliklerin bir sonraki commit’te olmasını istiyorsanız, sadece o değişiklikleri içerecek şekilde hazırlık alanına (the staging directory) ekleyerek hazırlarsınız.

  3. Dosyaların hazırlık alanındaki hallerini alıp oradaki bellek kopyasını kalıcı olarak Git klasörüne (the Git directory) depolayan bir commit işlemi yaparsınız.

Bir dosyanın belirli bir sürümü Git klasöründeyse, onun commit’lenmiş olduğu kabul edilir. Eğer üzerinde değişiklik yapılmış fakat hazırlık alanına eklenmişse, staged olduğu söylenir. Ve checkout işleminden sonra üzerinde değişiklik yapılmış; fakat commit için hazırlanmamışsa, değiştirilmiş olarak nitelenir. Git Temelleri bölümünde, bu aşamalar hakkında ve onlardan nasıl faydalanacağınız ya da staged aşamasını nasıl geçebileceğinizi detaylıca öğreneceksiniz.