Git Nedir? Sıfırdan İleri Seviyeye Kapsamlı Rehber [2026]
Yazar: Burak Balkı | Kategori: Database | Okuma Süresi: 33 dk
Bu kapsamlı rehber, Git'in temellerinden ileri seviye tekniklerine kadar her yönünü 2026 güncel bilgileriyle ele alıyor. Adım adım kod örnekleri ve gerçek dü...
Merhaba değerli geliştiriciler!
Günümüzün hızlı tempolu yazılım geliştirme dünyasında, kod tabanını etkili bir şekilde yönetmek ve ekip içinde sorunsuz işbirliği yapmak hayati önem taşır. Peki, projenizin karmaşıklığı arttıkça bu süreci nasıl kontrol altında tutarsınız? İşte tam da bu noktada, yazılım geliştirmenin temel taşı olan **Git** devreye giriyor. 2026 itibarıyla, Git sadece bir araç değil, aynı zamanda modern geliştirme süreçlerinin omurgası haline gelmiş durumda. Bu kapsamlı rehberde, Git'in temellerinden başlayarak ileri seviye tekniklerine kadar her şeyi adım adım öğrenecek, pratik kod örnekleriyle kendi projelerinizde hemen uygulamaya başlayabileceksiniz. Hazır olun, çünkü sürüm kontrol dünyasına yepyeni bir bakış açısı kazanacaksınız!
## Git Nedir?
**Git, Linus Torvalds tarafından 2005 yılında geliştirilen, dağıtık bir sürüm kontrol sistemidir (Distributed Version Control System - DVCS).** Yazılım geliştiricilerin kodlarında yaptıkları değişiklikleri takip etmelerine, farklı sürümleri yönetmelerine, hata ayıklamalarına ve ekip üyeleriyle eş zamanlı olarak işbirliği yapmalarına olanak tanır. Her geliştiricinin projenin tam bir kopyasına sahip olması sayesinde, merkezi bir sunucuya bağımlılık ortadan kalkar ve çevrimdışı çalışma imkanı sunar.
Git, başlangıçta Linux çekirdeği geliştirme sürecinin ihtiyaçlarını karşılamak üzere tasarlanmış olsa da, esnekliği, hızı ve güvenilirliği sayesinde kısa sürede dünyanın en popüler sürüm kontrol sistemi haline gelmiştir. 2026 itibarıyla, küçük açık kaynak projelerinden devasa kurumsal uygulamalara kadar her ölçekteki projede aktif olarak kullanılmaktadır. Geliştiricilerin kod tabanında yapılan değişiklikleri anlık olarak izlemelerine, geçmiş sürümlere kolayca dönmelerine ve farklı özellik dalları (branch) üzerinde bağımsız olarak çalışarak entegrasyon süreçlerini basitleştirmelerine olanak tanır.
## Neden Git Kullanmalısınız? [2026 Güncel Veriler]
Git'in popülaritesi tesadüf değildir. Sunduğu avantajlar, modern yazılım geliştirme pratikleri için vazgeçilmezdir. İşte 2026 itibarıyla Git kullanmanız için başlıca nedenler:
* **Dağıtık Mimari:** Her geliştiricinin projenin tam geçmişine sahip olması, merkezi sunucu arızalarında bile veri kaybı riskini minimize eder. Çevrimdışı çalışabilme yeteneği, özellikle uzaktan çalışma modellerinin yaygınlaştığı 2026 dünyasında büyük bir avantajdır.
* **Hız ve Performans:** Git, büyük kod tabanlarında bile son derece hızlı çalışır. Commit, branch ve merge işlemleri yerel makinenizde gerçekleştiği için performans açısından merkezi sistemlere göre çok daha üstündür.
* **Esnek Branching Modeli:** Git'in branch yapısı, yeni özellikler geliştirmeyi, hata düzeltmeleri yapmayı ve farklı denemeler yapmayı inanılmaz derecede kolaylaştırır. Bu esneklik, CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) süreçlerinin etkin bir şekilde uygulanmasını sağlar.
* **Veri Bütünlüğü ve Güvenlik:** Git, her commit için SHA-1 hash algoritması kullanarak veri bütünlüğünü sağlar. Bu, projenizin geçmişinin değiştirilemez olduğu ve herhangi bir dosyanın veya commit'in tahrif edilmesinin anında tespit edilebileceği anlamına gelir.
* **Aktif ve Geniş Topluluk Desteği:** 2026 itibarıyla Git, dünyanın en büyük ve en aktif geliştirici topluluklarından birine sahiptir. Stack Overflow, GitHub ve çeşitli forumlarda milyonlarca kaynak, örnek ve çözüm bulmak mümkündür. Bu durum, karşılaşabileceğiniz herhangi bir soruna hızlıca çözüm bulabileceğiniz anlamına gelir.
* **Entegrasyon Kolaylığı:** Git, GitHub, GitLab, Bitbucket gibi popüler kod barındırma platformları ve Jenkins, Travis CI gibi CI/CD araçları ile kusursuz bir entegrasyon sunar. Bu, geliştirme iş akışınızı otomatize etmenizi ve verimliliği artırmanızı sağlar.
> **Burak Balkı'dan Not:** Kendi 10+ yıllık tecrübelerime göre, Git'in esnek branching stratejileri (özellikle Gitflow veya GitHub Flow), büyük ekiplerde paralel geliştirmeyi ve ürün döngülerini inanılmaz derecede hızlandırıyor. Projeleriniz büyüdükçe, Git'in sağladığı bu yapısal avantajların değeri katlanarak artacaktır.
## Git vs Alternatifler: 2026 Karşılaştırması
Git, piyasadaki tek sürüm kontrol sistemi olmasa da, sunduğu avantajlarla rakiplerini geride bırakmıştır. İşte 2026 itibarıyla Git'i popüler alternatiflerle karşılaştıran bir tablo:
| Özellik | Git | Subversion (SVN) | Mercurial |
| :----------------- | :------------------------------------------ | :------------------------------------------ | :--------------------------------------- |
| **Mimari** | Dağıtık (DVCS) | Merkezi (CVCS) | Dağıtık (DVCS) |
| **Performans** | Yerel işlemlerle çok hızlı | Sunucuya bağımlı, daha yavaş | Git'e yakın, iyi performans |
| **Öğrenme Eğrisi** | Başlangıçta biraz daha dik, ileri seviye güçlü | Daha basit, merkezi modelden gelenler için kolay | Git'e benzer, biraz daha basit |
| **Branching** | Hafif, hızlı, esnek | Daha ağır, maliyetli | Hafif, Git'e benzer |
| **Ekosistem** | GitHub, GitLab, Bitbucket lideri | Apache, TortoiseSVN | Bitbucket (eski), RhodeCode |
| **Topluluk** | Çok geniş ve aktif (2026'nın en büyüğü) | Orta düzeyde, düşüşte | Orta düzeyde, niş |
| **Kurumsal Destek**| Yaygın ve güçlü | Orta düzeyde, legacy sistemlerde | Orta düzeyde |
| **Kullanım Alanı** | Her ölçekteki proje, açık kaynak | Eski, merkeziyetçi projeler | Bazı özel projeler, büyük dosyalar için tercih edilebilir |
2026 verilerine göre, Git'in dağıtık yapısı ve esnek branching modeli, modern DevOps ve Agile pratikleriyle daha uyumlu olduğu için SVN gibi merkezi sistemlere göre çok daha fazla tercih edilmektedir. Mercurial ise Git'e güçlü bir alternatif olsa da, Git'in ekosistem büyüklüğü ve topluluk desteği karşısında daha niş bir konumdadır.
## Kurulum ve İlk Adımlar: Git 2.47.0 (2026)
Git'i kullanmaya başlamadan önce sisteminize kurmanız gerekir. 2026 itibarıyla en güncel stabil sürüm olan **Git 2.47.0** üzerinden kurulum adımlarını inceleyelim.
### Ön Gereksinimler
Git'i kurmak için özel bir ön gereksinim olmamakla birlikte, bir terminal veya komut istemcisi kullanma bilgisi faydalıdır.
### Adım 1: Git'i İndirme
İşletim sisteminize uygun Git paketini `git-scm.com` adresindeki resmi indirme sayfasından edinebilirsiniz.
* **Windows:** Git for Windows yükleyicisini indirin ve varsayılan seçeneklerle kurulumu tamamlayın.
* **macOS:** Homebrew kullanıyorsanız terminalde `brew install git` komutunu çalıştırın. Alternatif olarak, Xcode Command Line Tools ile birlikte gelir (`xcode-select --install`).
* **Linux (Debian/Ubuntu):** `sudo apt update && sudo apt install git`
* **Linux (Fedora):** `sudo dnf install git`
### Adım 2: Kurulumu Doğrulama
Kurulumun başarılı olup olmadığını kontrol etmek için terminalde aşağıdaki komutu çalıştırın:
```bash
git --version
```
Çıktı olarak `git version 2.47.0` (veya kurduğunuz güncel sürüm) benzeri bir ifade görmelisiniz.
### Adım 3: Git Ayarlarını Yapılandırma
Git'i kullanmaya başlamadan önce, commit'lerinizde görülecek adınızı ve e-posta adresinizi ayarlamanız önemlidir. Bu bilgiler, kimin hangi değişikliği yaptığını belirlemek için kullanılır.
```bash
git config --global user.name "Burak Balkı"
git config --global user.email "burak.balki@example.com"
```
Bu ayarları kontrol etmek için:
```bash
git config --list
```
> **Pro Tip:** `--global` bayrağı, bu ayarların tüm Git depolarınız için geçerli olmasını sağlar. Sadece belirli bir depo için farklı bir isim/e-posta kullanmak isterseniz, `--global` bayrağını kullanmadan depo dizini içinde bu komutları çalıştırabilirsiniz.
## Temel Kullanım ve Örnekler: Git Komutları
Artık Git yüklü ve yapılandırılmış. Şimdi temel Git iş akışını ve en sık kullanılan komutları pratik örneklerle inceleyelim.
### Örnek 1: Yeni Bir Depo Oluşturma ve İlk Commit
**Problem:** Yeni bir proje başlatmak ve kodları sürüm kontrolüne almak.
**Çözüm:** `git init` ile yerel bir Git deposu oluşturun, dosyaları ekleyin ve `git commit` ile ilk değişikliği kaydedin.
```bash
# Yeni bir proje dizini oluşturun ve içine girin
mkdir benim-ilk-git-projem-2026
cd benim-ilk-git-projem-2026
# Git deposunu başlatın
git init
# Bir dosya oluşturun
echo "# Benim İlk Git Projem 2026" > README.md
echo "console.log('Hello Git!');" > app.js
# Dosyaları staging alanına ekleyin
git add README.md app.js
# veya tüm değişiklikleri eklemek için:
git add .
# Değişiklikleri kaydedin (commit edin)
git commit -m "İlk commit: Proje başlangıcı ve README eklendi"
```
### Örnek 2: Değişiklikleri İzleme ve Commit Etme
**Problem:** Mevcut bir projedeki dosyalarda yapılan değişiklikleri kaydetmek.
**Çözüm:** Dosyaları değiştirin, `git status` ile değişiklikleri görün, `git add` ile staging'e alın ve `git commit` ile kaydedin.
```bash
# app.js dosyasını değiştirin
# (Bir metin editörü ile açıp içeriği güncelleyin)
# Örneğin: console.log('Hello Git!'); -> console.log('Hello Git 2026!');
# Değişiklikleri görüntüleyin
git status
# Değişiklikleri staging alanına ekleyin
git add app.js
# Değişiklikleri commit edin
git commit -m "app.js güncellendi: 2026 mesajı eklendi"
```
### Örnek 3: Commit Geçmişini Görüntüleme
**Problem:** Projenin geçmişinde yapılan tüm değişiklikleri ve commit mesajlarını görmek.
**Çözüm:** `git log` komutunu kullanın.
```bash
git log
```
> **Çıktı Örneği:**
```
commit f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0 (HEAD -> master)
Author: Burak Balkı
Date: Wed Jun 4 10:30:00 2026 +0300
app.js güncellendi: 2026 mesajı eklendi
commit a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9
Author: Burak Balkı
Date: Wed Jun 4 10:25:00 2026 +0300
İlk commit: Proje başlangıcı ve README eklendi
```
### Örnek 4: Branch Oluşturma ve Değiştirme
**Problem:** Yeni bir özellik üzerinde çalışırken ana kod tabanını etkilememek.
**Çözüm:** `git branch` ile yeni bir dal oluşturun ve `git checkout` ile o dala geçin.
```bash
# Yeni bir özellik dalı oluşturun
git branch feature/yeni-ozellik-2026
# Oluşturulan dalları görüntüleyin
git branch
# Yeni dala geçin
git checkout feature/yeni-ozellik-2026
# Şimdi bu dalda değişiklikler yapabiliriz
echo "Yeni özellik kodu." > new_feature.js
git add new_feature.js
git commit -m "Yeni özellik eklendi"
```
### Örnek 5: Branch'leri Birleştirme (Merge)
**Problem:** Geliştirilen özelliği ana kod tabanına entegre etmek.
**Çözüm:** Ana dala geri dönün ve `git merge` ile özellik dalını birleştirin.
```bash
# Ana dala (master/main) geri dönün
git checkout master
# Özellik dalını ana dala birleştirin
git merge feature/yeni-ozellik-2026
# Birleştirilen özellik dalını silin (isteğe bağlı)
git branch -d feature/yeni-ozellik-2026
```
## İleri Seviye Teknikler: Git ile Daha Fazlası [2026]
Git'in temel komutlarını öğrendikten sonra, daha karmaşık senaryolar için ileri seviye tekniklere geçebiliriz. Bu teknikler, iş akışınızı optimize etmenize ve daha temiz bir commit geçmişi oluşturmanıza yardımcı olacaktır.
### 1. Git Rebase: Temiz Bir Geçmiş İçin Yeniden Temellendirme
`git rebase`, commit geçmişinizi yeniden yazmanıza olanak tanır. Genellikle, bir özellik dalını ana daldaki en son değişikliklerle güncel tutmak ve merge commit'lerinden kaçınarak daha doğrusal bir geçmiş oluşturmak için kullanılır.
**Senaryo:** `feature/login` dalında çalışırken `master` dalına yeni commit'ler eklendi. `feature/login` dalını `master` ile güncelleyip daha temiz bir merge yapmak istiyorsunuz.
```bash
# feature/login dalına geçin
git checkout feature/login
# master dalındaki değişiklikleri kendi dalınıza rebase edin
git rebase master
# Rebase sonrası master'a geçip hızlı ileri merge yapabilirsiniz
git checkout master
git merge feature/login # Fast-forward merge olacaktır
```
> **Uyarı:** `git rebase` komutunu, başkalarıyla paylaştığınız (public) dallarda kullanmaktan kaçının. Bu, ortak commit geçmişini değiştirerek çatışmalara yol açabilir. Kendi yerel dallarınızda veya henüz paylaşılmamış dallarda güvenle kullanabilirsiniz.
### 2. Git Stash: Geçici Değişiklikleri Saklama
Bazen bir özellik üzerinde çalışırken acil bir hata düzeltmesi yapmanız gerekebilir, ancak mevcut değişikliklerinizi commit etmek istemezsiniz. `git stash` tam da bu durumlar için idealdir.
```bash
# Değişiklikleriniz var ama commit etmek istemiyorsunuz
# Örneğin: app.js'de değişiklik yaptınız
# Değişiklikleri geçici olarak saklayın
git stash save "Acil hata düzeltmesi için değişiklikleri sakla"
# Şimdi master'a geçip hata düzeltmesini yapabilirsiniz
git checkout master
# Hata düzeltmesi commit edildi...
# Tekrar eski dalınıza geçin
git checkout feature/yeni-ozellik-2026
# Sakladığınız değişiklikleri geri getirin
git stash pop
```
### 3. Git Cherry-Pick: Belirli Commit'leri Taşıma
`git cherry-pick`, başka bir daldaki belirli bir commit'i mevcut dalınıza uygulamak için kullanılır. Bu, tüm dalı birleştirmek yerine sadece belirli bir düzeltmeyi veya özelliği taşımak istediğinizde faydalıdır.
**Senaryo:** `hotfix` dalındaki bir hata düzeltmesini `develop` dalına uygulamak istiyorsunuz.
```bash
# hotfix dalındaki commit ID'sini bulun
git log --oneline hotfix
# Örn: d1e2f3a "Hata düzeltmesi: Kullanıcı girişi"
# develop dalına geçin
git checkout develop
# Belirli commit'i buraya uygulayın
git cherry-pick d1e2f3a
```
### 4. Git Submodule ve Git Worktree: Çoklu Depo Yönetimi
Büyük projelerde veya bağımlılıkları yönetirken `git submodule` veya `git worktree` kullanmak gerekebilir.
* **Git Submodule:** Bir Git deposunu başka bir Git deposunun alt dizini olarak eklemenizi sağlar. Genellikle harici kütüphaneleri veya bağımlılıkları yönetmek için kullanılır. 2026 itibarıyla, monorepo yaklaşımları yaygınlaşsa da, submodule'lar hala belirli senaryolarda (örneğin, ortak bir kütüphaneyi birçok bağımsız projede kullanmak) tercih edilebilir.
```bash
# Bir alt modül ekleyin
git submodule add https://github.com/example/my-library.git lib/my-library
git commit -m "my-library alt modülü eklendi"
# Alt modülleri klonladıktan sonra başlatmak
git submodule update --init --recursive
```
* **Git Worktree:** Aynı depo için birden fazla çalışma dizini oluşturmanıza olanak tanır. Bu, aynı anda farklı dallarda çalışmanız gerektiğinde (örneğin, bir dalda hata ayıklarken diğerinde yeni özellik geliştirmek) çok kullanışlıdır.
```bash
# Yeni bir çalışma ağacı oluşturun (örneğin, hotfix dalı için)
git worktree add ../hotfix-worktree hotfix
# Mevcut çalışma ağaçlarını listeleyin
git worktree list
```
## Best Practices & Anti-Patterns: 2026 Geliştirme Yaklaşımları
10 yılı aşkın tecrübemle, production ortamında Git kullanırken edindiğim en kritik dersleri ve ekip verimliliğini artıran yaklaşımları sizinle paylaşmak istiyorum. Doğru Git kullanımı, sadece kodunuzu güvende tutmakla kalmaz, aynı zamanda ekip içi işbirliğini de zirveye taşır.
* **✅ Küçük ve Anlamlı Commit'ler Yapın:** Her commit tek bir mantıksal değişikliği içermelidir. Bu, kod incelemelerini kolaylaştırır, hata ayıklama sürecini hızlandırır ve geri alma işlemlerini basitleştirir. `git blame` veya `git bisect` gibi araçları kullanırken hayat kurtarır.
* **❌ Büyük ve Karmaşık Commit'lerden Kaçının:** Birkaç farklı özelliği veya düzeltmeyi tek bir commit'e sıkıştırmak, hem anlaşılırlığı azaltır hem de gelecekteki olası sorunları çözmeyi zorlaştırır.
* **✅ Açıklayıcı Commit Mesajları Yazın:** Commit mesajlarınız, değişikliğin nedenini, neyi değiştirdiğini ve nasıl değiştirdiğini kısaca açıklamalıdır. İlk satır (konu) 50 karakteri geçmemeli ve ardından boş bir satır bırakılarak detaylı açıklama yapılmalıdır.
```
feat: Kullanıcı kayıt akışı eklendi
Yeni kullanıcıların sisteme kaydolmasını sağlayan bir API endpoint'i ve
ilgili veritabanı şema değişiklikleri eklendi. Şifreler bcrypt ile hashleniyor.
```
* **❌ "Fix", "Update", "Changes" gibi Genel Mesajlar Kullanmayın:** Bu tür mesajlar, gelecekte commit geçmişini incelerken size hiçbir bilgi vermez.
* **✅ Branching Stratejisi Belirleyin:** Gitflow, GitHub Flow veya GitLab Flow gibi standart bir branching stratejisi benimseyin. Bu, ekip üyelerinin hangi dalda çalışması gerektiğini ve değişikliklerin nasıl birleştirileceğini netleştirir. 2026 itibarıyla GitHub Flow, özellikle sürekli teslimat (CD) odaklı ekiplerde oldukça popülerdir.
* **❌ Master/Main Dalına Doğrudan Commit Yapmayın:** `master` veya `main` dalı her zaman kararlı ve deploy edilebilir durumda olmalıdır. Tüm geliştirmeler özellik dallarında yapılmalı ve kod incelemesinden (Pull Request/Merge Request) sonra birleştirilmelidir.
* **✅ .gitignore Dosyasını Doğru Kullanın:** `node_modules/`, `.env`, `dist/`, `*.log` gibi gereksiz veya hassas dosyaların Git deposuna eklenmesini önlemek için `.gitignore` dosyasını etkili bir şekilde yapılandırın. Bu, deponuzun boyutunu küçültür ve güvenlik risklerini azaltır.
* **❌ Hassas Verileri (API Anahtarları, Şifreler) Git'e Commit Etmeyin:** Bu, en büyük güvenlik anti-pattern'larından biridir. Hassas veriler `.env` dosyaları, ortam değişkenleri veya güvenli sır yönetim sistemleri (örn. HashiCorp Vault, AWS Secrets Manager) aracılığıyla yönetilmelidir. Yanlışlıkla commit ederseniz, `git filter-repo` gibi araçlarla geçmişten temizlemeniz gerekir.
* **✅ Sık Sık Pull/Fetch Yapın:** Ekip üyelerinin yaptığı değişiklikleri düzenli olarak yerel deponuza çekin. Bu, merge çatışmalarını en aza indirmeye yardımcı olur ve değişiklikler arasındaki entegrasyonu kolaylaştırır.
* **❌ Uzun Süre Güncelleme Yapmadan Çalışmayın:** Uzun ömürlü dallarda uzun süre izole çalışmak, merge çatışmalarının büyümesine ve entegrasyon sürecinin bir kabusa dönüşmesine neden olabilir.
* **✅ Kod İncelemeleri (Code Reviews) Yapın:** Git'in Pull Request/Merge Request mekanizmalarını kullanarak kod incelemelerini zorunlu hale getirin. Bu, kod kalitesini artırır, hataları erkenden yakalar ve bilgi paylaşımını teşvik eder.
* **❌ Kod İncelemelerini Atlamayın veya Yüzeysel Yapmayın:** Kod incelemeleri, sadece bir formalite değil, kod tabanının sağlığı için kritik bir adımdır.
## Yaygın Hatalar ve Çözümleri [2026]
Git kullanırken karşılaşabileceğiniz bazı yaygın sorunlar ve bunların çözümleri:
### 1. Problem: Merge Çatışmaları (Merge Conflicts)
**Sebep:** İki farklı dalda aynı dosyanın aynı satırlarında farklı değişiklikler yapıldığında Git otomatik olarak birleştirme yapamaz.
**Çözüm:** Git, çatışan bölgeleri özel işaretleyicilerle (örn. `<<<<<<<`, `=======`, `>>>>>>>`) gösterir. Bu bölgeleri manuel olarak düzenleyerek doğru sürümü seçmeli veya her iki değişikliği de birleştirmelisiniz. Düzenleme bittikten sonra dosyayı `git add` ile staging'e alıp `git commit` ile birleştirmeyi tamamlayın.
```bash
# Çatışmayı çözdükten sonra
git add <çözülen_dosya>
git commit -m "Merge conflict çözüldü"
```
### 2. Problem: Yanlışlıkla Commit Edilen Hassas Veriler
**Sebep:** `.env` dosyaları, API anahtarları veya şifreler gibi hassas bilgilerin `.gitignore` dosyasına eklenmeden yanlışlıkla depoya commit edilmesi.
**Çözüm:** Bu çok kritik bir güvenlik açığıdır. Geçmişteki commit'lerden bu verileri temizlemek için `git filter-repo` (veya daha eski `git filter-branch`) kullanmalısınız. Ancak bu işlem, geçmişi yeniden yazdığı için dikkatli yapılmalı ve diğer ekip üyeleriyle koordinasyon gerektirir.
```bash
# İlk olarak git-filter-repo aracını kurun
# pip install git-filter-repo
# Hassas dosyayı geçmişten tamamen silin (ÇOK DİKKATLİ KULLANIN!)
git filter-repo --path sensitive_file.env --invert-paths --force
```
> **Önemli:** Bu komut, depoyu yeniden yazar ve diğer ekip üyelerinin depoyu yeniden klonlamasını gerektirebilir. Acil durumlarda kullanın ve hemen ilgili sırları değiştirin.
### 3. Problem: "Detached HEAD" Durumu
**Sebep:** `git checkout ` gibi bir komutla belirli bir commit'e geçildiğinde veya bir rebase işlemi sırasında HEAD'in bir dala değil, doğrudan bir commit'e işaret etmesi. Bu durumda yapılan değişiklikler kaybolabilir.
**Çözüm:** Eğer bu durumda değişiklikler yaptıysanız ve bunları kaybetmek istemiyorsanız, yeni bir dal oluşturmalısınız:
```bash
# Detached HEAD durumundayken değişiklikler yaptıysanız
git branch yeni-dal-adi
git checkout yeni-dal-adi
# Eğer sadece bir commit'i incelemek için geçtiyseniz ve geri dönmek istiyorsanız
git checkout master # veya ana dalınızın adı
```
### 4. Problem: Uzak Depo ile Senkronizasyon Sorunları
**Sebep:** Yerel deponuzdaki değişikliklerin uzak depodaki değişikliklerle çakışması veya uzak depoyu güncelleyememeniz.
**Çözüm:** `git pull` yapmadan önce yerel değişikliklerinizi commit edin veya stash'leyin. Eğer `git push` yaparken `non-fast-forward` hatası alıyorsanız, bu uzak depoda sizin yerelde olmayan değişiklikler olduğu anlamına gelir. Önce `git pull` yaparak uzak değişiklikleri çekmeli, çatışmaları çözmeli ve sonra tekrar `git push` yapmalısınız.
```bash
# Uzak değişiklikleri çek ve birleştir (varsa çatışmaları çöz)
git pull origin master
# Çatışmaları çözdükten sonra
git push origin master
```
## Performans Optimizasyonu: Büyük Git Depolarını Yönetme [2026]
Büyük kod tabanları ve uzun commit geçmişleri olan Git depolarında performans sorunları yaşanabilir. 2026 itibarıyla, özellikle monorepo yaklaşımlarının yaygınlaşmasıyla bu optimizasyonlar daha da önem kazanmıştır. İşte Git performansını artırmak için bazı teknikler:
### 1. Git Garbage Collection (`git gc`)
Git, zamanla gereksiz nesneleri (örneğin, silinmiş dallardan kalan objeler) biriktirebilir. `git gc` (garbage collect) komutu, depoyu sıkıştırır ve temizler, bu da disk alanından tasarruf sağlar ve bazı Git işlemlerinin hızını artırabilir.
```bash
git gc
```
> **Tecrübe:** Kendi production ortamımdaki büyük monorepolarda, düzenli `git gc` çalıştırmak (özellikle CI/CD süreçlerinde veya belirli aralıklarla) diske yazma ve okuma sürelerinde gözle görülür iyileşmeler sağlamıştır.
### 2. Shallow Clone (`--depth`)
Eğer projenin tüm commit geçmişine ihtiyacınız yoksa (örneğin, CI/CD ortamlarında veya sadece en son sürümü incelemek için), `git clone --depth` ile sığ bir klonlama yapabilirsiniz. Bu, indirme süresini ve depo boyutunu önemli ölçüde azaltır.
```bash
git clone --depth 1 https://github.com/example/buyuk-proje.git
```
Bu komut, sadece en son commit'i ve onunla ilişkili dosyaları indirir.
### 3. Git LFS (Large File Storage)
Büyük ikili dosyalar (resimler, videolar, derlenmiş çıktılar) Git'in performansını düşürebilir ve depo boyutunu artırabilir. Git LFS, bu tür dosyaları Git deposu dışında depolamanıza ve depoda sadece küçük işaretçiler tutmanıza olanak tanır.
```bash
# Git LFS'yi başlatın (bir kez)
git lfs install
# İzlemek istediğiniz dosya tiplerini belirtin
git lfs track "*.psd"
git lfs track "*.zip"
# .gitattributes dosyasını commit edin
git add .gitattributes
git commit -m "LFS izleme ayarları eklendi"
# Büyük dosyaları normal şekilde ekleyip commit edin
git add buyuk-resim.psd
git commit -m "Büyük resim eklendi (LFS ile yönetiliyor)"
```
### 4. Sparse Checkout
Çok büyük bir monorepo ile çalışıyorsanız ancak sadece belirli alt dizinlerdeki dosyalara ihtiyacınız varsa, `git sparse-checkout` kullanarak sadece ihtiyacınız olan kısımları klonlayabilirsiniz. Bu özellik, 2026 itibarıyla büyük ölçekli kurumsal projelerde oldukça yaygınlaşmıştır.
```bash
# Depoyu klonlayın (ancak dosyaları çekmeyin)
git clone --no-checkout https://github.com/example/monorepo.git
cd monorepo
# Sparse checkout'u etkinleştirin
git sparse-checkout init --cone
# Sadece belirli bir dizini çekmek istediğinizi belirtin
git sparse-checkout set services/auth
# Dosyaları çekin
git checkout master
```
## Gerçek Dünya Proje Örneği: Git ile Veritabanı Şema Yönetimi [2026]
Bu bölümde, Git'in sadece kod değil, aynı zamanda veritabanı şema değişikliklerini nasıl yönettiğini gösteren küçük bir proje örneği oluşturacağız. Bu, özellikle "Database" kategorisiyle ilgili talebi karşılamak adına önemli bir senaryodur. Projemiz, basit bir Node.js uygulaması ve `knex.js` ile yönetilen bir SQLite veritabanı içerecek.
### Proje Yapısı
```
my-db-app-2026/
├── .git/
├── migrations/
│ ├── 20260604100000_create_users_table.js
│ └── 20260604101500_add_email_to_users.js
├── src/
│ └── app.js
├── knexfile.js
├── package.json
└── README.md
```
### Adım 1: Projeyi Başlatma ve Git İnit
```bash
mkdir my-db-app-2026
cd my-db-app-2026
git init
npm init -y
npm install knex sqlite3
# knexfile.js oluştur
npx knex init
```
**`knexfile.js` içeriği:**
```javascript
// knexfile.js
module.exports = {
development: {
client: 'sqlite3',
connection: {
filename: './dev.sqlite3'
},
useNullAsDefault: true,
migrations: {
directory: './migrations'
}
}
};
```
`README.md` oluşturup ilk commit'i yapın:
```bash
echo "# My DB App 2026" > README.md
git add .
git commit -m "Proje başlangıcı: Knex ve SQLite ayarları, README"
```
### Adım 2: İlk Veritabanı Şema Migrasyonu ve Commit
Kullanıcılar tablosu oluşturmak için bir migrasyon dosyası yaratın:
```bash
npx knex migrate:make create_users_table
```
`migrations/20260604100000_create_users_table.js` içeriği (timestamp farklı olabilir):
```javascript
// migrations/20260604100000_create_users_table.js
exports.up = function(knex) {
return knex.schema.createTable('users', function(table) {
table.increments('id');
table.string('username').notNullable().unique();
table.string('password_hash').notNullable();
table.timestamps(true, true);
});
};
exports.down = function(knex) {
return knex.schema.dropTable('users');
};
```
Migrasyonu uygulayın ve commit edin:
```bash
npx knex migrate:latest
git add .
git commit -m "feat: users tablosu oluşturuldu"
```
### Adım 3: Şema Değişikliği ve Yeni Bir Branch
Kullanıcı tablosuna email alanı eklemek için yeni bir branch oluşturun:
```bash
git checkout -b feature/add-user-email
npx knex migrate:make add_email_to_users
```
`migrations/20260604101500_add_email_to_users.js` içeriği:
```javascript
// migrations/20260604101500_add_email_to_users.js
exports.up = function(knex) {
return knex.schema.table('users', function(table) {
table.string('email').unique().nullable();
});
};
exports.down = function(knex) {
return knex.schema.table('users', function(table) {
table.dropColumn('email');
});
};
```
Migrasyonu uygulayın ve commit edin:
```bash
npx knex migrate:latest
git add .
git commit -m "feat: users tablosuna email alanı eklendi"
```
### Adım 4: Master'a Birleştirme ve Deploy
Değişiklikleri `master`'a birleştirin:
```bash
git checkout master
git merge feature/add-user-email
git branch -d feature/add-user-email
```
Şimdi `master` dalı, hem kullanıcı tablosunu hem de email alanını içeren son şemayı barındırıyor. Bu sayede, Git commit geçmişi üzerinden veritabanı şema değişikliklerini de kod değişiklikleri gibi takip edebilir, geri alabilir veya farklı ortamlara deploy edebilirsiniz. Bu yaklaşım, özellikle 2026'daki mikroservis ve DevOps odaklı mimarilerde, veritabanı değişikliklerinin güvenli ve izlenebilir bir şekilde yönetilmesi için kritik öneme sahiptir.
## Önemli Noktalar (Key Takeaways) [2026]
Git öğrenme yolculuğunuzda aklınızda tutmanız gereken kritik noktalar:
* **Git, dağıtık bir sürüm kontrol sistemidir (DVCS)** ve her geliştiricinin projenin tam geçmişine sahip olmasını sağlar.
* **Küçük, odaklı ve anlamlı commit'ler** yaparak kod incelemelerini ve hata ayıklamayı kolaylaştırın.
* **Açıklayıcı commit mesajları** yazmak, projenizin geçmişini okumayı ve anlamayı hızlandırır.
* **Branching stratejileri (Gitflow, GitHub Flow)**, ekip içinde paralel geliştirmeyi ve entegrasyonu düzenler.
* **`git rebase` ile temiz bir commit geçmişi** oluşturabilir, ancak paylaşılmış dallarda dikkatli kullanmalısınız.
* **`git stash`**, üzerinde çalıştığınız değişiklikleri geçici olarak saklamak için harika bir araçtır.
* **`.gitignore` dosyasını etkili kullanmak**, gereksiz ve hassas dosyaların depoya girmesini engeller.
* **Hassas verileri (şifreler, anahtarlar) asla Git deposuna commit etmeyin**; ortam değişkenleri veya sır yönetim sistemleri kullanın.
* **Düzenli `git pull` yapmak**, merge çatışmalarını azaltır ve ekiple senkronize kalmanızı sağlar.
* **Kod incelemeleri (Pull Request/Merge Request)**, kod kalitesini ve ekip içi bilgi paylaşımını artırır.
* **`git gc` ve Git LFS gibi araçlar**, büyük Git depolarının performansını optimize etmek için kritik öneme sahiptir.
## Sık Sorulan Sorular (FAQ) [2026]
### Git nedir ve ne işe yarar?
Git, Linus Torvalds tarafından geliştirilen dağıtık bir sürüm kontrol sistemidir (DVCS). Yazılımcıların kodlarında yaptıkları değişiklikleri takip etmelerine, farklı sürümleri yönetmelerine ve ekip üyeleriyle eş zamanlı olarak işbirliği yapmalarına yarar.
### Git ile GitHub arasındaki fark nedir?
Git, yerel makinenizde çalışan bir sürüm kontrol sistemidir. GitHub ise Git depolarını barındıran, web tabanlı bir platformdur; kod paylaşımı, işbirliği ve proje yönetimi araçları sunar.
### Git nasıl kurulur ve ilk adımlar nelerdir?
Git, `git-scm.com` adresinden indirilebilir. Kurulum sonrası `git config --global user.name` ve `user.email` komutlarıyla kimlik bilgilerinizi yapılandırarak kullanmaya başlayabilirsiniz. Temel adımlar `git init`, `git add` ve `git commit` içerir.
### Git öğrenmek ne kadar sürer?
Git'in temel komutlarını öğrenmek birkaç saat sürebilirken, ileri seviye tekniklerde ustalaşmak ve karmaşık senaryoları yönetmek pratikle birlikte haftalar veya aylar alabilir. Düzenli kul