Git Depo Yapısı: Eksiksiz Teknik Kılavuz

Git, proje geçmişini değiştirilemez anlık görüntü nesnelerinden oluşan yönlendirilmiş döngüsüz bir grafik (DAG) olarak depolayan bir dağıtık sürüm kontrol sistemidir. Her Git deposu üç mantıksal bölgeden oluşur — çalışma dizini, hazırlama indeksi ve .git/ içindeki nesne deposu — bunlara ek olarak bu geçmişte gezinmeyi sağlayan bir dizi hafif işaretçi (dallar, etiketler, uzak depolar) bulunur. Bu katmanların nasıl etkileşime girdiğini anlamak, Git’i mekanik olarak kullanmak ile cerrahi bir hassasiyetle kullanmak arasındaki farktır.

Depolarınızı bir VPS üzerinde kendi sunucunuzda barındırıyorsanız, bu iç yapıya hakim olmak; felaket senaryolarından kurtulmanızı, verimli CI/CD pipeline’ları tasarlamanızı ve üçüncü taraf bir platforma bağımlı kalmadan projenizin geçmişindeki her baytı denetlemenizi sağlar.

Üç Bölge Modeli: Git Verileri Nasıl Taşır

Tek tek bileşenlere dalmadan önce, her Git işlemini yöneten veri akışı modelini içselleştirin:

Working Directory  -->  Staging Area (Index)  -->  .git/ Object Store
     (edit)               (git add)                  (git commit)

Bir commit oluştururken değişiklikler soldan sağa, geri yükleme veya sıfırlama yaparken ise sağdan sola doğru ilerler. Her Git komutu, özünde bu bölgelerden biri veya birkaçı üzerinde gerçekleştirilen bir okuma ya da yazma işlemidir.

Çalışma Dizini

Çalışma dizini (çalışma ağacı olarak da bilinir), projenizin belirli bir checkout durumundaki dosya sistemi görünümüdür. git clone veya git checkout komutunu çalıştırdığınızda Git, .git/objects/ içindeki sıkıştırılmış nesnelerden dosyaları yeniden oluşturur ve bu dizine yazar.

Çalışma dizinindeki dosyalar dört durumdan birinde bulunur:

• İzlenmeyen (Untracked) — Git bu dosyayı hiç görmemiştir; yalnızca diskte mevcuttur.
• İzlenen, değiştirilmemiş — dosya, son commit anlık görüntüsüyle tam olarak eşleşmektedir.
• İzlenen, değiştirilmiş — dosya, son commit anlık görüntüsünden farklıdır ancak henüz hazırlamaya alınmamıştır.
• İzlenen, silinmiş — dosya diskten kaldırılmıştır ancak silme işlemi henüz hazırlamaya alınmamıştır.

Birçok geliştiricinin tökezlediği kritik bir nüans: çalışma dizini, deponun basit bir kopyası değildir. Git, onu ağaç nesnelerini okuyarak ve blob nesnelerini sıkıştırmadan açarak yeniden oluşturur. .git/ bütünse, çalışma dizinini sıfırdan her zaman yeniden oluşturabilirsiniz — bunun tersi doğru değildir.

Büyük Monorepo’lar için Seyrek Checkout

On binlerce dosya içeren depolarda (monorepo mimarilerinde yaygındır), Git’in çalışma dizininde hangi yolları somutlaştıracağını sınırlayabilirsiniz:

git sparse-checkout init --cone
git sparse-checkout set services/api services/auth

Bu, kısıtlı disk G/Ç’sine sahip bir VPS‘te son derece değerlidir; çünkü Git, koni dışındaki yollar için blob’ları sıkıştırmadan açmayı atlar.

Hazırlama Alanı (Index)

Dahili olarak index adıyla bilinen hazırlama alanı, .git/index konumunda bulunan bir ikili dosyadır. Çalışma dizininiz ile kalıcı nesne deposu arasında yer alan, önerilen bir sonraki commit olarak işlev gören değiştirilebilir bir anlık görüntüdür.

git add <file>          # Stage a specific file
git add -p              # Interactively stage hunks within a file
git add -u              # Stage all tracked modifications and deletions
git status              # Compare working directory and index against HEAD
git diff --cached       # Show diff between index and HEAD

Index Neden Var

Index, daha basit VCS araçlarının görmezden geldiği bir sorunu çözer: kısmi commit’ler. Beş dosyayı değiştirmiş olabilirsiniz ancak yalnızca üçünü bir sonraki commit’e dahil etmek istiyorsunuzdur. Index, editörünüzde nelerin açık olduğundan bağımsız olarak kaydetmek istediğiniz anlık görüntüyü tam olarak oluşturmanıza olanak tanır.

Uç durum — index bozulması: Bir sistem çökmesi git add işlemini yarıda keserse, index dosyası bozulabilir. Belirtiler arasında git status komutunun takılı kalması veya garip çıktılar vermesi sayılabilir. Kurtarma:

rm .git/index
git reset

Git, çalışma dizininize dokunmadan index’i HEAD üzerinden yeniden oluşturur.

Birleştirme Çakışma Kaydı Olarak Index

Bir birleştirme çakışması sırasında index, çakışan her dosyanın üç sürümünü aynı anda depolar (aşama 1, 2 ve 3 — taban, bizimki, onlarınki). Bu nedenle git diff --cached çakışma ortasında yararlı bir şey göstermez; üç aşamanın tamamını incelemek için git diff --cc veya bir birleştirme aracı kullanmanız gerekir.

.git/ Dizini: Nesne Deposunun Anatomisi

.git/ dizini, deponun kendisidir. Diğer her şey — çalışma dizini, uzak klonlar — ondan türetilir. .git/ silindiğinde bir depo, geçmişi olmayan sıradan bir dizine dönüşür.

.git/
├── HEAD
├── config
├── description
├── index
├── COMMIT_EDITMSG
├── hooks/
├── info/
├── logs/
│   ├── HEAD
│   └── refs/
├── objects/
│   ├── info/
│   └── pack/
└── refs/
    ├── heads/
    ├── remotes/
    └── tags/

HEAD

HEAD, bir sembolik ref (bir dala işaret eden) veya ham bir SHA-1 hash’i (ayrık HEAD durumu) içeren düz metin bir dosyadır.

cat .git/HEAD
# ref: refs/heads/main        <-- on a branch
# a3f1c9d...                  <-- detached HEAD

Ayrık HEAD bir hata durumu değildir — bir etiketi veya belirli bir commit’i inceleme amacıyla checkout ettiğinizde kasıtlı olarak gerçekleşir. Tehlike, ayrık HEAD durumunda commit yapmaktır: bu commit’ler, bir dala bağlanana kadar yalnızca reflog aracılığıyla erişilebilir olur.

git checkout -b rescue-branch   # Attach detached commits to a new branch

config

Yerel depo yapılandırma dosyasıdır. Global (~/.gitconfig) ve sistem (/etc/gitconfig) ayarlarını geçersiz kılar. Yaygın girişler:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
[remote "origin"]
    url = git@github.com:user/repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
    remote = origin
    merge = refs/heads/main

Kendi sunucunuzda barındırılan bir sunucuda, uzak URL’leri değiştirirken veya kısmi klonlar için uploadpack.allowReachableSHA1InWant yapılandırırken bu dosyayı doğrudan sık sık düzenleyeceksiniz.

refs/

refs/ dizini, her biri tek bir SHA-1 hash’i tutan düz metin dosyaları içerir. Bunlar, Git’in DAG’ını gezilebilir kılan adlandırılmış işaretçilerdir.

Performans açısından Git, bir depoda çok sayıda ref biriktiğinde bunları .git/packed-refs içinde paketler. Ref’lere karşı betik yazarken her iki konumu da kontrol etmeyi unutmayın.

Git Nesneleri: Değiştirilemez Çekirdek

.git/objects/ içinde depolanan her şey içerik adreslidir: dosya adı, nesnenin içeriğinin SHA-1 (veya daha yeni Git sürümlerinde SHA-256) hash’idir. Bu, Git’i doğası gereği kurcalamaya karşı dayanıklı kılar — herhangi bir baytı değiştirmek hash’i değiştirir ve zinciri kırar.

Dört Nesne Türü

Nesneleri Doğrudan İnceleme

# Show the type of any object
git cat-file -t a3f1c9d

# Show the content of any object
git cat-file -p a3f1c9d

# Show the tree of the current HEAD commit
git ls-tree HEAD

# Show a specific blob's content
git show HEAD:src/main.py

Gevşek Nesneler ve Paket Dosyaları

Başlangıçta her nesne, .git/objects/<2-char-prefix>/<38-char-suffix> altında ayrı bir sıkıştırılmış dosya olarak depolanır. Bunlar gevşek nesnelerdir. Zamanla Git, gevşek nesneleri karşılık gelen bir indeksle (.pack.idx) birlikte paket dosyalarına (.git/objects/pack/*.pack) paketlemek için git gc (çöp toplama) çalıştırır.

Paket dosyaları delta sıkıştırması kullanır — tam kopyalar yerine benzer nesneler arasındaki farkı depolar. Binlerce benzer metin dosyası içeren bir depo, paketleme sonrasında dramatik biçimde küçülebilir. Sınırlı NVMe kapasitesine sahip bir VPS‘te, arşivlemeden önce büyük depolarda git gc --aggressive çalıştırmak standart bir uygulamadır.

git count-objects -vH    # Show loose object count and disk usage
git gc --aggressive      # Repack aggressively (CPU-intensive)
git verify-pack -v .git/objects/pack/*.idx | sort -k3 -n | tail -20
# Find the 20 largest objects in the pack

Commit Geçmişi: Yönlendirilmiş Döngüsüz Graf

Her commit nesnesi, bir ağaç nesnesine (kök dizin anlık görüntüsü) tam olarak bir işaretçi ve üst commit’lere sıfır veya daha fazla işaretçi içerir. Bu, şu özelliklere sahip bir DAG oluşturur:

• Sıfır üst = ilk commit (kök commit)
• Bir üst = normal bir commit
• İki üst = birleştirme commit’i
• Üç veya daha fazla üst = ahtapot birleştirmesi (nadir, aynı anda birçok özellik dalını entegre etmek için kullanılır)

git log --oneline --graph --all    # Visualize the full DAG
git log --format="%H %P"           # Show each commit's SHA and parent SHA(s)

Commit Değiştirilemezliği ve Geçmişi Yeniden Yazma

Bir commit’in SHA’sı içeriğinden (üst SHA’lar dahil) türetildiğinden, herhangi bir yeniden yazma işlemi yeni bir SHA ile yeni bir commit oluşturur. git rebase, git commit --amend ve git filter-repo gibi işlemler geçmişi değiştirmez — paralel bir geçmiş oluştururlar. Eski commit’ler, çöp toplanana kadar nesne deposunda kalmaya devam eder.

Bu nedenle paylaşılan bir dala yeniden yazılmış geçmişi zorla push etmek yıkıcıdır: iş arkadaşlarının yerel dalları hâlâ eski commit zincirine işaret etmektedir.

Dallar: Hafif İşaretçiler

Bir dal, SHA-1 hash’i içeren 41 baytlık bir dosyadan ibarettir. Dal oluşturmak, Git yalnızca küçük bir dosya yazdığından depo boyutundan bağımsız olarak anlıktır.

git branch feature/auth           # Create branch at current HEAD
git checkout -b feature/auth      # Create and switch in one step
git switch -c feature/auth        # Modern equivalent (Git 2.23+)
git branch -d feature/auth        # Delete (safe: refuses if unmerged)
git branch -D feature/auth        # Delete (force: regardless of merge status)

Dal İç Yapısı

cat .git/refs/heads/main
# a3f1c9d8e2b1f4c7d9e0a1b2c3d4e5f6a7b8c9d0

Bir dalda commit yaptığınızda Git, yeni commit SHA’sını bu dosyaya yazar. “Dal işaretçisini ilerletmek” işleminin tamamı budur.

Takip Dalları ve Upstream Yapılandırması

Bir takip ilişkisi, Git’e yerel bir dalın git status sapma raporlaması ve git pull davranışı için hangi uzak dalla karşılaştırılması gerektiğini söyler.

git branch --set-upstream-to=origin/main main
git branch -vv    # Show tracking relationships and ahead/behind counts

Etiketler: Geçmişte Kalıcı İşaretler

Etiketler, belirli commit’leri önemli olarak işaretler — genellikle yazılım sürümleri için kullanılır. Dalların aksine, etiketler yeni commit’lerle taşınmaz.

git tag v2.1.0                              # Lightweight tag at HEAD
git tag -a v2.1.0 -m "Release 2.1.0"       # Annotated tag
git tag -s v2.1.0 -m "Signed release"      # GPG-signed annotated tag
git push origin --tags                      # Push all tags to remote
git push origin v2.1.0                      # Push a specific tag

Kritik tuzak: git push varsayılan olarak etiketleri push etmez. Ekipler bunu sık sık unutur ve uzak depoda bulunmayan bir etikete atıfta bulunan sürüm notları yayımlar.

Uzak Depolar: Dağıtık İş Birliği

Bir uzak depo, .git/config içinde depolanan adlandırılmış bir URL’dir. Uzak takip dalları (refs/remotes/ altında), yalnızca açıkça fetch yaptığınızda güncellenen, uzak deponun dallarının yerel salt okunur anlık görüntüleridir.

git remote add origin git@github.com:user/repo.git
git remote -v                          # List remotes with URLs
git remote set-url origin <new-url>    # Change a remote URL
git fetch origin                       # Update remote-tracking branches
git fetch --prune                      # Remove stale remote-tracking branches
git push origin main                   # Push local main to remote
git push -u origin feature/auth        # Push and set upstream tracking

Birden Fazla Uzak Depo

Tek bir depo birden fazla uzak depoyu takip edebilir — bu, bir fork’u upstream ile birlikte yönetirken yaygındır:

git remote add upstream git@github.com:original/repo.git
git fetch upstream
git merge upstream/main

Ekibiniz için bir dedicated server üzerinde bare depolar barındırırken, her geliştirici sunucuyu uzak depo olarak ekler ve push erişimi için SSH anahtar kimlik doğrulaması kullanır.

Hook’lar: Her Git Olayında Otomatik Uygulama

Hook’lar, .git/hooks/ içindeki çalıştırılabilir betiklerdir. Git bunları iş akışındaki belirli noktalarda çağırır. git clone veya git push tarafından aktarılmazlar — her geliştirici (veya sunucu) bunları bağımsız olarak kurmalıdır. Bu, ekip ortamlarında sık karşılaşılan bir karışıklık kaynağıdır.

İstemci Tarafı Hook’lar

Sunucu Tarafı Hook’lar

Örnek: Gizli Tespit için Pre-commit Hook

#!/usr/bin/env bash
# .git/hooks/pre-commit

if git diff --cached --name-only | xargs grep -lE '(AKIA|passwords*=|api_keys*=)' 2>/dev/null; then
    echo "ERROR: Potential secret detected in staged files. Commit aborted."
    exit 1
fi
exit 0

Çalıştırılabilir yapın:

chmod +x .git/hooks/pre-commit

Ekip genelinde hook dağıtımı için Husky (Node.js projeleri) gibi bir araç kullanın ya da hook’ları depo kökünde bir hooks/ dizininde saklayın ve proje kurulumu sırasında sembolik bağlantı oluşturun.

Reflog: Güvenlik Ağı

Reflog, geçmişi yok ettiği görünen işlemler (hard reset’ler, rebase’ler, değiştirilmiş commit’ler) dahil olmak üzere HEAD ve dal işaretçilerinin her hareketini kaydeder. .git/logs/ konumunda depolanır.

git reflog                          # Show HEAD movement history
git reflog show main                # Show movement history for a specific branch
git checkout HEAD@{3}               # Check out the state HEAD was in 3 moves ago
git branch recovered HEAD@{5}       # Recover commits by branching from a reflog entry

Reflog girişleri varsayılan olarak 90 gün sonra sona erer (gc.reflogExpire). Bir üretim sunucusunda bunu uzatmayı düşünebilirsiniz:

git config gc.reflogExpire 180
git config gc.reflogExpireUnreachable 30

Bare Depolar: Sunucu Tarafı Barındırma

Bir bare depo‘nun çalışma dizini yoktur. Yalnızca kök düzeyinde .git/ içeriğini barındırır. Bare depolar, merkezi barındırma için doğru formattır — checkout edilmiş bir dalın karmaşıklıkları olmadan push’ları kabul ederler.

git init --bare /srv/repos/myproject.git

GitHub, GitLab veya kendi barındırdığınız bir Git sunucusuna push yaptığınızda, bir bare depoya push yapıyorsunuzdur. Git sunucunuzu cPanel’li bir VPS veya ham Linux VPS üzerinde barındırıyorsanız, SSH erişimiyle /srv/repos/ altındaki bare depolar standart mimaridir.

Paylaşılan Bare Depo Başlatma

# On the server
git init --bare --shared=group /srv/repos/project.git
chown -R git:developers /srv/repos/project.git

# On a developer's machine
git remote add origin git@yourserver.com:/srv/repos/project.git
git push -u origin main

Git Nesne Depolama: Boyut, Bütünlük ve Bakım

Depo Sağlığını Kontrol Etme

git fsck --full          # Verify object integrity (finds dangling and corrupt objects)
git fsck --lost-found    # Write dangling objects to .git/lost-found/

Büyük Nesneleri Bulma ve Kaldırma

Yanlışlıkla commit edilen büyük ikili dosyalar, şişirilmiş depoların yaygın bir nedenidir. Bunları çıkarmak için git filter-repo kullanmadan önce tespit edin:

# Find the 10 largest objects by compressed size
git verify-pack -v .git/objects/pack/*.idx 
  | sort -k3 -rn 
  | head -10 
  | awk '{print $1}' 
  | xargs -I{} git cat-file -p {}

# Remove a file from all history (requires git-filter-repo)
git filter-repo --path path/to/large-file.bin --invert-paths

Filtrelemeden sonra tüm iş arkadaşları yeniden klonlamalıdır — yerel depolarındaki SHA hash’leri artık yeniden yazılmış geçmişte mevcut değildir.

Karşılaştırma: Temel Git Depo Kavramları

Pratik Karar Matrisi ve Temel Çıkarımlar

Altyapınızda bir Git deposu kurarken veya denetlerken bu kontrol listesini kullanın:

Depo başlatma

• Birden fazla kullanıcıdan push alacak her depo için git init --bare --shared=group kullanın.
• Bare depoları web’den erişilebilir dizinlerin dışında saklayın (asla /var/www/ altında değil).

Nesne deposu sağlığı

• Herhangi bir depolama olayı veya dosya sistemi hatasından sonra git fsck --full çalıştırın.
• Uzun ömürlü depolarda periyodik olarak git gc planlayın; sunucunuzda cron aracılığıyla otomatikleştirin.
• Paket dosyası boyutunu git count-objects -vH ile izleyin; gevşek nesne sayısı 1.000’i aşarsa araştırın.

Dal ve ref hijyeni

• Birleştirilmiş dalları derhal silin; eski ref’ler birikir ve git fetch --prune işlemlerini yavaşlatır.
• Silinmiş uzak dallara göre işlem yapmaktan kaçınmak için CI pipeline’larında git fetch --prune kullanın.

Hook dağıtımı

• Ekip genelinde politika için .git/hooks/ hook’larına güvenmeyin — hook’lar klonlanmaz. Bunun yerine sunucu tarafı pre-receive hook’larını veya bir CI kapısını kullanın.
• Her Git sunucu yükseltmesinden sonra sunucu tarafı hook’larını denetleyin; hook yorumlayıcı yolları değişebilir.

Kendi sunucunuzda güvenlik

• git kullanıcısına SSH erişimini zorunlu komutlarla kısıtlayın (command= içinde authorized_keys).
• Rastgele komut çalıştırılmasını önlemek için git-shell kullanıcısının giriş kabuğu olarak git kullanın.
• Herhangi bir web arayüzü (Gitea, GitLab, cgit) açıyorsanız depo sunucunuzu geçerli bir SSL sertifikası ile eşleştirin.

Geçmişi yeniden yazma

• Koordineli bir geçiş planı olmadan başkalarıyla paylaşılan dallarda geçmişi asla yeniden yazmayın.
• git filter-repo sonrasında tüm iş arkadaşları yeniden klonlamalıdır; CI/CD uzak URL’lerini derhal güncelleyin.

Felaket kurtarma

• Üretim sunucularında reflog süre sonunu uzatın (gc.reflogExpire = 180).
• Yedek olarak ayrı bir sunucuda ikincil bir bare klon tutun; birincil sunucudan basit bir git fetch yeterlidir.

SSS

Bare ve bare olmayan Git deposu arasındaki fark nedir?

Bare olmayan bir deponun, dosyaların checkout edildiği bir çalışma dizini ve nesne deposunu içeren bir .git/ alt dizini vardır. Bare depo ise yalnızca kökünde nesne deposunu içerir (çalışma dizini yoktur) ve push alan paylaşımlı bir sunucu için doğru formattır.

git reset --hard çalıştırdıktan sonra commit’leri kurtarabilir miyim?

Evet, commit’ler çöp toplanmadığı sürece. Kurtarmak istediğiniz commit’in SHA’sını bulmak için git reflog çalıştırın, ardından onu yeni bir dala bağlamak için git checkout -b recovery-branch <SHA> kullanın. Reflog girişleri varsayılan olarak 90 gün boyunca saklanır.

git push neden etiketlerimi aktarmıyor?

Tasarım gereği, git push yalnızca açıkça push ettiğiniz ref’lerden erişilebilen commit’leri aktarır. Etiketler ayrı ref’lerdir ve git push origin --tags (tüm etiketler) veya git push origin <tagname> (belirli bir etiket) ile push edilmeleri gerekir.

Birleştirme çakışması sırasında index’e ne olur?

Index, çakışan her dosyanın üç sürümünü aynı anda depolar: aşama 1 (ortak ata/taban), aşama 2 (sizin sürümünüz) ve aşama 3 (onların sürümü). Normal git add yalnızca aşama 0’ı (çözülmüş) yazar. Tüm çakışmalar çözülüp hazırlamaya alınana kadar git commit devam etmeyi reddeder.

Git hook’ları istemci tarafı ve sunucu tarafı dağıtımlar arasında nasıl farklılık gösterir?

İstemci tarafı hook’lar geliştiricinin makinesinde çalışır ve merkezi olarak uygulanmaz — herhangi bir geliştirici hook dosyasını silerek bunları atlayabilir. Sunucu tarafı hook’lar (pre-receive, update, post-receive) barındırma sunucusunda çalışır ve istemci tarafından atlanamaz; bu da onları dal koruma politikaları, kod inceleme gereksinimleri ve CI/CD tetikleyicileri için doğru uygulama noktası yapar.