← Kursa Dön
📄 Text · 30 min

Git Nedir? Versiyon Kontrol Tarihçesi

Giriş: Neden Bu Konuyu Öğreniyoruz?

Bir düşün: Bir yazılım projesi üzerinde çalışıyorsun. Haftalar süren emeğin var. Bir gece "küçük bir düzeltme" yapıyorsun ve sabah kalkınca uygulamanın çalışmadığını fark ediyorsun. Dünkü haline dönmek istiyorsun ama... hangi dosyaları değiştirdin? Ne eklemiştik, ne silmiştik? Hiçbir fikrin yok.

Daha kötüsü: Üç kişilik bir ekiptesin. Herkes aynı dosyalarda değişiklik yapıyor. Ali login sayfasını düzeltiyor, Ayşe aynı dosyada menüyü değiştiriyor. İkisi de aynı anda çalışıyor ve birinin değişiklikleri diğerinin üzerine yazılıyor. Kimin ne yaptığı kayıp.

İşte versiyon kontrol sistemi (Version Control System — VCS) tam olarak bu kabusu bitirmek için var. Ve Git, bu işi yapan araçların en güçlüsü, en yaygını ve en zekice tasarlanmışı.

Bu derste şunları öğreneceğiz:

  • Versiyon kontrolü fikri nasıl doğdu?

  • Hangi yaklaşımlar denendi, neden yetersiz kaldı?

  • Git neden ve nasıl yaratıldı?

  • Git'i diğer araçlardan ayıran şey ne?

Versiyon Kontrol Nedir?

📁 "Final_v2_GERCEKTEN_BU_SON.docx" Sendromu

Eğer bir zamanlar dosyalarını şöyle adlandırdıysan, yalnız değilsin:

rapor.docx
rapor_v2.docx
rapor_v2_duzeltilmis.docx
rapor_v2_duzeltilmis_FINAL.docx
rapor_v2_duzeltilmis_FINAL_gercekten_son.docx

Bu, insanlığın en ilkel versiyon kontrol yöntemi: dosyayı kopyala ve yeniden adlandır. Çalışır mı? Biraz. Ama:

  • Hangi dosya en güncel?

  • "v2_duzeltilmis" ile "v2" arasında ne değişti?

  • Geri dönmek istersen hangi adıma gideceksin?

  • Bir arkadaşın da aynı dosyayı düzenliyorsa nasıl birleştireceksin?

Bu soruları çözmek için versiyon kontrol sistemi icat edildi. VCS'nin yaptığı şeyi bir cümlede özetlersek:

Her değişikliğin ne zaman, kim tarafından, neden yapıldığını kaydeder ve istediğin ana geri dönmeni sağlar.

🎬 Analoji: Fotoğraf Albümü vs Video Kamera

Versiyon kontrolünü anlamanın en iyi yolu bir fotoğraf albümü düşünmek.

Bir proje geliştirirken yaptığın her anlamlı değişiklikten sonra bir fotoğraf (snapshot) çekiyorsun. "Giriş sayfası tamamlandı" — çık! "Kullanıcı kaydı eklendi" — çık! Her fotoğraf o anki projenin tam halini gösteriyor.

Bu fotoğraflar sıralı bir albüme konuyor. Albümü geriye doğru çevirebilir, istediğin fotoğrafa dönebilir, iki fotoğraf arasındaki farkları görebilirsin.

Ama bir de ekip var. Herkesin kendi albümü var. Herkes farklı açılardan fotoğraf çekiyor. Sonra bu albümleri birleştirmek istiyorsun. İşte Git'in en büyük gücü burada: herkesin albümünü akıllıca birleştirebilmesi.

📸 Proje Fotoğrafları (Commit'ler):

[Fotoğraf 1] → [Fotoğraf 2] → [Fotoğraf 3] → [Fotoğraf 4]
   "Proje        "Login          "Veritabanı     "CSS
    başladı"      eklendi"        bağlandı"       düzeltmesi"

Her fotoğraf = bir commit. Her commit, projenin o andaki tam fotoğrafı. Ve Git bu fotoğrafları çok verimli bir şekilde saklıyor — her seferinde tüm dosyaları kopyalamak yerine, sadece değişenleri kaydediyor.

VCS'nin Kısa Tarihi

Versiyon kontrol sistemleri bir gecede ortaya çıkmadı. Onlarca yıllık evrim geçirdiler. Bu tarihi bilmek, Git'in neden böyle tasarlandığını anlamak için önemli.

🏛️ 1. Nesil: Yerel Sistemler (1970-80'ler)

İlk VCS'ler tek bir bilgisayarda çalışıyordu.

RCS (Revision Control System, 1982): Dosyaların değişiklik geçmişini yerel olarak saklıyordu. Tek bir kullanıcı, tek bir bilgisayar.

┌─────────────────────────────┐
│         Bilgisayarım        │
│                             │
│  dosya.c  ←→  RCS veritabanı│
│              (değişiklikler) │
└─────────────────────────────┘

Sorun: Ekip çalışması yok. Herkes kendi makinesinde. Dosyaları paylaşmak için USB bellek veya e-posta gerekiyor. Evet, insanlar gerçekten bunu yapıyordu.

🏢 2. Nesil: Merkezi Sistemler (1990-2000'ler)

CVS (1990) ve Subversion/SVN (2000) ile merkezi model doğdu.

Burada tek bir sunucu var. Herkes bu sunucuya bağlanıyor. Değişiklikleri sunucuya gönderiyor, sunucudan alıyor.

                ┌──────────────┐
                │   SUNUCU     │
                │  (Merkezi    │
                │   Depo)      │
                └──────┬───────┘
                       │
            ┌──────────┼──────────┐
            │          │          │
       ┌────┴───┐ ┌───┴────┐ ┌──┴─────┐
       │ Ali'nin│ │Ayşe'nin│ │Mehmet'in│
       │   PC   │ │   PC   │ │   PC    │
       └────────┘ └────────┘ └────────┘

       Her PC'de sadece dosyaların SON HALİ var.
       Geçmiş? Sadece sunucuda.

İyileştirme: Artık ekip çalışması mümkün. Ali ve Ayşe aynı projede çalışabiliyor.

Ama ciddi sorunlar vardı:

  1. Tek nokta arızası (Single Point of Failure): Sunucu çökerse? Kimse çalışamaz. Geçmiş kaybolabilir.

  2. Ağ bağımlılığı: İnternetsiz commit bile yapamazsın. Uçakta, kafede, kırsalda — şansına küs.

  3. Yavaşlık: Her işlem sunucuyla iletişim gerektirdiği için log bakmak bile ağ hızına bağlıydı.

  4. Branching kabusu: SVN'de branch açmak mümkündü ama o kadar yavaş ve karmaşıktı ki, insanlar branch'lerden kaçınıyordu.

🌐 3. Nesil: Dağıtık Sistemler (2005-Günümüz)

İşte Git burada sahneye çıkıyor. Ama Git'in hikayesi oldukça dramatik.

Git'in Doğuş Hikayesi: Zorunluluktan Doğan Devrim

Linux Çekirdeği ve BitKeeper Krizi

2005 yılı. Linus Torvalds, Linux çekirdeğini (kernel) geliştiriyor. Dünya üzerindeki en büyük açık kaynak projelerinden biri. Binlerce geliştirici katkıda bulunuyor.

Linux ekibi, o zamana kadar BitKeeper adlı ticari bir dağıtık versiyon kontrol sistemi kullanıyordu. BitKeeper, Linux'a ücretsiz lisans vermişti. Ancak 2005'te bu lisans iptal edildi. (Detaylar tartışmalı, ama kısaca: Linux topluluğundan birinin BitKeeper'ı tersine mühendislik yapması şirketi kızdırdı.)

Linus'un elinde iki seçenek vardı:

  1. Mevcut açık kaynak VCS'lerden birini kullan (CVS, SVN, Monotone...)

  2. Kendi sistemini yaz

Linus mevcut araçlara baktı ve hiçbirini beğenmedi. Neden? Çünkü Linux çekirdeği gibi devasa bir proje için çok yavaştılar.

Linus'un Tasarım Hedefleri

Linus, yeni VCS'nin şu özelliklere sahip olması gerektiğini düşünüyordu:

  1. Hız: Binlerce dosya üzerinde saniyeler içinde çalışmalı

  2. Dağıtık yapı: Herkesin tam bir kopyası olmalı, merkeze bağımlılık olmamalı

  3. Veri bütünlüğü: Hiçbir veri bozulmamalı veya sessizce değişmemeli

  4. Basit dallanma (branching): Branch oluşturmak ve birleştirmek ucuz ve hızlı olmalı

  5. Büyük projeler: Yüz binlerce commit, binlerce dosya — sorunsuz çalışmalı

Ve Linus, 2 hafta içinde Git'in ilk versiyonunu yazdı. Evet, iki hafta. Nisan 2005'te geliştirmeye başladı, aynı ay içinde Linux çekirdeğinin versiyon kontrolü Git'e taşındı.

💡 İpucu: "Git" kelimesi İngiliz argosunda "inatçı, huysuz kişi" anlamına gelir. Linus, "I name all my projects after myself. First Linux, now Git." (Tüm projelerimi kendimden esinlenerek adlandırırım) demiştir. Kendine has mizahıyla...

Merkezi vs Dağıtık: Temel Fark

Bu ayrım Git'i anlamanın anahtarı. Eğer bu farkı kavrarsan, Git'in neden bazı şeyleri öyle yaptığını hep anlarsın.

Merkezi (Centralized) Model — SVN Tarzı

                    ┌──────────────────┐
                    │    SUNUCU (SVN)  │
                    │                  │
                    │  Tüm geçmiş     │
                    │  Tüm branch'ler │
                    │  Tüm commit'ler │
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
         ┌────┴────┐   ┌────┴────┐   ┌────┴────┐
         │   Ali   │   │  Ayşe   │   │  Mehmet  │
         │         │   │         │   │          │
         │ Sadece  │   │ Sadece  │   │ Sadece   │
         │ son hal │   │ son hal │   │ son hal  │
         └─────────┘   └─────────┘   └──────────┘

  • Sunucu = tek gerçek kaynak (single source of truth)

  • Geliştiricilerde sadece dosyaların son hali var

  • Geçmişe bakmak, branch açmak → sunucuya bağlan

  • Sunucu çökerse = felaket

Dağıtık (Distributed) Model — Git Tarzı

    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
    │     Ali       │    │    Ayşe      │    │    Mehmet     │
    │               │    │              │    │              │
    │ TÜM geçmiş  │    │ TÜM geçmiş  │    │ TÜM geçmiş  │
    │ TÜM branch  │    │ TÜM branch  │    │ TÜM branch  │
    │ TÜM commit  │    │ TÜM commit  │    │ TÜM commit  │
    └──────┬───────┘    └──────┬───────┘    └──────┬───────┘
           │                   │                   │
           └───────────────────┼───────────────────┘
                               │
                    ┌──────────┴──────────┐
                    │   GitHub / GitLab   │
                    │   (Uzak Depo —      │
                    │    isteğe bağlı)    │
                    └─────────────────────┘

  • Her geliştirici, projenin tam kopyasına sahip

  • İnternetsiz çalışabilirsin: commit at, branch aç, geçmişe bak

  • GitHub/GitLab var ama "merkez" değil — sadece kolaylık sağlayan bir paylaşım noktası

  • Sunucu çökerse? Herkesin yedeği var. Ali'nin bilgisayarından komple geri yükleme yapılabilir.

Pratik Fark Tablosu

ÖzellikMerkezi (SVN)Dağıtık (Git)
Offline çalışma❌ Hayır✅ Tam destek
Hız🐌 Ağa bağlı⚡ Yerel, çok hızlı
Yedekleme😰 Tek nokta😎 Her kopya bir yedek
Branch açma🐌 Yavaş, zahmetli⚡ Saniyenin altında
Geçmişe bakma🐌 Sunucuya bağlan⚡ Hep yerel
Öğrenme eğrisi📉 Daha basit📈 Daha dik ama daha güçlü

Git'in Temel Felsefesi

Git'i kullanırken "neden böyle?" diye soracağın anlar olacak. Bu felsefeyi bilmek, cevapları kendinin bulmasını sağlar.

1. Snapshot, Diff Değil

Eski VCS'ler (CVS, SVN) dosyaların farklarını (diff) saklıyordu:

SVN Yaklaşımı (Delta-based):

Dosya v1 → [değişiklik 1] → [değişiklik 2] → [değişiklik 3]

v3'ü görmek için: v1 + değişiklik1 + değişiklik2 + değişiklik3 uygula

Git ise her commit'te projenin tamamının anlık görüntüsünü (snapshot) saklar:

Git Yaklaşımı (Snapshot-based):

Commit 1: [dosya_A_v1] [dosya_B_v1] [dosya_C_v1]
Commit 2: [dosya_A_v1] [dosya_B_v2] [dosya_C_v1]  ← sadece B değişmiş
Commit 3: [dosya_A_v2] [dosya_B_v2] [dosya_C_v2]

(Değişmeyen dosyalar için önceki versiyona referans tutar — kopyalamaz)

Bu yaklaşım sayesinde:

  • Herhangi bir commit'e anında gidebilirsin (diff'leri toplamak gerekmez)

  • Branch'ler arası geçiş çok hızlı

  • Veri bütünlüğü kolay doğrulanır

2. Her Şey Yerel

Git'te neredeyse her işlem yerel diskte gerçekleşir:

  • git log → yerel

  • git diff → yerel

  • git branch → yerel

  • git commit → yerel

Ağa erişim gerektiren tek işlemler: git push, git pull, git fetch — yani sadece uzak depoyla senkronizasyon.

Bu yüzden Git inanılmaz hızlı. SVN'de "git log" muadili komut her seferinde sunucuyla konuşurken, Git'te milisaniyeler içinde tamamlanır.

3. Veri Bütünlüğü: SHA-1 Hash

Git'te her şey bir hash ile tanımlanır. Bir dosyayı, bir commit'i, bir klasörü — Git her birini SHA-1 algoritmasıyla özetler (hash'ler):

Örnek SHA-1 hash:
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

Bu 40 karakterlik hexadecimal string, içeriğin parmak izi gibidir. İçerik 1 bit bile değişse, hash tamamen farklı olur.

Neden önemli?

  • Bir dosya bozulursa, hash değişir → Git anında fark eder

  • Commit geçmişiyle oynanırsa, hash'ler tutmaz → tespit edilir

  • İki farklı bilgisayardaki aynı içerik → aynı hash → eşleştirme kolay

⚠️ Dikkat: Git, SHA-1 hash kullanır. SHA-1'de nadir de olsa çarpışma (collision) üretmek teorik olarak mümkündür. Git, gelecekte SHA-256'ya geçiş sürecindedir. Ama pratikte bu hiçbir zaman sorun olmadı — milyarlarca commit arasında çarpışma olasılığı astronomik düzeyde düşüktür.

4. Üç Alan (Three States)

Git, dosyalarını üç temel alanda yönetir. Bu, Git'in en önemli kavramlarından biri ve bir sonraki derste detaylı işleyeceğiz. Şimdilik genel resmi görelim:

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Working    │     │   Staging    │     │  Repository  │
│  Directory   │────▶│    Area      │────▶│   (.git)     │
│              │ add │  (Index)     │commit│              │
│  Dosyalarını │     │  Sahneye     │     │  Kalıcı      │
│  düzenlediğin│     │  hazırladığın│     │  kayıt       │
│  yer         │     │  yer         │     │              │
└──────────────┘     └──────────────┘     └──────────────┘

Bunu bir fotoğraf stüdyosuna benzetebiliriz:

  • Working Directory = stüdyo — istediğin gibi düzenle, dağıt, topla

  • Staging Area = fotoğraf çekimi için hazırlanan set — "bu kareleri çekeceğim" dediğin alan

  • Repository = çekilmiş ve arşive konmuş fotoğraflar — kalıcı kayıt

Bu üç katmanlı yapı, Git'e inanılmaz esneklik kazandırır. Değişikliklerini parça parça commit'leyebilirsin.

Git'in Etkisi: Rakamlarla Git

Git'in ne kadar yaygın olduğunu anlamak için bazı rakamlar:

  • GitHub: 100+ milyon geliştirici, 400+ milyon repository (2024)

  • Kullanım oranı: Stack Overflow anketlerinde geliştiricilerin %93+'ü Git kullanıyor

  • Alternatifler: Mercurial, SVN, Perforce hâlâ kullanılıyor ama Git baskın

  • Şirketler: Google, Microsoft, Meta, Netflix, Amazon — hepsi Git kullanıyor

Git, bir araç olmaktan öte, modern yazılım geliştirmenin ortak dili haline geldi.

Git vs Diğer VCS'ler

Git vs SVN (Subversion)

SVN hâlâ bazı büyük şirketlerde ve eski projelerde kullanılıyor. Temel farklar:

Senaryo: 10,000 commit'lik bir projenin geçmişine bakmak

SVN:
$ svn log                   # Sunucuya istek gönderir
Ağ bekleme... 2-5 saniye... # Sonuçlar gelir

Git:
$ git log                   # Yerel diskten okur
Anında — 0.01 saniye        # Her şey zaten sende
Senaryo: Yeni bir branch oluşturmak

SVN:
$ svn copy trunk branches/feature  # Sunucudaki dosyaları kopyalar
Ağ bekleme... dosyalar kopyalanıyor...

Git:
$ git branch feature               # 41 byte'lık bir dosya oluşturur
Bitti. 0.001 saniye.               # Branch = sadece bir pointer

Git vs Mercurial (Hg)

Mercurial da dağıtık bir VCS. Aynı yıl (2005) doğdu. Git'e en yakın rakibi.

  • Mercurial daha basit ve tutarlı bir komut seti sunar

  • Git daha güçlü ve esnek ama öğrenme eğrisi daha dik

  • Sonuç: Git kazandı. GitHub'un etkisi büyük — Mercurial topluluğu küçüldü

💡 İpucu: Neden Git kazandı? Büyük ölçüde GitHub sayesinde. GitHub 2008'de açıldı ve open source projelerin Git'e taşınmasını tetikledi. Araç iyi olabilir ama ekosistem belirleyici olur. Git'in GitHub, GitLab, Bitbucket gibi devasa bir ekosistemi var.

Git Ne İşe Yarar? Gerçek Kullanım Senaryoları

1. Zaman Yolculuğu

# 3 ay önceki projenin haline bak
git log --oneline
# a1b2c3d Login sayfası eklendi
# d4e5f6g Veritabanı bağlantısı
# h7i8j9k Proje başlatıldı

git checkout h7i8j9k    # Projeyi ilk haline geri götür
git checkout main       # Tekrar bugüne dön

2. Paralel Geliştirme

# Ana projeden bağımsız, yeni özellik geliştir
git branch yeni-ozellik
git checkout yeni-ozellik
# ... kodla, test et, dene ...
# Hazır olunca ana projeye birleştir
git checkout main
git merge yeni-ozellik

3. Ekip Çalışması

# Arkadaşının değişikliklerini al
git pull origin main
# Kendi değişikliklerini gönder
git push origin main

4. Güvenli Deneme

# Radikal bir değişiklik denemek istiyorsun
git branch deney
git checkout deney
# ... her şeyi alt üst et ...
# Olmadı mı? Sil gitsin
git checkout main
git branch -D deney
# Ana proje tertemiz, hiç dokunulmamış

5. Bug Avı

# Hangi commit ile bug girmiş? Git bulsun:
git bisect start
git bisect bad          # Şu an bozuk
git bisect good v1.0    # v1.0'da çalışıyordu
# Git, binary search ile sorumlu commit'i bulur

Git'in Yapamadığı Şeyler

Git mucize değil. Neyi yapmadığını bilmek de önemli:

  1. Büyük binary dosyalar: Git, metin dosyaları için mükemmeldir. Ama 2GB'lık video veya PSD dosyaları için uygun değildir. (Bunun için Git LFS var — ileri bölümlerde göreceğiz.)

  2. Otomatik yedekleme: Git bir backup aracı değil. Commit yapmazsan, değişiklik kaydedilmez. Git sana aracı verir — kullanmak senin sorumluluğun.

  3. Dosya kilitleme: İki kişi aynı binary dosyayı düzenliyorsa, Git bunu otomatik birleştiremez. (Metin dosyalarını birleştirebilir.)

  4. Proje yönetimi: Git versiyon kontrolü yapar. Görev yönetimi, sprint planlama, bug tracking için GitHub Issues, Jira gibi araçlar gerekir.

Yaygın Yanlış Anlamalar

"Git = GitHub" ❌

Bu en yaygın karışıklık. Açıkça söyleyelim:

  • Git = versiyon kontrol yazılımı. Bilgisayarında çalışır. Ücretsiz, açık kaynak.

  • GitHub = Git depolarını barındıran web servisi. Microsoft'a ait. Sosyal kodlama platformu.

Git olmadan GitHub olmaz ama GitHub olmadan Git gayet çalışır.

Git ≠ GitHub

Git = Motor
GitHub = Otopark + Showroom + Sosyal Klüp

Diğer otoparklar da var:
- GitLab (self-hosted yapabilirsin)
- Bitbucket (Atlassian - Jira ile entegre)
- Gitea (hafif, self-hosted)
- Azure DevOps (Microsoft)

"Git zor" ❓

Git'in öğrenme eğrisi var, doğru. Ama:

  • Günlük kullanım için 5-6 komut yeterli (add, commit, push, pull, branch, merge)

  • Zor kısımlar (rebase, cherry-pick, reflog) ileri seviye — ve genelde nadiren lazım

  • Bir kere mantığını kavrayınca, tüm komutlar anlamlı hale geliyor

Bu kurs boyunca adım adım ilerleyeceğiz. Panik yok.

Git Ekosistemi: Büyük Resim

Git tek başına bir komut satırı aracı. Ama etrafında devasa bir ekosistem oluşmuş:

                         ┌───────────────────┐
                         │      Git CLI      │
                         │  (Komut Satırı)   │
                         └────────┬──────────┘
                                  │
                 ┌────────────────┼────────────────┐
                 │                │                │
          ┌──────┴──────┐  ┌─────┴──────┐  ┌──────┴──────┐
          │   GUI'ler   │  │  Hosting   │  │   CI/CD     │
          │             │  │            │  │             │
          │ VS Code Git │  │ GitHub     │  │ GitHub      │
          │ GitKraken   │  │ GitLab     │  │  Actions    │
          │ Sourcetree  │  │ Bitbucket  │  │ Jenkins     │
          │ Fork        │  │ Gitea      │  │ GitLab CI   │
          └─────────────┘  └────────────┘  └─────────────┘

  • GUI Araçları: Komut satırını sevmiyorsan grafik arayüzler var. Ama bu kursta CLI öğreneceğiz — temeli bilmek şart.

  • Hosting: Kodunu bulutta tutmak, paylaşmak, işbirliği yapmak için.

  • CI/CD: Kodun her push'ta otomatik test edilmesi, derlenmesi, deploy edilmesi.

Neden Git Öğrenmeliyim?

Eğer yazılım dünyasında kariyer yapacaksan, Git bilmek:

  1. Zorunlu: Neredeyse tüm iş ilanlarında Git bilgisi isteniyor

  2. Evrensel: Frontend, backend, mobile, DevOps, data science — herkes kullanıyor

  3. Verimlilik: Doğru kullanınca saatler kazandırır, yanlış kullanınca saatler kaybettirir

  4. İşbirliği: Modern yazılım ekip işi — Git olmadan ekip çalışması mümkün değil

  5. Portföy: GitHub profilin, CV'nin bir parçası — işverenler bakıyor

Özet

  • Versiyon Kontrol Sistemi (VCS), dosyalardaki değişikliklerin geçmişini takip eden ve geri dönüş imkânı veren bir sistemdir

  • VCS'ler yerel → merkezi → dağıtık olarak evrildi; Git, dağıtık neslin en başarılı temsilcisidir

  • Git, 2005'te Linus Torvalds tarafından Linux çekirdeği için yaratıldı — hız, güvenlik ve dağıtık yapı öncelikli tasarlandı

  • Git'te her geliştirici tam bir kopyaya sahiptir — internet olmadan da çalışabilirsin

  • Git snapshot (anlık görüntü) tabanlıdır, diff (fark) tabanlı değil — bu onu hızlı ve güvenilir kılar

  • Git ≠ GitHub: Git bir araç, GitHub o aracı kullanan bir platform. Git'i öğrenmek, GitHub'dan bağımsız bir beceridir

*Bir sonraki derste Git'i bilgisayarına kuracak ve ilk yapılandırmalarını yapacağız. Ellerini kirletme zamanı!*