Çoğu geliştirici beş Git komutu öğrenip orada durur. add, commit, push, pull, merge. Cesur hissediyorlarsa belki checkout ve branch. Bu seni ilk yıl idare ettirir. Sonra dalında "fix", "wip" ve "please work" gibi mesajlarla 47 commit olur, yanlışlıkla sıfırlamaması gereken bir şeyi sıfırlarsın ve ters giden bir merge'i geri almak için 40 dakika Stack Overflow'da geçirirsin.

Git'i yıllardır kullanıyorum. Sıradan bir şekilde değil — yoğun bir şekilde. Birden fazla dal, birden fazla repo, birden fazla katkıcı, tüm gün, her gün. Aşağıdakiler gerçekten kullandığım komutlar ve iş akışları. Bir eğitimde iyi görünenler değil. Bana her hafta gerçek zaman kazandıranlar.

Interactive Rebase: Kimse Görmeden Karmaşayı Temizle#

Dalında on iki commit var. Yarısı "fix typo." Biri "undo previous commit" diyor. Bir diğeri "actually fix it this time." PR açmak üzeresin. Kimsenin o geçmişi görmesine gerek yok.

Interactive rebase, dalındaki geçmişi paylaşmadan önce yeniden yazmanı sağlar. Commit'leri birleştirebilir, mesajları yeniden yazabilir, sıralayabilir veya tamamen düşürebilirsin.

Temel Komut#

bash

git rebase -i HEAD~5

Bu, son 5 commit'ini en eskiden en yeniye gösteren bir editör açar:

bash

pick a1b2c3d Add user authentication endpoint
pick d4e5f6g Fix typo in auth middleware
pick h7i8j9k Add rate limiting
pick l0m1n2o Fix rate limit bug
pick p3q4r5s Update auth tests

Her satır bir komutla başlar. pick'i şunlardan biriyle değiştir:

squash (veya s) — Bu commit'i üsttekiyle birleştir, mesajları birleştir
fixup (veya f) — Squash gibi, ama bu commit'in mesajını at
reword (veya r) — Commit'i koru ama mesajını değiştir
drop (veya d) — Bu commit'i tamamen sil
edit (veya e) — Rebase'i bu commit'te duraklat, amend edebilsin

Gerçek Bir Temizlik Oturumu#

İşte gerçekte yaptığım şey. Yukarıdaki dağınık geçmiş şöyle olur:

bash

pick a1b2c3d Add user authentication endpoint
fixup d4e5f6g Fix typo in auth middleware
pick h7i8j9k Add rate limiting
fixup l0m1n2o Fix rate limit bug
pick p3q4r5s Update auth tests

Kaydet ve kapat. Artık beş yerine üç temiz commit'in var. Typo düzeltmesi auth commit'ine katlanır. Rate limit bug düzeltmesi rate limit commit'ine katlanır. PR reviewer'ın temiz, mantıklı bir ilerleme görür.

Commit'leri Yeniden Sıralama#

Satırları kelimenin tam anlamıyla yeniden düzenleyebilirsin. Test commit'i rate limiting'den önce gelmeli ise, satırı taşı:

bash

pick a1b2c3d Add user authentication endpoint
pick p3q4r5s Update auth tests
pick h7i8j9k Add rate limiting

Git commit'lerini bu yeni sırada tekrar oynatır. Çakışma varsa durur ve çözmene izin verir.

Autosquash Kısayolu#

Bir commit'in öncekinin düzeltmesi olduğunu commit zamanında biliyorsan, commit'lerken işaretle:

bash

git commit --fixup=a1b2c3d

Bu, fixup! Add user authentication endpoint mesajlı bir commit oluşturur. Sonra rebase yaptığında:

bash

git rebase -i --autosquash HEAD~5

Git otomatik olarak fixup commit'lerini hedeflerinin hemen altına taşır ve fixup olarak işaretler. Sadece kaydet ve kapat. Manuel düzenleme yok.

Bunu sürekli kullanıyorum. Nihai geçmişi temiz tutarken bir dalda iterasyon yapmanın en hızlı yolu.

Altın Kural#

Paylaşılan bir dala push edilmiş commit'leri asla rebase'leme. Başka insanlar o commit'lerin üzerine iş inşa ettiyse, geçmişi yeniden yazmak gerçek sorunlara yol açar. Kendi feature dallarını birleştirmeden önce rebase'le. main'i asla rebase'leme.

Eğer feature dalını zaten push ettiysen ve rebase gerekiyorsa:

bash

git push --force-with-lease

--force-with-lease bayrağı --force'dan daha güvenli. Son fetch'inden beri aynı dala başka biri push ettiyse push'u reddeder.

Cherry-Pick: Cerrahi Commit Transferi#

Cherry-pick, bir daldan belirli bir commit'i alıp başka birine uygular. Merge değil. Rebase değil. Sadece bir commit, temizce uygulanmış.

Gerçekte Ne Zaman Kullanıyorum#

En yaygın senaryo: feature dalımda bir bug düzelttim, ama düzeltmenin main'e veya bir release dalına hemen gitmesi gerekiyor. Tüm feature dalımı merge etmek istemiyorum. Sadece o tek düzeltmeyi istiyorum.

bash

# Düzeltmenin commit hash'ini bul
git log --oneline feature/user-auth
# a1b2c3d Fix null pointer in session validation
 
# main'e geçip cherry-pick et
git checkout main
git cherry-pick a1b2c3d

Tamam. Düzeltme main'de aynı değişikliklerle yeni bir commit olarak var.

Commit Yapmadan Cherry-Pick#

Bazen değişiklikleri uygulamak ama henüz commit'lememek istersin:

bash

git cherry-pick --no-commit a1b2c3d

Değişiklikler staged ama commit edilmemiş. Değiştirebilir, daha fazla değişiklik ekleyebilir, hazır olunca commit edebilirsin.

Aralıklı Cherry-Pick#

Ardışık birden fazla commit mi gerekiyor? Aralık sözdizimini kullan:

bash

git cherry-pick a1b2c3d..f6g7h8i

Çakışmaları Yönetmek#

Cherry-pick çakışmaları merge çakışmaları gibi çalışır:

bash

# Git bir çakışma olduğunu söyleyecek
# Çakışan dosyaları düzelt, sonra:
git add .
git cherry-pick --continue

Veya vazgeçtiysen:

bash

git cherry-pick --abort

Git Bisect: Bug'lar İçin İkili Arama#

Bir şey bozuldu. İki hafta önce çalıştığını biliyorsun. O zamandan beri 200 commit var. Hangisi bozdu?

Her commit'i elle kontrol edebilirsin. Ya da git bisect kullanabilirsin, bu tam olarak bozulan commit'i bulmak için ikili arama kullanır. 200 commit için yaklaşık 7-8 kontrol, 200 yerine.

Manuel Yol#

bash

# Bisect'i başlat
git bisect start
 
# Mevcut commit'i kötü olarak işaretle (bug burada var)
git bisect bad
 
# Bilinen iyi bir commit'i işaretle (bug burada yoktu)
git bisect good v2.1.0

Git iyi ile kötü arasında yarıdaki bir commit'i checkout eder. Test et. Sonra:

bash

# Bug bu commit'te varsa:
git bisect bad
 
# Bug bu commit'te yoksa:
git bisect good

Git aralığı her seferinde yarıya böler. 7-8 adım sonra şunu söyler:

bash

a1b2c3d4e5f6g7h is the first bad commit
commit a1b2c3d4e5f6g7h
Author: Some Developer <dev@example.com>
Date: Tue Feb 18 14:23:01 2026 +0300
 
    Refactor session handling to use async middleware

Artık tam olarak hangi commit'in bug'ı tanıttığını biliyorsun. İşin bittiğinde:

bash

git bisect reset

Otomatik Yol (Asıl Güç Budur)#

Bug'ı tespit edebilen bir testin varsa, her şeyi otomatikleştirebilirsin:

bash

git bisect start
git bisect bad HEAD
git bisect good v2.1.0
git bisect run npm test -- --grep "session validation"

Git otomatik olarak commit'leri checkout eder, testi çalıştırır ve çıkış koduna göre iyi veya kötü olarak işaretler. Git away, geri gel, ve sana tam commit'i söyler.

Git Worktree: Birden Fazla Dal, Sıfır Stash#

Bu en az kullanılan Git özelliği. Çoğu geliştiricinin varlığından haberi olmadığına eminim.

Problem: bir feature dalında derinlerdesin. Her yerde değişmiş dosyalar var. Sonra biri "şu production bug'ına hızlıca bakabilir misin?" diyor. Üç seçeneğin var:

Her şeyi stash'le, dal değiştir, düzelt, geri dön, stash'i pop et. Hiçbir şeyin ters gitmeyeceğini um.
Yarım kalmış işini "wip" mesajıyla commit'le. Çirkin ama işlevsel.
Repo'yu başka bir dizine tekrar klonla.

Ya da seçenek 4: worktree.

Worktree Nedir#

Worktree, aynı repository'ye bağlı ikinci (veya üçüncü, veya dördüncü) çalışma dizini. Her worktree'nin kendi checkout edilmiş dalı, kendi çalışma dosyaları, kendi index'i var. Ama aynı .git verisini paylaşırlar, yani tüm repo'yu çoğaltmıyorsun.

Worktree Ekleme#

bash

# feature/user-auth dalındasın, işin içindesin
# main'de bir bug düzeltmen gerekiyor:
 
git worktree add ../hotfix-session main

Bu, main checkout edilmiş yeni bir ../hotfix-session dizini oluşturur. Mevcut dizinin olduğu gibi kalır. Hiçbir şey stash'lenmez, commit'lenmez, bozulmaz.

bash

cd ../hotfix-session
# Bug'ı düzelt
git add .
git commit -m "Fix null pointer in session validation"
git push origin main
cd ../my-project
# Feature'ın üzerinde hiçbir şey olmamış gibi çalışmaya devam et

Worktree'leri Yönetme#

bash

# Tüm worktree'leri listele
git worktree list
 
# İşin bittiğinde worktree'yi kaldır
git worktree remove ../hotfix-session
 
# Dizin zaten silindiyse:
git worktree prune

Bu Neden Stash'ten İyi#

Stash hızlı bağlam değişiklikleri için iyi. Ama worktree'ler beş dakikadan fazla sürecek her şey için daha iyi:

IDE'n feature dalında açık kalır. Yeniden indeksleme yok, scroll pozisyonunu kaybetme yok.
Her iki dizinde aynı anda test çalıştırabilirsin.
Stash çakışması veya neyi stash'lediğini unutma riski yok.
Bir worktree'de uzun süren dev server, diğerinde temiz build olabilir.

Reflog: Her Şey İçin Geri Al Butonu#

Hard reset yaptın ve commit'leri kaybettin. Bir dalı sildin. Rebase yaptın ve her şey berbat oldu. İşinin gittiğini düşünüyorsun.

Gitmedi. Git neredeyse hiçbir şeyi gerçekten silmez. Reflog güvenlik ağın.

Reflog Nedir#

HEAD her hareket ettiğinde — her commit, checkout, rebase, reset, merge — Git bunu reflog'a kaydeder.

bash

git reflog

Çıktı:

bash

a1b2c3d (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3
f4e5d6c HEAD@{1}: commit: Add payment processing
b7a8c9d HEAD@{2}: commit: Update user dashboard
e0f1g2h HEAD@{3}: commit: Fix auth token refresh
i3j4k5l HEAD@{4}: checkout: moving from feature/payments to main

Hard Reset Sonrası Kurtarma#

Yanlışlıkla git reset --hard HEAD~3 çalıştırdın ve üç commit'i kaybettin. Reflog'da duruyorlar:

bash

# Neyi kaybettiğini gör
git reflog
 
# Reset'ten önceki commit HEAD@{1}
git reset --hard f4e5d6c

Üç commit geri geldi. Kriz önlendi.

Silinen Dalı Kurtarma#

Merge edilmemiş işi olan bir dalı sildin:

bash

git branch -D feature/experimental
# Hayır, orada iki haftalık iş vardı

Commit'ler hâlâ var. Bul:

bash

git reflog | grep "feature/experimental"
 
# Buldun. Dalı o commit'te yeniden oluştur:
git branch feature/experimental a1b2c3d

Dal tüm commit'leriyle geri döndü.

Kötü Rebase Sonrası Kurtarma#

Rebase yaptın ve her şey ters gitti:

bash

# Reflog rebase'den önce nerede olduğunu gösterir
git reflog
# b7a8c9d HEAD@{6}: commit: Your last good commit
 
# Rebase'den öncesine dön
git reset --hard b7a8c9d

Rebase başlamadan önceki haline döndün. Sanki hiç olmamış gibi.

Stash'i Düzgün Kullan#

Çoğu kişi stash'i şöyle kullanır:

bash

git stash
# bir şey yap
git stash pop

Bu çalışır, ama her şeyi "eşyalar" etiketli bir kutuya atmaya eşdeğer.

Stash'lerine İsim Ver#

bash

git stash push -m "WIP: user auth form validation"

İzlenmeyen Dosyaları Dahil Et#

bash

# Yeni dosyalar dahil her şeyi stash'le
git stash push --include-untracked -m "WIP: new auth components"

Kısmi Stash#

Belirli dosyaları stash'leyebilirsin:

bash

# Sadece belirli dosyaları stash'le
git stash push -m "Just the auth changes" src/auth/ src/middleware.ts

Dallanma Stratejileri: Hangisi Gerçekten Çalışıyor#

Gitflow#

Klasik. main, develop, feature/*, release/*, hotfix/*.

Ne zaman çalışır: Mobil uygulamalar, masaüstü yazılımları, adlandırılmış sürümlü release'leri olan ve aynı anda birden fazla sürümü desteklenen her şey.

Ne zaman çalışmaz: Sürekli deployment'lı web uygulamaları. Günde 5 kez production'a deploy ediyorsan, release dalları ve develop dalları saf yük.

GitHub Flow#

Basit. main'in var. Feature dalları oluşturursun. PR açarsın. main'e merge edersin. main'i deploy edersin.

Ne zaman çalışır: Web uygulamaları gönderen küçük-orta takımlar. Sürekli deployment. main her zaman deploy ediliyorsa, ihtiyacın olan her şey bu.

Trunk-Based Development#

Herkes doğrudan main'e (trunk) commit eder veya çok kısa ömürlü dallar (bir günden az) üzerinden. Uzun süren feature dalları yok.

Ne zaman çalışır: İyi CI/CD'si, kapsamlı test suite'i ve feature flag'leri olan yüksek performanslı takımlar.

Benim Tavsiyem#

Çoğu web geliştirme takımı için: GitHub Flow ile başla. Basit, çalışıyor.

Takımın 15-20 mühendisi aşarsa ve günde birden fazla deploy ediyorsan, feature flag'lerle trunk-based development'a bak.

Sürümlü yazılım gönderiyorsan (mobil uygulamalar, CLI araçları, kütüphaneler): Gitflow veya basitleştirilmiş versiyonu.

Bir blog yazısı "en iyisi bu" dediği için strateji seçme. Gerçekte nasıl gönderdiğine uyanı seç.

Git Hook'ları: Sürekli Unuttuğun Şeyleri Otomatikleştir#

pre-commit — Her commit'ten önce çalışır. Linting ve formatlama için kullan:

bash

#!/bin/bash
# .git/hooks/pre-commit
 
# ESLint'i sadece staged dosyalarda çalıştır
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|ts|tsx)$')
 
if [ -n "$STAGED_FILES" ]; then
  echo "Running ESLint on staged files..."
  npx eslint $STAGED_FILES --quiet
  if [ $? -ne 0 ]; then
    echo "ESLint failed. Fix errors before committing."
    exit 1
  fi
fi

commit-msg — Commit mesajı formatını doğrular:

bash

#!/bin/bash
# .git/hooks/commit-msg
 
COMMIT_MSG=$(cat "$1")
PATTERN="^(feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert)(\(.+\))?: .{1,72}"
 
if ! echo "$COMMIT_MSG" | grep -qE "$PATTERN"; then
  echo "Invalid commit message format."
  echo "Expected: type(scope): description"
  exit 1
fi

Husky vs Native Hook'lar#

Husky hook yapılandırmalarını repo'da saklar ve npm install'da .git/hooks'u otomatik kurar:

bash

npx husky init

lint-staged ile birleştirildiğinde hızlı, hedefli pre-commit kontrolleri elde edersin:

json

{
  "lint-staged": {
    "*.{js,ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.css": ["prettier --write"],
    "*.json": ["prettier --write"]
  }
}

Zaman Kazandıran Alias'lar#

Pretty Log#

bash

git config --global alias.lg "log --oneline --graph --all --decorate"

Bunu günde 20 kez çalıştırıyorum. Repository'nin durumunu anlamanın en hızlı yolu.

Son Commit'i Geri Al#

bash

git config --global alias.undo "reset HEAD~1 --mixed"

Daha Fazla Kullandığım Alias'lar#

bash

# Commit edeceğin şeyi göster
git config --global alias.staged "diff --staged"
 
# Kısa durum
git config --global alias.st "status -sb"
 
# Mesajı değiştirmeden amend
git config --global alias.amend "commit --amend --no-edit"
 
# Merge yerine rebase ile pull
git config --global alias.up "pull --rebase --autostash"
 
# main'e merge edilmiş dalları sil
git config --global alias.cleanup "!git branch --merged main | grep -v '^[ *]*main$' | xargs git branch -d"

up alias'ı özellikle iyi. pull --rebase her pull için merge commit'i oluşturmak yerine geçmişini düz tutar. --autostash kirli dosyaların varsa değişikliklerini otomatik stash'ler ve geri yükler.

Her Gün Kullandığım Komutlar#

Staged Değişiklikleri Diff'le#

bash

git diff --staged

Bu commit'lenecek olanı gösterir. Commit'lemeden önce her zaman çalıştırıyorum. Her zaman. Yanlışlıkla dahil etmeleri, debug ifadelerini, olmaması gereken console.log'ları yakalar.

Belirli Bir Commit'i Göster#

bash

git show a1b2c3d

Satır Aralıklı Blame#

bash

git blame -L 42,60 src/auth/session.ts

42-60 arasındaki satırları kimin en son değiştirdiğini gösterir.

Tüm Geçmişte String Ara#

bash

# Bir fonksiyonun ne zaman eklendiğini veya kaldırıldığını bul
git log -S "validateSession" --oneline
 
# Bir regex kalıbının ne zaman göründüğünü bul
git log -G "session.*timeout" --oneline

Her Şeyi Bir Araya Koyma: Gerçek Bir İş Akışı#

Tipik bir gün bu araçlarla şöyle görünür:

bash

# Sabah: neler oluyor kontrol et
git lg
git fetch --all
 
# Bir feature başlat
git checkout -b feature/session-refresh main
 
# Çalış, artımlı commit'le
git add -p                        # Tüm dosyalar değil, belirli hunk'lar stage et
git commit -m "Add token refresh endpoint"
 
# Araya girme: production bug düzeltmesi gerekiyor
git worktree add ../hotfix main
cd ../hotfix
# ... düzelt, commit'le, push et, PR merge edildi ...
cd ../my-project
git worktree remove ../hotfix
 
# PR'a hazır: geçmişi temizle
git rebase -i main
 
# Push et ve PR aç
git push -u origin feature/session-refresh
 
# Staging'de bir şey mi bozuldu? Hangi commit bul:
git bisect start
git bisect bad HEAD
git bisect good main
git bisect run npm test
 
# Yanlış şeyi hard-reset ettim
git reflog
git reset --hard HEAD@{2}

Bu komutların her biri saniyeler sürer. Birlikte, saatler kazandırır. Varsayımsal saatler değil — gerçek saatler, her hafta.

Git, derinliği ödüllendiren bir araç. Temel bilgiler günü kurtarır. Ama bu yazıdaki komutlar, "Git kullanıyorum" ile "Git beni gerçekten hızlandırıyor" arasını ayıran şeyler. Artımlı öğren. Bu hafta bir yeni teknik seç ve kas hafızası olana kadar kullan. Sonra bir tane daha seç.

Gece 11'de bir production bug'ına bakan gelecekteki sen, git bisect'i bildiğin için sana teşekkür edecek.

Interactive Rebase: Kimse Görmeden Karmaşayı Temizle#

Dalında on iki commit var. Yarısı "fix typo." Biri "undo previous commit" diyor. Bir diğeri "actually fix it this time." PR açmak üzeresin. Kimsenin o geçmişi görmesine gerek yok.

Interactive rebase, dalındaki geçmişi paylaşmadan önce yeniden yazmanı sağlar. Commit'leri birleştirebilir, mesajları yeniden yazabilir, sıralayabilir veya tamamen düşürebilirsin.

Temel Komut#

bash

git rebase -i HEAD~5

Bu, son 5 commit'ini en eskiden en yeniye gösteren bir editör açar:

bash

pick a1b2c3d Add user authentication endpoint
pick d4e5f6g Fix typo in auth middleware
pick h7i8j9k Add rate limiting
pick l0m1n2o Fix rate limit bug
pick p3q4r5s Update auth tests

Her satır bir komutla başlar. pick'i şunlardan biriyle değiştir:

squash (veya s) — Bu commit'i üsttekiyle birleştir, mesajları birleştir
fixup (veya f) — Squash gibi, ama bu commit'in mesajını at
reword (veya r) — Commit'i koru ama mesajını değiştir
drop (veya d) — Bu commit'i tamamen sil
edit (veya e) — Rebase'i bu commit'te duraklat, amend edebilsin

Gerçek Bir Temizlik Oturumu#

İşte gerçekte yaptığım şey. Yukarıdaki dağınık geçmiş şöyle olur:

bash

pick a1b2c3d Add user authentication endpoint
fixup d4e5f6g Fix typo in auth middleware
pick h7i8j9k Add rate limiting
fixup l0m1n2o Fix rate limit bug
pick p3q4r5s Update auth tests

Commit'leri Yeniden Sıralama#

Satırları kelimenin tam anlamıyla yeniden düzenleyebilirsin. Test commit'i rate limiting'den önce gelmeli ise, satırı taşı:

bash

pick a1b2c3d Add user authentication endpoint
pick p3q4r5s Update auth tests
pick h7i8j9k Add rate limiting

Git commit'lerini bu yeni sırada tekrar oynatır. Çakışma varsa durur ve çözmene izin verir.

Autosquash Kısayolu#

Bir commit'in öncekinin düzeltmesi olduğunu commit zamanında biliyorsan, commit'lerken işaretle:

bash

git commit --fixup=a1b2c3d

Bu, fixup! Add user authentication endpoint mesajlı bir commit oluşturur. Sonra rebase yaptığında:

bash

git rebase -i --autosquash HEAD~5

Git otomatik olarak fixup commit'lerini hedeflerinin hemen altına taşır ve fixup olarak işaretler. Sadece kaydet ve kapat. Manuel düzenleme yok.

Bunu sürekli kullanıyorum. Nihai geçmişi temiz tutarken bir dalda iterasyon yapmanın en hızlı yolu.

Altın Kural#

Eğer feature dalını zaten push ettiysen ve rebase gerekiyorsa:

bash

git push --force-with-lease

--force-with-lease bayrağı --force'dan daha güvenli. Son fetch'inden beri aynı dala başka biri push ettiyse push'u reddeder.

Cherry-Pick: Cerrahi Commit Transferi#

Cherry-pick, bir daldan belirli bir commit'i alıp başka birine uygular. Merge değil. Rebase değil. Sadece bir commit, temizce uygulanmış.

Gerçekte Ne Zaman Kullanıyorum#

bash

# Düzeltmenin commit hash'ini bul
git log --oneline feature/user-auth
# a1b2c3d Fix null pointer in session validation
 
# main'e geçip cherry-pick et
git checkout main
git cherry-pick a1b2c3d

Tamam. Düzeltme main'de aynı değişikliklerle yeni bir commit olarak var.

Commit Yapmadan Cherry-Pick#

Bazen değişiklikleri uygulamak ama henüz commit'lememek istersin:

bash

git cherry-pick --no-commit a1b2c3d

Değişiklikler staged ama commit edilmemiş. Değiştirebilir, daha fazla değişiklik ekleyebilir, hazır olunca commit edebilirsin.

Aralıklı Cherry-Pick#

Ardışık birden fazla commit mi gerekiyor? Aralık sözdizimini kullan:

bash

git cherry-pick a1b2c3d..f6g7h8i

Çakışmaları Yönetmek#

Cherry-pick çakışmaları merge çakışmaları gibi çalışır:

bash

# Git bir çakışma olduğunu söyleyecek
# Çakışan dosyaları düzelt, sonra:
git add .
git cherry-pick --continue

Veya vazgeçtiysen:

bash

git cherry-pick --abort

Git Bisect: Bug'lar İçin İkili Arama#

Bir şey bozuldu. İki hafta önce çalıştığını biliyorsun. O zamandan beri 200 commit var. Hangisi bozdu?

Her commit'i elle kontrol edebilirsin. Ya da git bisect kullanabilirsin, bu tam olarak bozulan commit'i bulmak için ikili arama kullanır. 200 commit için yaklaşık 7-8 kontrol, 200 yerine.

Manuel Yol#

bash

# Bisect'i başlat
git bisect start
 
# Mevcut commit'i kötü olarak işaretle (bug burada var)
git bisect bad
 
# Bilinen iyi bir commit'i işaretle (bug burada yoktu)
git bisect good v2.1.0

Git iyi ile kötü arasında yarıdaki bir commit'i checkout eder. Test et. Sonra:

bash

# Bug bu commit'te varsa:
git bisect bad
 
# Bug bu commit'te yoksa:
git bisect good

Git aralığı her seferinde yarıya böler. 7-8 adım sonra şunu söyler:

bash

a1b2c3d4e5f6g7h is the first bad commit
commit a1b2c3d4e5f6g7h
Author: Some Developer <dev@example.com>
Date: Tue Feb 18 14:23:01 2026 +0300
 
    Refactor session handling to use async middleware

Artık tam olarak hangi commit'in bug'ı tanıttığını biliyorsun. İşin bittiğinde:

bash

git bisect reset

Otomatik Yol (Asıl Güç Budur)#

Bug'ı tespit edebilen bir testin varsa, her şeyi otomatikleştirebilirsin:

bash

git bisect start
git bisect bad HEAD
git bisect good v2.1.0
git bisect run npm test -- --grep "session validation"

Git otomatik olarak commit'leri checkout eder, testi çalıştırır ve çıkış koduna göre iyi veya kötü olarak işaretler. Git away, geri gel, ve sana tam commit'i söyler.

Git Worktree: Birden Fazla Dal, Sıfır Stash#

Bu en az kullanılan Git özelliği. Çoğu geliştiricinin varlığından haberi olmadığına eminim.

Problem: bir feature dalında derinlerdesin. Her yerde değişmiş dosyalar var. Sonra biri "şu production bug'ına hızlıca bakabilir misin?" diyor. Üç seçeneğin var:

Her şeyi stash'le, dal değiştir, düzelt, geri dön, stash'i pop et. Hiçbir şeyin ters gitmeyeceğini um.
Yarım kalmış işini "wip" mesajıyla commit'le. Çirkin ama işlevsel.
Repo'yu başka bir dizine tekrar klonla.

Ya da seçenek 4: worktree.

Worktree Nedir#

Worktree Ekleme#

bash

# feature/user-auth dalındasın, işin içindesin
# main'de bir bug düzeltmen gerekiyor:
 
git worktree add ../hotfix-session main

Bu, main checkout edilmiş yeni bir ../hotfix-session dizini oluşturur. Mevcut dizinin olduğu gibi kalır. Hiçbir şey stash'lenmez, commit'lenmez, bozulmaz.

bash

cd ../hotfix-session
# Bug'ı düzelt
git add .
git commit -m "Fix null pointer in session validation"
git push origin main
cd ../my-project
# Feature'ın üzerinde hiçbir şey olmamış gibi çalışmaya devam et

Worktree'leri Yönetme#

bash

# Tüm worktree'leri listele
git worktree list
 
# İşin bittiğinde worktree'yi kaldır
git worktree remove ../hotfix-session
 
# Dizin zaten silindiyse:
git worktree prune

Bu Neden Stash'ten İyi#

Stash hızlı bağlam değişiklikleri için iyi. Ama worktree'ler beş dakikadan fazla sürecek her şey için daha iyi:

IDE'n feature dalında açık kalır. Yeniden indeksleme yok, scroll pozisyonunu kaybetme yok.
Her iki dizinde aynı anda test çalıştırabilirsin.
Stash çakışması veya neyi stash'lediğini unutma riski yok.
Bir worktree'de uzun süren dev server, diğerinde temiz build olabilir.

Reflog: Her Şey İçin Geri Al Butonu#

Hard reset yaptın ve commit'leri kaybettin. Bir dalı sildin. Rebase yaptın ve her şey berbat oldu. İşinin gittiğini düşünüyorsun.

Gitmedi. Git neredeyse hiçbir şeyi gerçekten silmez. Reflog güvenlik ağın.

Reflog Nedir#

HEAD her hareket ettiğinde — her commit, checkout, rebase, reset, merge — Git bunu reflog'a kaydeder.

bash

git reflog

Çıktı:

bash

a1b2c3d (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3
f4e5d6c HEAD@{1}: commit: Add payment processing
b7a8c9d HEAD@{2}: commit: Update user dashboard
e0f1g2h HEAD@{3}: commit: Fix auth token refresh
i3j4k5l HEAD@{4}: checkout: moving from feature/payments to main

Hard Reset Sonrası Kurtarma#

Yanlışlıkla git reset --hard HEAD~3 çalıştırdın ve üç commit'i kaybettin. Reflog'da duruyorlar:

bash

# Neyi kaybettiğini gör
git reflog
 
# Reset'ten önceki commit HEAD@{1}
git reset --hard f4e5d6c

Üç commit geri geldi. Kriz önlendi.

Silinen Dalı Kurtarma#

Merge edilmemiş işi olan bir dalı sildin:

bash

git branch -D feature/experimental
# Hayır, orada iki haftalık iş vardı

Commit'ler hâlâ var. Bul:

bash

git reflog | grep "feature/experimental"
 
# Buldun. Dalı o commit'te yeniden oluştur:
git branch feature/experimental a1b2c3d

Dal tüm commit'leriyle geri döndü.

Kötü Rebase Sonrası Kurtarma#

Rebase yaptın ve her şey ters gitti:

bash

# Reflog rebase'den önce nerede olduğunu gösterir
git reflog
# b7a8c9d HEAD@{6}: commit: Your last good commit
 
# Rebase'den öncesine dön
git reset --hard b7a8c9d

Rebase başlamadan önceki haline döndün. Sanki hiç olmamış gibi.

Stash'i Düzgün Kullan#

Çoğu kişi stash'i şöyle kullanır:

bash

git stash
# bir şey yap
git stash pop

Bu çalışır, ama her şeyi "eşyalar" etiketli bir kutuya atmaya eşdeğer.

Stash'lerine İsim Ver#

bash

git stash push -m "WIP: user auth form validation"

İzlenmeyen Dosyaları Dahil Et#

bash

# Yeni dosyalar dahil her şeyi stash'le
git stash push --include-untracked -m "WIP: new auth components"

Kısmi Stash#

Belirli dosyaları stash'leyebilirsin:

bash

# Sadece belirli dosyaları stash'le
git stash push -m "Just the auth changes" src/auth/ src/middleware.ts

Dallanma Stratejileri: Hangisi Gerçekten Çalışıyor#

Gitflow#

Klasik. main, develop, feature/*, release/*, hotfix/*.

Ne zaman çalışır: Mobil uygulamalar, masaüstü yazılımları, adlandırılmış sürümlü release'leri olan ve aynı anda birden fazla sürümü desteklenen her şey.

Ne zaman çalışmaz: Sürekli deployment'lı web uygulamaları. Günde 5 kez production'a deploy ediyorsan, release dalları ve develop dalları saf yük.

GitHub Flow#

Basit. main'in var. Feature dalları oluşturursun. PR açarsın. main'e merge edersin. main'i deploy edersin.

Ne zaman çalışır: Web uygulamaları gönderen küçük-orta takımlar. Sürekli deployment. main her zaman deploy ediliyorsa, ihtiyacın olan her şey bu.

Trunk-Based Development#

Herkes doğrudan main'e (trunk) commit eder veya çok kısa ömürlü dallar (bir günden az) üzerinden. Uzun süren feature dalları yok.

Ne zaman çalışır: İyi CI/CD'si, kapsamlı test suite'i ve feature flag'leri olan yüksek performanslı takımlar.

Benim Tavsiyem#

Çoğu web geliştirme takımı için: GitHub Flow ile başla. Basit, çalışıyor.

Takımın 15-20 mühendisi aşarsa ve günde birden fazla deploy ediyorsan, feature flag'lerle trunk-based development'a bak.

Sürümlü yazılım gönderiyorsan (mobil uygulamalar, CLI araçları, kütüphaneler): Gitflow veya basitleştirilmiş versiyonu.

Bir blog yazısı "en iyisi bu" dediği için strateji seçme. Gerçekte nasıl gönderdiğine uyanı seç.

Git Hook'ları: Sürekli Unuttuğun Şeyleri Otomatikleştir#

pre-commit — Her commit'ten önce çalışır. Linting ve formatlama için kullan:

bash

#!/bin/bash
# .git/hooks/pre-commit
 
# ESLint'i sadece staged dosyalarda çalıştır
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|ts|tsx)$')
 
if [ -n "$STAGED_FILES" ]; then
  echo "Running ESLint on staged files..."
  npx eslint $STAGED_FILES --quiet
  if [ $? -ne 0 ]; then
    echo "ESLint failed. Fix errors before committing."
    exit 1
  fi
fi

commit-msg — Commit mesajı formatını doğrular:

bash

#!/bin/bash
# .git/hooks/commit-msg
 
COMMIT_MSG=$(cat "$1")
PATTERN="^(feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert)(\(.+\))?: .{1,72}"
 
if ! echo "$COMMIT_MSG" | grep -qE "$PATTERN"; then
  echo "Invalid commit message format."
  echo "Expected: type(scope): description"
  exit 1
fi

Husky vs Native Hook'lar#

Husky hook yapılandırmalarını repo'da saklar ve npm install'da .git/hooks'u otomatik kurar:

bash

npx husky init

lint-staged ile birleştirildiğinde hızlı, hedefli pre-commit kontrolleri elde edersin:

json

{
  "lint-staged": {
    "*.{js,ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.css": ["prettier --write"],
    "*.json": ["prettier --write"]
  }
}

Zaman Kazandıran Alias'lar#

Pretty Log#

bash

git config --global alias.lg "log --oneline --graph --all --decorate"

Bunu günde 20 kez çalıştırıyorum. Repository'nin durumunu anlamanın en hızlı yolu.

Son Commit'i Geri Al#

bash

git config --global alias.undo "reset HEAD~1 --mixed"

Daha Fazla Kullandığım Alias'lar#

bash

# Commit edeceğin şeyi göster
git config --global alias.staged "diff --staged"
 
# Kısa durum
git config --global alias.st "status -sb"
 
# Mesajı değiştirmeden amend
git config --global alias.amend "commit --amend --no-edit"
 
# Merge yerine rebase ile pull
git config --global alias.up "pull --rebase --autostash"
 
# main'e merge edilmiş dalları sil
git config --global alias.cleanup "!git branch --merged main | grep -v '^[ *]*main$' | xargs git branch -d"

Her Gün Kullandığım Komutlar#

Staged Değişiklikleri Diff'le#

bash

git diff --staged

Bu commit'lenecek olanı gösterir. Commit'lemeden önce her zaman çalıştırıyorum. Her zaman. Yanlışlıkla dahil etmeleri, debug ifadelerini, olmaması gereken console.log'ları yakalar.

Belirli Bir Commit'i Göster#

bash

git show a1b2c3d

Satır Aralıklı Blame#

bash

git blame -L 42,60 src/auth/session.ts

42-60 arasındaki satırları kimin en son değiştirdiğini gösterir.

Tüm Geçmişte String Ara#

bash

# Bir fonksiyonun ne zaman eklendiğini veya kaldırıldığını bul
git log -S "validateSession" --oneline
 
# Bir regex kalıbının ne zaman göründüğünü bul
git log -G "session.*timeout" --oneline

Her Şeyi Bir Araya Koyma: Gerçek Bir İş Akışı#

Tipik bir gün bu araçlarla şöyle görünür:

bash

# Sabah: neler oluyor kontrol et
git lg
git fetch --all
 
# Bir feature başlat
git checkout -b feature/session-refresh main
 
# Çalış, artımlı commit'le
git add -p                        # Tüm dosyalar değil, belirli hunk'lar stage et
git commit -m "Add token refresh endpoint"
 
# Araya girme: production bug düzeltmesi gerekiyor
git worktree add ../hotfix main
cd ../hotfix
# ... düzelt, commit'le, push et, PR merge edildi ...
cd ../my-project
git worktree remove ../hotfix
 
# PR'a hazır: geçmişi temizle
git rebase -i main
 
# Push et ve PR aç
git push -u origin feature/session-refresh
 
# Staging'de bir şey mi bozuldu? Hangi commit bul:
git bisect start
git bisect bad HEAD
git bisect good main
git bisect run npm test
 
# Yanlış şeyi hard-reset ettim
git reflog
git reset --hard HEAD@{2}

Bu komutların her biri saniyeler sürer. Birlikte, saatler kazandırır. Varsayımsal saatler değil — gerçek saatler, her hafta.

Gece 11'de bir production bug'ına bakan gelecekteki sen, git bisect'i bildiğin için sana teşekkür edecek.

Interactive Rebase: Kimse Görmeden Karmaşayı Temizle#

Temel Komut#

Gerçek Bir Temizlik Oturumu#

Commit'leri Yeniden Sıralama#

Autosquash Kısayolu#

Altın Kural#

Cherry-Pick: Cerrahi Commit Transferi#

Gerçekte Ne Zaman Kullanıyorum#

Commit Yapmadan Cherry-Pick#

Aralıklı Cherry-Pick#

Çakışmaları Yönetmek#

Git Bisect: Bug'lar İçin İkili Arama#

Manuel Yol#

Otomatik Yol (Asıl Güç Budur)#

Git Worktree: Birden Fazla Dal, Sıfır Stash#

Worktree Nedir#

Worktree Ekleme#

Worktree'leri Yönetme#

Bu Neden Stash'ten İyi#

Reflog: Her Şey İçin Geri Al Butonu#

Reflog Nedir#

Hard Reset Sonrası Kurtarma#

Silinen Dalı Kurtarma#

Kötü Rebase Sonrası Kurtarma#

Stash'i Düzgün Kullan#

Stash'lerine İsim Ver#

İzlenmeyen Dosyaları Dahil Et#

Kısmi Stash#

Dallanma Stratejileri: Hangisi Gerçekten Çalışıyor#

Gitflow#

GitHub Flow#

Trunk-Based Development#

Benim Tavsiyem#

Git Hook'ları: Sürekli Unuttuğun Şeyleri Otomatikleştir#

Husky vs Native Hook'lar#

Zaman Kazandıran Alias'lar#

Pretty Log#

Son Commit'i Geri Al#

Daha Fazla Kullandığım Alias'lar#

Her Gün Kullandığım Komutlar#

Staged Değişiklikleri Diff'le#

Belirli Bir Commit'i Göster#

Satır Aralıklı Blame#

Tüm Geçmişte String Ara#

Her Şeyi Bir Araya Koyma: Gerçek Bir İş Akışı#

İlgili Yazılar

Best Free Online Developer Tools Every Developer Needs in 2026

Free Base64, URL & HTML Encoder/Decoder Tools Online

Interactive Rebase: Kimse Görmeden Karmaşayı Temizle#

Temel Komut#

Gerçek Bir Temizlik Oturumu#

Commit'leri Yeniden Sıralama#

Autosquash Kısayolu#

Altın Kural#

Cherry-Pick: Cerrahi Commit Transferi#

Gerçekte Ne Zaman Kullanıyorum#

Commit Yapmadan Cherry-Pick#

Aralıklı Cherry-Pick#

Çakışmaları Yönetmek#

Git Bisect: Bug'lar İçin İkili Arama#

Manuel Yol#

Otomatik Yol (Asıl Güç Budur)#

Git Worktree: Birden Fazla Dal, Sıfır Stash#

Worktree Nedir#

Worktree Ekleme#

Worktree'leri Yönetme#

Bu Neden Stash'ten İyi#

Reflog: Her Şey İçin Geri Al Butonu#

Reflog Nedir#

Hard Reset Sonrası Kurtarma#

Silinen Dalı Kurtarma#

Kötü Rebase Sonrası Kurtarma#

Stash'i Düzgün Kullan#

Stash'lerine İsim Ver#

İzlenmeyen Dosyaları Dahil Et#

Kısmi Stash#

Dallanma Stratejileri: Hangisi Gerçekten Çalışıyor#

Gitflow#

GitHub Flow#

Trunk-Based Development#