Git nedir ve bir geliştirici neden Git'e ihtiyaç duyar?

Git bir versiyon kontrol sistemidir

Git, proje dosyalarındaki değişikliklerin geçmişini kaydeden bir programdır. Kodun durumunu her kaydettiğinizde Git, yazar, tarih ve açıklama içeren bir anlık görüntü (commit) saklar. Herhangi bir anlık görüntüye geri dönebilir, onu mevcut durumla karşılaştırabilir, belirli bir satırı kimin ve neden değiştirdiğini bulabilirsiniz.

Daha önce «proje_v2», «proje_final» ve «proje_final_BU_SON» gibi klasörler tuttuysanız, aslında zaten versiyon kontrolü yapıyordunuz, sadece elle. Git aynı şeyi otomatik, kompakt ve bir şey kaybetme korkusu olmadan yapar. Bu yüzden geliştiriciler arasında «Git nedir» sorusunun cevabı sadece bir program değil, kod editörü kadar vazgeçilmez temel bir çalışma aracıdır.

Git'in «kopya klasörlerinden» ve bulut depolamadan farkı

Bulut depolama bir dosyanın son sürümünü ve en iyi ihtimalle birkaç otomatik kopyasını saklar. Git ise anlamlı bir geçmiş tutar: değişiklikleri ne zaman kaydedeceğinize kendiniz karar verir ve tam olarak ne yaptığınızı yazarsınız. Ayrıca Git, hiçbir bulut sürücünün yapamadığı şeyleri yapabilir:

• aynı anda birkaç geliştirme hattını (branch) yürütmek ve bunları birleştirmek;
• sürümler arasındaki farkı satır satır göstermek (git diff);
• farklı kişilerin aynı dosyalardaki düzenlemelerini birleştirmek;
• hatanın ortaya çıktığı commit'i bulmak (git bisect);
• internet olmadan çalışmak — tüm geçmiş yerel olarak sizde durur.

Git ne demek: adın anlamı

Git'in resmi bir açılımı yoktur, bir kısaltma değildir. Linus Torvalds programa kendi tarzında bir isim verdi: İngiliz argosunda git «sevimsiz, inatçı tip» anlamına gelir. Torvalds, bütün projelerine kendi adını verdiğini söyleyerek şaka yapmıştı. Kelimenin İngilizceden kabaca çevirisi «hergele», «ahmak» gibidir.

Projenin ilk README dosyasında yazar birkaç esprili açılım önermişti: örneğin her şey çalıştığında «global information tracker», bir şeyler bozulduğunda ise küfürlü bir versiyon. Yani bir mülakatta «Git'in açılımı nedir» diye sorulursa doğru cevap şudur: hiçbir şey, bu bir akronim değil, bir kelime.

Türkçede yazarken de konuşurken de genellikle «Git» denir. Tek heceli bir kelimedir ve «cit» değil «git» diye okunur.

Git nereden çıktı

2005 yılına kadar Linux çekirdeği geliştiricileri tescilli bir sistem olan BitKeeper'ı kullanıyordu. Topluluğa verilen ücretsiz lisans geri çekilince Torvalds birkaç hafta içinde kendi sistemini yazdı. Gereksinimler katıydı: devasa bir projede hız, tamamen dağıtık çalışma, geçmişin bozulmaya karşı güvenilir korunması ve binlerce paralel branch ile rahat çalışma.

Kısa süre sonra projenin bakımını Junio Hamano üstlendi ve hâlâ Git'in maintainer'ıdır. Bugün Git, GPLv2 lisanslı açık kaynak bir sistemdir; GitHub, GitLab, Bitbucket, Gitea ve kurumsal platformlar onun üzerine kuruludur.

Git nasıl çalışır: sistemin yapısı

Git'in sihirli komutlar yığını gibi görünmesini bırakmak için üç fikri anlamak yeterlidir. Bunlar sistemin davranışının neredeyse tamamını açıklar.

1. Farklar değil, anlık görüntüler

Eski sistemlerin çoğu değişiklikleri dosyalara uygulanan düzeltmeler dizisi olarak saklardı. Git ise anlık görüntülerle düşünür: her commit, kaydedildiği andaki projenin tam durumudur. Yer israf etmemek için değişmemiş dosyalar kopyalanmaz, commit yalnızca daha önce kaydedilmiş nesneye işaret eder. Depoyu paketlerken Git benzer nesneleri ayrıca sıkıştırır, bu yüzden büyük bir projenin geçmişi bile az yer kaplar.

2. Her şey hash ile adreslenir

Git'teki her nesne — dosya içeriği (blob), klasör yapısı (tree), commit (commit) — içeriğinden hesaplanan bir kimlik alır. Tarihsel olarak bu SHA-1'dir (40 onaltılık karakter); yeni sürümlerde SHA-256 tabanlı depo oluşturmak mümkündür. Eski bir commit'i fark ettirmeden değiştirmek imkânsızdır: onun hash'i ve ardından gelen tüm commit'lerin hash'leri değişir.

$ git log --oneline -3
a3f9c21 Giriş formunu ekle
7b02e4d E-posta doğrulamasını düzelt
1c8d5f0 İlk commit

Soldaki kısa diziler commit'lerin kısaltılmış hash'leridir. Bunlarla herhangi bir sürüme ulaşabilirsiniz: git show 7b02e4d.

3. Dosyaların üç durumu

Bu, Git'in temelinin temelidir ve neredeyse her mülakatta sorulur. Projedeki bir dosya üç alandan birinde bulunabilir:

Index, Git'i diğer pek çok sistemden ayıran şeydir. Değişikliklerin yalnızca bir kısmını commit'e koymanıza izin verir: örneğin hata düzeltmesini ayrı, değişken yeniden adlandırmalarını ayrı. Böylece geçmiş okunabilir olur.

Dağıtıklık: neden herkeste tam bir kopya var

Git dağıtık bir versiyon kontrol sistemidir (DVCS). Klonladığınızda sadece son dosyaları değil, projenin tüm geçmişini alırsınız. İşlemlerin çoğu — commit, geçmişi görüntüleme, branch oluşturma, karşılaştırma — sunucu olmadan, yerelde ve anında gerçekleşir.

Bu modelde GitHub gibi bir sunucu, ekibin ana kopya olarak üzerinde anlaştığı başka bir depo kopyasından ibarettir. Sunucu erişilemez olursa iş durmaz: commit atmaya devam eder, değişiklikleri daha sonra git push ile gönderirsiniz. Sunucu tamamen kaybolsa bile geçmiş herhangi bir klondan geri yüklenebilir.

Git ve GitHub aynı şey değildir

Yeni başlayanlarda sık görülen bir karışıklık. Git, bilgisayarınızda çalışan bir programdır. GitHub ise Git depolarının barındırıldığı ve ekip çalışması için araçlar sunan bir web hizmetidir: pull request, code review, issue'lar, CI. GitLab ve Bitbucket benzer hizmetlerdir.

Git'i GitHub olmadan da kullanabilirsiniz; örneğin kişisel notlar ya da yerel bir proje için. Ama Git olmadan GitHub'ın bir anlamı yoktur: tamamen onun depoları etrafında kurulmuştur.

Git temelleri: minimum çalışma döngüsü

Günlük çalışma böyle görünür. Bu birkaç komut, bir geliştiricinin her gün yaptığı işlerin büyük kısmını karşılar.

# mevcut klasörde depo oluştur
git init

# neyin değiştiğine bak
git status

# dosyaları index'e ekle
git add index.html style.css

# anlık görüntüyü kaydet
git commit -m "Ana sayfanın arayüzünü kodla"

# geçmişe bak
git log --oneline

# branch oluştur ve ona geç
git switch -c feature/login

# branch'i ana branch'e birleştir
git switch main
git merge feature/login

# değişiklikleri sunucuya gönder
git push origin main

git switch komutu Git 2.23'te, git checkout'un bazı işlevlerinin daha anlaşılır bir karşılığı olarak geldi. Eski talimatlarda git checkout -b feature/login görürsünüz — aynı şeydir.

git commit sırasında ne olur

Git, index'in içeriğini alır, her dosyayı blob olarak kaydeder, klasörler için tree nesneleri oluşturur ve bir commit nesnesi yaratır. Commit'te şunlar yazılıdır: ağaca referans, üst commit'e referans (birleştirmeden sonra iki tane), yazar, committer ve mesaj. Ardından mevcut branch'in işaretçisi yeni commit'e kaydırılır. Git'te branch kelimenin tam anlamıyla son commit'in hash'ini içeren bir dosyadır; bu yüzden branch'ler milisaniyeler içinde oluşturulur.

Git ne işe yarar: pratik nedenler

Deney yapmaktan korkmazsınız

Her değişiklik geri alınabilir. Kodu bozdunuz mu? git restore dosya son kaydedilmiş sürümü geri getirir. Hatalı bir commit zaten geçmişe girdi mi? git revert, ortak geçmişi yeniden yazmadan tersine bir commit oluşturur. Bu, çalışma tarzınızı değiştirir: geri almak saniyeler sürdüğü için daha cesurca denersiniz.

Kaossuz ekip çalışması

Her geliştirici kendi branch'inde çalışır ve diğerlerini rahatsız etmez. Görev hazır olduğunda değişiklikler review'dan geçer ve ana branch'e birleştirilir. İki kişi aynı bölümü düzenlediyse Git bir conflict gösterir ve başkasının emeğinin üzerine sessizce yazmak yerine onu bilinçli olarak çözmenize olanak tanır.

Dokümantasyon olarak geçmiş

İyi commit mesajları «kod neden böyle» sorusunu yanıtlar. git blame dosya komutu her satırı en son kimin ve hangi commit'te değiştirdiğini, git log -p dosya ise dosyanın tüm evrimini gösterir. Bir yıl sonra bu, saatlerce sürecek araştırmalardan kurtarır.

İşverenlerin beklentisi

Git bilgisi hemen hemen her geliştirici, test uzmanı, DevOps mühendisi ve veri analisti ilanında yer alır. Mülakatlarda ezberlenmiş komutlar değil, kavrayış sınanır: merge ile rebase arasındaki fark, index'in ne olduğu, bir commit'in nasıl geri alınacağı, conflict'in nasıl çözüleceği. Düzenli bir commit geçmişine sahip GitHub profili de portföy işlevi görür.

Git başka kimin işine yarar

Git, metin dosyalarının olduğu ve geçmişin önemli olduğu her yerde kullanışlıdır: teknik yazarlar (Markdown ile dokümantasyon), arayüz kodlayan tasarımcılar, analistler (SQL betikleri, notebook'lar), sistem yöneticileri (sunucu yapılandırmaları, kod olarak altyapı). Büyük ikili dosyalar — video, PSD, veri setleri — için Git LFS eklentisi kullanılır, çünkü Git'in kendisi metin için optimize edilmiştir.

Pro Git: Git üzerine en iyi kitap

Derinleşmek istiyorsanız Scott Chacon ve Ben Straub'un «Pro Git» kitabıyla başlayın. Ücretsizdir, açık lisansla dağıtılır ve resmi git-scm.com sitesinin Book bölümünde, çeşitli dil çevirileriyle birlikte yayımlanmıştır. Sık aranan «pro git» tam olarak budur: temellerden iç yapıya kadar eksiksiz bir ders kitabı.

Faydalı okumak için:

• 1–3. bölümler (giriş, temeller, branch'ler) zorunlu minimumdur, komutları terminalde tekrarlayın;
• uzak depolar ve GitHub ile çalışma bölümü — ekip içinde çalışmaya başladığınızda;
• «Git'in iç yapısı» bölümü — nesnelerin ve referansların nasıl işlediğini gerçekten anlamak istediğinizde.

İkinci resmi dayanak yerleşik yardımdır: git help commit veya git commit --help komutun tam belgesini açar, git commit -h ise bayrakların kısa özetini gösterir.

Yeni başlayanların tipik yanılgıları

• «Git dosyaları otomatik kaydeder». Hayır, commit atana kadar değişiklikler yalnızca çalışma dizininde var olur.
• «Commit hemen GitHub'a gider». Commit yereldir. Sunucuya ancak git push'tan sonra gider.
• «git add yeni dosyalar içindir». git add zaten takip edilen dosyalardaki değişiklikleri de index'e ekler.
• «Geçmişten silinen geri gelmez». Neredeyse her zaman gelir: git reflog işaretçilerin hareketlerini tutar ve «kaybolan» commit hash'iyle bulunur.
• «Branch'ler projenin kopyalarıdır». Branch, dosyaların bir kopyası değil, bir commit'e hafif bir işaretçidir.

Git öğrenmeye nereden başlamalı

1. Git'i kurun ve sürümünü kontrol edin: git --version.
2. Adınızı ve e-postanızı ayarlayın: git config --global user.name ve user.email.
3. Bir alıştırma deposu oluşturun, 5–10 commit atın, git log ve git diff çıktılarına bakın.
4. Branch'lerle çalışın: oluşturun, birleştirin, bilerek bir conflict yaratın ve çözün.
5. GitHub hesabı açın, deponuzu oraya gönderin, ilk pull request'inizi açın.

Bu sıra, başvuru kaynaklarını baştan sona okumaktan daha hızlı sonuç verir: her komutun depo durumunu nasıl değiştirdiğini hemen görürsünüz.

Özet

Git; proje geçmişini anlık görüntüler halinde saklayan, onu hash'lerle koruyan ve ekibin branch'lerde paralel çalışmasını sağlayan dağıtık bir versiyon kontrol sistemidir. Adının bir açılımı yoktur; pratikte ise her geliştiricinin olmazsa olmaz aracıdır. add — commit — push döngüsünü öğrenin, dosyaların üç alanını ve branch'leri kavrayın, ardından Pro Git kitabıyla derinleşin. Bunların hepsi, ilk commit'ten pull request'e kadar adım adım, Git kursunda uygulamalı olarak ele alınıyor.