Chapters ā–¾ 2nd Edition

1.3 Başlangıç - Git Nedir?

Git Nedir?

Ɩzetle Git nedir? Bu, ƶzümsemesi gerekli ve ƶnemli olan bir bƶlümdür. Çünkü eğer Git’in ne olduğunu, temellerini ve nasıl Ƨalıştığını iyi anlarsanız, Git’i etkili bir şekilde kullanmak da muhtemelen sizin iƧin Ƨok daha kolay olacaktır. Git’i öğrenirken, mümkün olduğunca diğer Sürüm Denetim Sistemleri’nden (CVS, Subversion veya Perforce gibi) bildiklerinizi aklınızdan Ƨıkarmaya gayret edin ki Git’i daha berrak ve doğru şekilde öğrenip kullanabilesiniz. Git’in kullanıcı arayüzü diğer Sürüm Denetim Sistemleri’ne epey benzese de Git, bilgileri diğerlerinden Ƨok daha farklı bir şekilde depolar ve bu bilgiler hakkında daha farklı düşünür. Bu yüzden bunun gibi farklılıkları anlamak Git’i kullanırken kafanızın karışmasını engeller.SubversionPerforce

Farklılıklar Değil, Anlık Pozlar

Git’in diğer herhangi bir VCS’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ı sürüm denetimi şeklinde tanımlanır).

Verileri her dosyanın baz halini referans alarak
Görsel 4. Verileri her dosyanın baz halini referans alarak, yapılan değişiklikler şeklinde saklamak.

Git, veriler 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üntüler serisi şeklinde düşünür ve o şekilde saklar. Git’le her katkı (katkı) işlediğinizde 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üntü akışı (poz) olarak gƶrür.

Git zaman geƧtikƧe veriyi projenin pozları olarak saklar.
Gƶrsel 5. Veriyi projenin pozları olarak saklamak.

Bu Git ve neredeyse diğer tüm VCS’leri arasındaki en büyük ayrımdır. Bu da Git’i, diğer sistemlerin kendilerinden ƶnceki nesilden kopyaladıkları sürüm denetimi mirasını her yƶnünü yeniden değerlendirmesini sağlar. Bƶylelikle Git, basit bir VCS’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 Dalları

Neredeyse Her İşlem Yereldir

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 CVCS’ye (MerkezĆ® Versiyon Kontrol Sistemi) alışkınsanız; Git’in bu yƶnü size, Git’in Allah tarafından ilahi bir hız yeteneğiyle kutsadığını düşündürtecektir. Çü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 Ƨok az şey olduğu anlamına geliyor. Eğer uƧak ya da trenle seyahat ederken 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ışıdır). 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’in Entegrasyonu Vardır

Git’deki her şeyin 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 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:

24b9da6552252987aa493b52f8696cd6d3b00373

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 Genel Olarak Sadece Veri Ekler

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 işlemediğ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 repoya 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: Değişiklikleri Geri Alma

Üç Durum

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:

  • Modified: dosyayı değiştirdiğinizi ama henüz veritabanına katkılamadığınızı (commit) gƶsterir.

  • Staged: değiştirilmiş bir dosyayı bir sonraki katkı pozunda (snapshot) işlenecek şekilde işaretlediğinizi gƶsterir.

  • Committed: dosyanın güvenli bir şekilde yerel veritabanınızda saklandığını gƶsterir.

Bu da bizi bir Git projesinin üç ana bölümüne getirir: the working tree (çalışma ağacı), the staging area (izleme alanı), ve Git klasörü.

çalışma ağacı, izleme alanı ve Git klasörü
Görsel 6. çalışma ağacı, izleme alanı ve Git klasörü.

Ƈalışma ağacı (working tree), checkout komutunun projenin bir sürümünde Ƨalıştırılmasıdır. Bu dosyalar Git dizinindeki sıkıştırılmış veritabanından Ƨıkarılır ve sizin modifiye edebilmeniz veya kullanabilmeniz iƧin diskinize yerleştirilir.

İzleme alanı (staging area) bir dosyadır, genel olarak Git klasörünüzün içindedir ve bir sonraki katkıya hangi bilgilerin işleneceğini depolar. Git terminolojisindeki teknik adı ``index``dir, ama ``izleme alanı`` ifadesi de iş görür.

Git klasƶrü ise Git’in projenize ait tüm üstverileri ve nesne veritabanını sakladığı yerdir. Bu Git’in en ƶnemli bƶlümüdür; aynı zamanda da başka bir repodan klon kopyaladığınızda kopyalanan şeyin de ta kendisidir.

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

  1. Ƈalışma ağacında dosyaları düzenlersiniz.

  2. ``git add …​`` komutuyla bir sonraki katkıya işlenecek olan değişiklikleri seƧersiniz.

  3. ``git commit …​`` komutuyla bir katkı işlersiniz, izleme alanındaki (stage) dosyaların pozlaını (snapshot) Ƨeker ve Git klasƶrünüzde kalıcı olarak saklarsınız.

Eğer bir dosyanın belli bir sürümü Git klasöründeyse, o dosya katkılanmış sayılır (commited). Eğer düzenlenmiş ve izleme alanına eklenmişse, izlem'e alınmıştır (staged). Eğer son denetlenmesinden sonra değiştirilmişse ama işlenmemişse, o halde değiştirilmiş durumdadır (modified). Git Temelleri bölümünde bu durumlar hakkında daha fazla şey öğrenecek ve bu durumların avantajını kullanmayı ya da izlem (stage) kısmını tamamen es geçmeyi öğreneceksiniz:

scroll-to-top