Git Mülakat Hazırlığı

Giriş — Git Bilgin Kariyerini Şekillendirir

Bir yazılım mülakatındasın. Teknik sorular soruluyor. Algoritmalar, veri yapıları, framework bilgisi — bunlar beklenen şeyler. Ama sonra mülakatçı soruyor: "Yanlışlıkla production branch'ine push ettiniz, ne yaparsınız?" veya "Rebase ile merge arasındaki fark nedir, ne zaman hangisini tercih edersiniz?"

Bu sorular sadece Git komutlarını bilip bilmediğini değil, nasıl düşündüğünü ve gerçek sorunları nasıl çözdüğünü ölçer. Git sorularında doğru cevap vermek teknik yetkinliğini gösterir; yanlış cevap vermek veya "bilmiyorum" demek ise değerlendirmeyi olumsuz etkileyebilir — çünkü Git, her yazılımcının temel aracıdır.

Bu derste mülakatlarda en sık sorulan Git sorularını kategorize edecek, her birine derinlemesine cevaplar vereceğiz. Ayrıca pratik senaryo sorularını ve troubleshooting becerilerini ele alacağız.

Kategori 1: Temel Kavram Soruları

Soru 1: "Git ile GitHub arasındaki fark nedir?"

Beklenen cevap düzeyi: Junior

Git:
  → Dağıtık versiyon kontrol YAZILIMI
  → Bilgisayarında yerel çalışır
  → Linus Torvalds tarafından 2005'te yaratıldı
  → Açık kaynak, ücretsiz
  → Komut satırı aracı (git init, git commit, ...)

GitHub:
  → Git repository'lerini barındıran WEB SERVİSİ
  → Microsoft'a ait (2018'de satın alındı)
  → Git'in üzerine ekstra özellikler ekler:
    - Pull Request (code review)
    - Issues (bug tracking)
    - Actions (CI/CD)
    - Projects (proje yönetimi)
  → Alternatifler: GitLab, Bitbucket, Gitea

Analoji:
  Git = Motor
  GitHub = Otopark + Showroom + Sosyal Klüp
  
  Motor olmadan otopark anlamsız,
  ama motor olmadan da araba kullanılabilir (yerel Git).

Soru 2: "Working directory, staging area ve repository arasındaki fark nedir?"

Beklenen cevap düzeyi: Junior

Üç Durum (Three States):

Working Directory (Çalışma Dizini):
  → Dosyalarını düzenlediğin yer
  → git status ile değişiklikleri gör
  → "Mutfak tezgahı" — malzemeler üzerinde çalışıyorsun

Staging Area (Hazırlık Alanı / Index):
  → git add ile dosyaları buraya taşırsın
  → "Tepsi" — commit'e dahil edilecek değişiklikleri seçiyorsun
  → Seçici commit yapmanı sağlar (tüm değişiklikleri değil, sadece istediğini)

Repository (.git dizini):
  → git commit ile kalıcı kayıt yaparsın
  → "Arşiv" — fotoğraf çekildi, albüme kondu, geri dönülebilir

  ┌──────────────┐  git add   ┌──────────────┐  git commit  ┌──────────┐
  │   Working    │───────────►│   Staging    │─────────────►│  Repo    │
  │  Directory   │            │    Area      │              │  (.git)  │
  └──────────────┘            └──────────────┘              └──────────┘

Soru 3: "git fetch ile git pull arasındaki fark nedir?"

Beklenen cevap düzeyi: Junior-Mid

git fetch:
  → Remote'taki değişiklikleri indirir
  → AMA working directory'yi DEĞİŞTİRMEZ
  → Sadece remote tracking branch'leri günceller
  → Güvenli — hiçbir şeyi bozmaz
  → "Mektubu posta kutusundan al, ama okuma"

git pull:
  → git fetch + git merge (varsayılan)
  → Remote'taki değişiklikleri indirir VE mevcut branch ile birleştirir
  → Working directory değişir
  → Conflict çıkabilir
  → "Mektubu al ve hemen oku"

git pull --rebase:
  → git fetch + git rebase
  → Merge commit oluşturmaz, lineer tarihçe korur

# Güvenli yol (ileri seviye):
$ git fetch origin
$ git log HEAD..origin/main  # Farkı gör
$ git merge origin/main       # Kabul edersen birleştir

# Hızlı yol:
$ git pull origin main        # Hepsini tek seferde

Soru 4: "git reset ile git revert arasındaki fark nedir?"

Beklenen cevap düzeyi: Mid

git reset:
  → Commit'leri GERİ ALIR (tarihçeden siler)
  → Paylaşılmamış (push edilmemiş) commit'ler için güvenli
  → 3 modu var:
    --soft  → Commit geri alınır, değişiklikler staging'de kalır
    --mixed → Commit geri alınır, değişiklikler working directory'de (varsayılan)
    --hard  → Commit geri alınır, değişiklikler SİLİNİR (tehlikeli!)
  → Tarihçeyi değiştirir — paylaşılmış branch'te KULLANMA

git revert:
  → Commit'in TERSINI yapan yeni bir commit oluşturur
  → Orijinal commit tarihçede kalır
  → Paylaşılmış branch'te güvenli
  → "Bu commit'i geri aldım" kaydı tarihçede görünür

Hangisini kullanmalı?
  → Push ETMEDİĞİN commit → git reset
  → Push ETTİĞİN commit → git revert

# reset örneği:
$ git reset --soft HEAD~1    # Son commit'i geri al, değişiklikler staging'de
$ git reset --hard HEAD~1    # Son commit'i tamamen sil (DİKKAT!)

# revert örneği:
$ git revert abc1234         # abc1234'ün tersini yapan yeni commit oluştur

Kategori 2: Branch ve Merge Soruları

Soru 5: "Merge ile rebase arasındaki fark nedir? Ne zaman hangisini kullanırsınız?"

Beklenen cevap düzeyi: Mid-Senior

Merge:
  → İki branch'i birleştiren yeni bir "merge commit" oluşturur
  → Tarihçe dallı görünür ama tam olarak korunur
  → Güvenli — paylaşılmış branch'lerde sorunsuz

Rebase:
  → Commit'leri başka bir noktanın üzerine "yeniden uygular"
  → Lineer, temiz tarihçe oluşturur
  → Commit hash'lerini DEĞİŞTİRİR — paylaşılmış branch'te TEHLİKELİ

Merge sonrası:
  A───B───C───────M
           \     /
            D───E

Rebase sonrası:
  A───B───C───D'───E'  (lineer!)

Ne zaman hangisi?
  → Feature branch'i güncellemek → rebase (temiz tarihçe)
  → Paylaşılmış branch → merge (güvenli)
  → PR merge → squash merge (tek commit)

💡 Mülakat ipucu: "Altın Kural"dan bahset: "Paylaşılmış commit'leri asla rebase etme." Bu, deneyim göstergesidir.

Soru 6: "Merge conflict nedir? Nasıl çözersiniz?"

Beklenen cevap düzeyi: Mid

Conflict ne zaman olur?
  → İki branch AYNI dosyanın AYNI satırlarını farklı şekilde değiştirdiğinde
  → Git hangisinin doğru olduğuna karar veremez
  → İnsan müdahalesi gerekir

Conflict marker'ları:
  <<<<<<< HEAD
  Senin değişikliğin
  =======
  Diğer branch'in değişikliği
  >>>>>>> feature/login

Çözüm adımları:
  1. Conflict'li dosyayı aç
  2. Marker'ları (<<<, ===, >>>) temizle
  3. Doğru kodu seç (veya her ikisini birleştir)
  4. git add <dosya>
  5. git commit (veya git rebase --continue)

# Pratik çözüm:
$ git merge feature/login
# CONFLICT in src/auth.js

$ code src/auth.js          # VS Code ile aç
# VS Code'da "Accept Current", "Accept Incoming",
# "Accept Both" seçenekleri var

$ git add src/auth.js
$ git commit -m "fix: Resolve merge conflict in auth"

Soru 7: "Fast-forward merge nedir?"

Beklenen cevap düzeyi: Mid

Fast-forward merge, branch'in main'den ayrıldığı noktadan
sonra main'e HİÇ commit eklenmemişse olur.

Başlangıç:
  main     A───B───C
                    \
  feature            D───E

main'de C'den sonra yeni commit yok → fast-forward mümkün!

Fast-forward sonrası:
  main     A───B───C───D───E  (pointer ilerletildi)

Merge commit OLUŞMAZ — sadece main pointer'ı ileri taşınır.

Eğer main'de yeni commit olsaydı:
  main     A───B───C───F
                    \
  feature            D───E
  
  → Fast-forward MÜMKÜN DEĞİL → 3-way merge yapılır → merge commit oluşur

Kategori 3: İleri Seviye Sorular

Soru 8: "git stash ne işe yarar? Gerçek kullanım senaryosu verin."

Beklenen cevap düzeyi: Mid

Stash, yarım kalmış değişiklikleri geçici olarak "rafa kaldırır."
Branch değiştirmek istiyorsun ama commit atacak durumda değilsin.

Senaryo:
  → feature/login üzerinde çalışıyorsun
  → Acil bir bug raporu geldi, hotfix yapman lazım
  → Ama yarım kalmış kodu commit etmek istemiyorsun

Çözüm:
  $ git stash                     # Değişiklikleri rafla
  $ git checkout main
  $ git checkout -b hotfix/bug
  # ... bug'ı düzelt, commit et, merge et ...
  $ git checkout feature/login
  $ git stash pop                 # Raftan geri al
  # Yarım kalmış çalışma geri geldi!

İleri kullanım:
  $ git stash list                # Tüm stash'leri gör
  $ git stash save "WIP: login"  # İsimli stash
  $ git stash apply stash@{1}    # Belirli stash'i uygula (silme)
  $ git stash drop stash@{0}     # Stash'i sil
  $ git stash branch yeni-branch # Stash'ten branch oluştur

Soru 9: "git cherry-pick ne yapar? Ne zaman kullanırsınız?"

Beklenen cevap düzeyi: Mid-Senior

Cherry-pick, belirli bir commit'i başka bir branch'e "kopyalar."
Tüm branch'i merge etmeden, TEK BİR commit'i almak.

Senaryo:
  → develop'ta bir bug fix yapıldı (commit: abc123)
  → Bu fix'i main'e de almak istiyorsun ama develop'taki
    diğer commit'leri almak istemiyorsun

  $ git checkout main
  $ git cherry-pick abc123

Yaygın kullanım durumları:
  1. Hotfix'i birden fazla branch'e uygulama
  2. Yanlış branch'e yapılan commit'i doğru branch'e taşıma
  3. Release branch'ine belirli fix'leri seçerek alma

Soru 10: "git bisect nedir? Nasıl kullanılır?"

Beklenen cevap düzeyi: Senior

Bisect, bir bug'ın HANGİ commit ile girdiğini bulmak için
binary search yapan Git aracı.

Senaryo:
  → Uygulama 2 hafta önce çalışıyordu, şimdi bozuk
  → 200 commit var arada — hangisi bozdu?
  → Manual kontrol: 200 commit → 200 test
  → Bisect (binary search): 200 commit → ~8 test

Kullanım:
  $ git bisect start
  $ git bisect bad                # Şu an bozuk
  $ git bisect good v1.0          # v1.0'da çalışıyordu
  
  # Git otomatik olarak ortadaki commit'e gider
  # Test et: çalışıyor mu?
  $ git bisect good               # Çalışıyorsa
  $ git bisect bad                # Çalışmıyorsa
  
  # 7-8 adımda suçlu commit bulunur:
  # abc1234 is the first bad commit
  
  $ git bisect reset              # Bitir, eski haline dön
  
  # Otomatik bisect (test script'i ile):
  $ git bisect start HEAD v1.0
  $ git bisect run npm test       # Her adımda npm test çalışır

Soru 11: "Detached HEAD nedir? Ne yaparsınız?"

Beklenen cevap düzeyi: Mid-Senior

HEAD, "şu an hangi commit'tesin" bilgisini tutar.
Normal durumda HEAD bir BRANCH'i gösterir.

Normal durum:
  HEAD → main → abc123  (HEAD, main branch'ine bağlı)

Detached HEAD:
  HEAD → abc123  (HEAD doğrudan commit'e bakıyor, branch'e değil)
  
Ne zaman olur?
  $ git checkout abc123       # Eski commit'e gitmek
  $ git checkout v1.0         # Tag'e gitmek
  
Neden sorun?
  → Detached HEAD'de commit yapabilirsin
  → AMA bir branch'e bağlamadan çıkarsan, commit'ler kaybolur
  → (Reflog'dan kurtarılabilir ama riskli)

Çözüm:
  $ git checkout abc123       # Detached HEAD'desin
  $ git checkout -b fix/bug   # Branch oluştur → artık güvendesin
  # veya
  $ git switch main           # Branch'e geri dön

Soru 12: "git reflog nedir? Hayat kurtarır mı?"

Beklenen cevap düzeyi: Senior

Reflog, HEAD'in GEÇMİŞ HAREKETLERİNİN kaydıdır.
"Git'in gizli geri dönüşüm kutusu" gibi düşün.

git log → commit tarihçesi (dallanma yapısı)
git reflog → HEAD'in her hareketinin kaydı (kronolojik)

Neden hayat kurtarır?
  → git reset --hard yaptın ve commit'ler "kayboldu"?
  → Reflog'dan kurtarabilirsin!

  $ git reflog
  abc1234 HEAD@{0}: reset: moving to HEAD~3   ← Burada reset yaptın
  def5678 HEAD@{1}: commit: Important feature  ← Kayıp commit!
  ghi9012 HEAD@{2}: commit: Another change
  jkl3456 HEAD@{3}: commit: Bug fix

  # Kayıp commit'e geri dön:
  $ git reset --hard def5678
  # veya
  $ git checkout -b recovery def5678

Altın kural: Git'te silinen neredeyse her şey
30 gün boyunca reflog'da kalır.
Gerçek veri kaybı nadir — sadece gc çalışırsa.

Kategori 4: Pratik Senaryo Soruları

Senaryo 1: "Yanlışlıkla main'e commit ettiniz. Ne yaparsınız?"

# Durum: main'de olman gerekirken commit attın
# Çözüm: Commit'i yeni bir branch'e taşı

# 1. Commit'lerin kaç tane olduğunu kontrol et
$ git log --oneline -5

# 2. Yeni branch oluştur (commit'ler dahil)
$ git branch feature/my-work

# 3. main'i geri al
$ git reset --hard HEAD~2  # 2 commit geri (push etmemişsen)

# 4. Yeni branch'e geç
$ git checkout feature/my-work

# Eğer zaten push ettiysen:
$ git revert HEAD~2..HEAD  # Revert commit'leri oluştur
$ git push origin main

Senaryo 2: "Commit mesajını yanlış yazdınız. Nasıl düzeltirsiniz?"

# Son commit'in mesajını düzelt:
$ git commit --amend -m "Doğru mesaj"

# Eski bir commit'in mesajını düzelt:
$ git rebase -i HEAD~5  # Son 5 commit'i aç
# İlgili commit'in "pick"ini "reword" yap
# Kaydet → yeni editör açılır → mesajı düzelt

# DİKKAT: Push ettiysen --force-with-lease gerekir
$ git push --force-with-lease origin feature/branch

Senaryo 3: "Büyük bir dosyayı yanlışlıkla commit ettiniz (100MB video). Nasıl kaldırırsınız?"

# Son commit'teyse:
$ git reset HEAD~1        # Commit'i geri al
$ echo "*.mp4" >> .gitignore
$ git add .gitignore
$ git commit -m "chore: Add video files to gitignore"

# Daha eski commit'lerdeyse:
$ git filter-repo --path large-video.mp4 --invert-paths

# veya BFG Repo Cleaner:
$ bfg --delete-files large-video.mp4

# DİKKAT: Tarihçe rewrite olur → tüm ekip etkilenir
# Push sonrası: git push --force-with-lease

Senaryo 4: "git pull yaptınız, merge conflict çıktı. Tüm değişikliklerinizi kaybetmeden nasıl çözersiniz?"

# Panik yapma! Değişikliklerin güvende.

# Seçenek 1: Conflict'i çöz
$ git status                  # Conflict'li dosyaları gör
$ code src/auth.js            # Dosyayı aç, marker'ları temizle
$ git add src/auth.js
$ git commit

# Seçenek 2: Merge'i iptal et (her şeyi geri al)
$ git merge --abort           # Pull/merge öncesine dön

# Seçenek 3: Kendi değişikliklerini koru (theirs/ours)
$ git checkout --ours src/auth.js    # Senin versiyonunu al
$ git checkout --theirs src/auth.js  # Remote versiyonunu al

Senaryo 5: "Commit'i yanlış branch'e yaptınız. Doğru branch'e nasıl taşırsınız?"

# Durum: develop'a yapman gereken commit'i main'e yaptın

# 1. Commit hash'ini not al
$ git log --oneline -1
# abc1234 feat: Add new feature

# 2. Doğru branch'e geç ve cherry-pick yap
$ git checkout develop
$ git cherry-pick abc1234

# 3. Yanlış branch'teki commit'i geri al
$ git checkout main
$ git reset --hard HEAD~1  # Push etmemişsen
# veya
$ git revert abc1234       # Push ettiysen

Senaryo 6: "'Bende çalışıyor' — ekip arkadaşınızda çalışmıyor. Ne yaparsınız?"

Checklist:
1. Branch'ler aynı mı? → git branch, git log karşılaştır
2. npm install yaptı mı? → node_modules güncel mi?
3. .env dosyası doğru mu? → Environment variables kontrol et
4. OS farkı mı? → Windows/Mac/Linux path, line ending farkları
5. Node/Python versiyonu aynı mı? → node -v, python --version
6. Cache sorunu mu? → rm -rf node_modules && npm ci
7. Git durumu temiz mi? → git status, untracked dosyalar var mı?
8. .gitignore sorunu mu? → Gerekli dosya ignore edilmiş olabilir

Kategori 5: Troubleshooting

Problem 1: "fatal: not a git repository"

$ git status
fatal: not a git repository (or any of the parent directories): .git

# Sebep: Bulunduğun dizin bir Git repo'su değil
# Çözüm:
$ pwd                    # Neredesin kontrol et
$ cd /path/to/project    # Doğru dizine git
$ ls -la .git            # .git var mı kontrol et
# Yoksa: git init veya git clone yap

Problem 2: "error: failed to push some refs"

$ git push origin main
! [rejected] main -> main (non-fast-forward)

# Sebep: Remote'ta senin yerel branch'inde olmayan commit'ler var
# Çözüm:
$ git pull --rebase origin main  # Önce güncellendir
$ git push origin main           # Sonra push et

# YANLIŞ ÇÖZÜM:
$ git push --force  # ❌ Başkasının çalışmasını ezebilir!

Problem 3: "Your branch is ahead/behind"

$ git status
Your branch is ahead of 'origin/main' by 3 commits.

# Ahead = Push etmediğin commit'ler var
$ git push origin main

Your branch is behind 'origin/main' by 5 commits.

# Behind = Remote'ta senin yerelinde olmayan commit'ler var
$ git pull origin main

Problem 4: "CRLF / LF satır sonu sorunları"

# Windows: CRLF (\r\n), Linux/Mac: LF (\n)
# Ekipteki farklı OS'ler sorun çıkarır

# Çözüm 1: Git config
$ git config --global core.autocrlf true   # Windows
$ git config --global core.autocrlf input  # Mac/Linux

# Çözüm 2: .gitattributes (en iyi çözüm — repo bazlı)
# .gitattributes dosyası:
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

Problem 5: "Yanlışlıkla git reset --hard yaptım!"

# Panik yapma! Reflog kurtarır.

$ git reflog
abc1234 HEAD@{0}: reset: moving to HEAD~5
def5678 HEAD@{1}: commit: My important work    ← BU!

$ git reset --hard def5678   # Kayıp commit'e geri dön
# veya
$ git checkout -b recovery def5678

# ⚠️ Eğer değişiklikler SADECE working directory'deyse
# (hiç commit etmemişsen) ve reset --hard yaptıysan:
# → Geri getirmek MÜMKÜN DEĞİL. git track etmediği
#   değişiklikleri kurtaramaz.

Mülakat Stratejisi ve İpuçları

Cevap Verme Yapısı

1. KISA CEVAP — Ne olduğunu 1-2 cümlede söyle
2. DERINLEŞTIR — Nasıl çalıştığını, neden var olduğunu açıkla
3. SENARYO VER — "Mesela şu durumda kullanırım..." de
4. TRADE-OFF — Avantaj/dezavantaj veya alternatif göster

Örnek: "git rebase nedir?"
  1. "Commit'leri başka bir base'in üzerine yeniden uygulayan komut."
  2. "Merge'den farklı olarak lineer tarihçe oluşturur, merge commit
     yaratmaz. Ama commit hash'lerini değiştirir."
  3. "Feature branch'imi main ile güncel tutmak için kullanırım.
     PR açmadan önce rebase yapıp temiz tarihçe sunarım."
  4. "Ama paylaşılmış branch'te tehlikeli — altın kural:
     push edilmiş commit'leri rebase etme."

Bilmediğinde Ne Yapmalı?

❌ Kötü: "Bilmiyorum." (ve susma)

✅ İyi:
  "Bu komutu aktif olarak kullanmıyorum ama bildiğim kadarıyla
   [genel bir açıklama]. Pratikte [benzer durumda ne yaptığını]
   anlatırım. Ayrıntılarını araştırıp öğrenebilirim."

  → Dürüstlük + öğrenme istekliliği = pozitif izlenim

En Çok Sorulan 10 Konu

Sıralama (mülakat sıklığına göre):

1. merge vs rebase (neredeyse HER mülakatta)
2. git reset vs revert
3. Merge conflict çözme
4. Branch stratejileri (Git Flow, GitHub Flow)
5. git stash kullanımı
6. Staging area'nın amacı
7. git fetch vs pull
8. Cherry-pick kullanım senaryosu
9. CI/CD pipeline açıklama
10. Büyük dosya / hassas bilgi sızıntısı çözümü

Quick Reference: Kurtarma Komutları

Mülakatlar dışında günlük hayatta da işe yarayacak bir referans:

# ═══════════════════════════════════════
# 🆘 KURTARMA KOMUTLARI
# ═══════════════════════════════════════

# Son commit'i geri al (değişiklikler kalır):
git reset --soft HEAD~1

# Son commit mesajını düzelt:
git commit --amend -m "Yeni mesaj"

# Staging'den çıkar (add'i geri al):
git restore --staged dosya.txt

# Dosyadaki değişiklikleri geri al:
git restore dosya.txt

# Merge/rebase'i iptal et:
git merge --abort
git rebase --abort

# Kayıp commit'i bul:
git reflog

# Silinen branch'i kurtar:
git reflog | grep "branch-adi"
git checkout -b branch-adi abc1234

# Tüm yerel değişiklikleri temizle:
git checkout -- .        # Tracked dosyalar
git clean -fd            # Untracked dosyalar (DİKKAT!)

# Remote ile senkronize ol (yerel = remote):
git fetch origin
git reset --hard origin/main

# Dosyanın eski versiyonunu geri getir:
git checkout abc1234 -- dosya.txt

# Büyük dosyayı tarihçeden sil:
git filter-repo --path dosya --invert-paths

# Tüm tag'leri ve branch'leri göster:
git log --oneline --graph --all --decorate

Kariyer İpuçları

GitHub Profilin = Dijital CV'n

Mülakat öncesi GitHub profilini kontrol edecekler:

1. Pinned repos — En iyi 6 projeni göster
2. README.md profili — Kim olduğunu, ne yaptığını anlat
3. Contribution graph — Düzenli commit at (her gün 1 bile yeterli)
4. Kod kalitesi — Commit mesajları temiz mi? PR'lar açıklayıcı mı?
5. Open source katkılar — Başka projelere katkı çok değerli

⚠️ Contribution graph gaming yapma — boş commit atmak belli olur.
Kaliteli, gerçek projeler göster.

Git Bilgini Nasıl Geliştirirsin?

1. Her gün Git kullan — teori değil pratik önemli
2. CLI'dan çalış — GUI'ler arkayı gizler, CLI öğretir
3. Zor durumları dene — bir test repo'sunda rebase, bisect, reflog dene
4. Open source'a katkı yap — gerçek dünya Git deneyimi
5. Ekip çalışması simüle et — arkadaşınla ortak repo'da çalış
6. Blog yaz — öğrendiğini anlatmak en iyi pekiştirme
7. ohshitgit.com — "Git ile işler ters gittiğinde" rehberi
8. learngitbranching.js.org — İnteraktif Git öğrenme

Özet

• Mülakatlarda Git soruları temel kavramlar (staging area, HEAD, branch), karşılaştırmalar (merge vs rebase, fetch vs pull, reset vs revert) ve pratik senaryolar (conflict çözme, yanlış commit kurtarma) üzerine yoğunlaşır

• Cevap verirken kısa tanım → derinleştirme → gerçek senaryo → trade-off yapısını takip et — bu, sistematik düşündüğünü gösterir

• Troubleshooting yeteneklerin (reflog ile kurtarma, bisect ile bug arama, stash ile context switching) ileri seviye değerlendirmede kritiktir

• git reflog neredeyse her "kayıp" durumda hayat kurtarır — commit edilmiş her şey 30 gün boyunca reflog'da kalır

• Git bilgini pratik yaparak geliştir — teori oku ama mutlaka kendi repo'nda dene; open source katkı en iyi öğrenme yoludur

• GitHub profilin dijital CV'ndir — temiz commit mesajları, düzenli katkılar ve kaliteli projeler kariyer fırsatlarını artırır

*Bu dersi tamamladığınız için tebrikler! 🎉 Git & GitHub kursunun sonuna geldiniz. Artık Git'in temellerinden ileri tekniklerine, GitHub Actions'tan gerçek dünya senaryolarına kadar geniş bir bilgiye sahipsiniz. Bundan sonrası pratik — her gün Git kullanarak, open source'a katkıda bulunarak ve ekip projelerinde çalışarak bu bilgiyi pekiştirin. Başarılar!*