1.3 Başlangıç - Git Nedir?

Git’in diğer herhangi bir VKS’den (Subversion ve benzerleri dahil olmak üzere) en büyük farkı, Git’in veriler hakkında düşünme şeklidir. Diğer çoğu sistem bilgileri dosya-bazlı değişim listesi şeklinde saklar. Bu diğer sistemler (CVS, Subversion, Perforce, Bazaar vd.) bilgileri dosya setleri ve o dosyalara zaman içinde yapılan değişiklikler şeklinde saklar (Bu genellikle delta-bazlı versiyon kontrol şeklinde tanımlanır).

Git, verileri hakkında bu şekilde düşünmez ve onları bu şekilde saklamaz. Bunun yerine Git, verilerini daha çok minyatür dosya sistemlerinin anlık görünümler serisi şeklinde düşünür ve o şekilde saklar. Git’le her commit yaptığınızda ya da projenizin durumunu kaydettiğinizde, Git kısaca tüm dosyalarınızın o an nasıl göründüğünün fotoğrafını çeker ve o anlık görünümün referansını saklar. Verimli olmak adına, eğer dosyalar değişmemişse Git o dosyaları tekrar saklamaz, onun yerine o dosyaların halihazırda saklandığı referansa bağlantı verir. Yani Git, verilerini daha çok anlık görünüm akışı olarak görür.

Bu Git ve neredeyse diğer tüm VKS’lerinin arasındaki en büyük ayrımdır. Bu da Git’i, diğer sistemlerin kendilerinden önceki jenerasyondan kopyaladıkları versiyon kontrolünün her yönünü yeniden değerlendirmesini sağlar. Böylelikle Git, basit bir VKS’dense, inanılmaz güçlü araçlarla donatılmış minyatür bir dosya sistemi olmuştur. Git’deki dallanmayı anlatırken verileriniz hakkında bu şekilde düşünmenin getirilerini keşfedeceğiz. Git Branching

Git’deki çoğu işlem çalışmak için yalnızca yerel dosyalara ve kaynaklara ihtiyaç duyar. Genel olarak başka bir bilgisayardan sizin ağınıza bilgi gelmesine ihtiyacınız yoktur. Eğer çoğu işlemin ağ gecikme yüküne sahip olduğu bir MVKS’ye (Merkezî Versiyon Kontrol Sistemi) alışkınsanız, Git’in bu yönü size, Hız Tanrıları’nın Git’i, ilahi ve tanrısal güçlerle kutsadığını düşündürecektir. Çünkü projenizin tüm tarihçesi tam olarak yerel diskinizdedir, ve çoğu işlem de neredeyse anında gerçekleşir.

Örneğin, projenin tarihçesine göz atmak için Git’in sunucuya girip, tarihçeye erişip size göstermesine gerek yoktur, onun yerine hızlıca sizin yerel veritabanınızdan okur. Bu da proje tarihçesini neredeyse anında görebildiğiniz anlamına gelir. Eğer bir dosyanın mevcut sürümü ve bir ay önceki sürümü arasındaki değişiklikleri görmek isterseniz, Git, uzaktaki bir sunucuya bu işlemi yapması için başvurmak ya da dosyanın eski versiyonunu uzaktaki sunucudan çekip yerel diskte hesaplamak yerine, dosyanın bir ay önceki haline hızlıca göz atıp yerel bir farklılık hesaplaması yapar.

Bu da çevrim dışı ya da VPN’sizseniz bile yapamayacağınız sadece çok az şey olduğunu belirtir. Eğer uçakla ya da trenle seyahet ediyorken biraz çalışmak isterseniz, yerel ortamınızda çalışıp commitleyebilir (yerel kopyanıza) ve internet bağlantısı edindiğinizde de onu internete yükleyebilirsiniz. Eğer eve giderseniz ve VPN istemciniz düzgün bir şekilde çalışmazsa bile hâlâ yerel ortamınızda çalışabilirsiniz. Diğer çoğu sistemde ise bunları yapmak ya imkânsız ya da çok sancılıdır. Örneğin Perforce’de, eğer sunucuya bağlı değilseniz pek bir şey yapamazsınız. Subversion ve CVS’de ise dosyaları düzenleyebilir ama sunucuya commitleyemezsiniz (Çünkü sunucunuz çevrim dışı). Bu size şu an çok da önemli bir özellikmiş gibi gelmeyebilir ama Git’i öğrendikçe ve kullandıkça bunun ne kadar büyük bir fayda sağladığını bizzat göreceksiniz.

Git’deki her şey saklanmadan önce sağlaması yapılır ve ondan sonra da o sağlamayla referans gösterilir. Bu da dosyaların ya da klasörlerin içeriğini Git’in haberi olmadan değiştirmenin imkânsız olduğu anlamına gelir. Bu işlev Git’in temelinde gömülü halde gelir ve Git’in felsefesinin ayrılmaz bir parçasıdır. Aktarım yaparken bilgi kaybetmezsiniz. Aynı şekilde Git farkına varmadan bir dosya da bozulmaz.

Git’in sağlama yapmak için kullandığı bu mekanizmanın adı SHA-1 özetidir. Bu, on altılık karakterlerden (0-9 ve a–f) oluşan ve Git’deki bir dosya veya dizin yapısının içeriğine göre hesaplanan 40 karakterlik bir karakter dizisidir. Bir SHA-1 özeti şuna benzer:

Bu özet değerlerini Git’in çoğu yerinde göreceksiniz çünkü Git onu sık sık kullanır. Hatta Git, sunucusundaki her şeyi dosya isimleriyle değil, içeriklerinin özet değeriyle saklar.

Git’de bir şeyler yaptığınızda neredeyse hepsi sadece Git’in veritabanına veri ekler. Sistemin geri alınamayan bir şey yapmasını veya verileri herhangi bir şekilde silmesini sağlamak zordur. Tüm VCS’lerde olduğu gibi, henüz commitlemediğiniz değişiklikleri kaybedebilir veya karman çorman yapabilirsiniz, ancak Git’e bir anlık görünüm verdikten sonra, özellikle veritabanınızı düzenli olarak başka bir repository’e yollarsanız, kaybetmek çok zordur.

Bu da Git’i kullanmayı keyifli kılar çünkü ortalığı batırma tehlikesi olmadan istediğimiz gibi denemeler yapabileceğimizi biliriz. Git’in verilerini nasıl sakladığını ve kaybolmuş gibi görünen dosyaları nasıl geri alabileceğinizi daha detaylı bir şekilde öğrenmek için: Undoing Things

Eğer Git’i öğrenme sürecinizin sorunsuz olmasını istiyorsanız, şimdi dikkatinizi verin. Git hakkında akılda tutulacak ana şey şudur, Git’in dosyalarınızın içinde bulunabileceği üç ana durum vardır: modified, staged, and committed:

Bu da bizi bir Git projesinin üç ana bölümüne getirir: the working tree, the staging area, ve Git klasörü.

Working tree, checkout komutunun projenin bir versiyonunda çalıştırılmasıdır. Bu dosyalar Git directory’deki sıkıştırılmış veritabanından çıkarılır ve sizin modifiye edebilmeniz veya kullanabilmeniz için diskinize yerleştirilir.

The staging area bir dosyadır, genel olarak Git klasörünüzün içindedir ve bir sonraki commite hangi bilgilerin gideceğini depolar. Git jargonundaki teknik adı ``index``dir, ama ``staging area`` ifadesi de iş görür.

Git klasörü ise Git’in projenize ait tüm üstverileri ve obje veritabanını sakladığı yerdir. Bu Git’in en önemli bölümüdür, aynı zamanda da başka bir repository’den klonu kopyaladığınızda kopyalanan şeyin ta kendisidir.

Git’in iş akışı basitçe şöyledir:

Eğer bir dosyanın belli bir versiyonu Git klasöründeyse, o dosya commitlenmiş sayılır. Eğer düzenlenmiş ve staging area’ya eklenmişse, stage edilmiştir. Eğer son denetlenmesinden sonra değiştirilmişse ama işlenmemişse, o halde modifiye edilmiştir. Şu kısımda bu durumlar hakkında daha fazla şey öğrenecek ve bu durumların avantajını kullanmayı ya da stage kısmını tamamen es geçmeyi öğreneceksiniz: Git Basics