Git Geçmişi ve Yardım Komutları

Git Geçmişi ve Yardım Komutları: Deponuzu İnceleyin, Arayın ve Anlayın

Yararlı bir Git geçmişi, eski commit’lerin sıralandığı basit bir listeden çok daha fazlasıdır. Davranışın ne zaman değiştiğini, bir kararın neden alındığını, hangi dosyaların etkilendiğini, bir satıra en son kimin dokunduğunu ve mevcut projenin nasıl geliştiğini açıklayabilen teknik bir kayıttır.

Git bu kaydı incelemek için birbirini tamamlayan çeşitli araçlar sunar. git log commit’ler arasında gezinir, git show seçilen bir nesneyi inceler, git diff durumları karşılaştırır, git blame satırları commit’lere bağlar ve git reflog yerel referansların hareketlerini kaydeder. Git ayrıca kapsamlı bir yerleşik yardım sistemi içerir; bu nedenle etkili çalışmaya başlamadan önce her seçeneği ezberlemeniz gerekmez.

Bu rehber söz konusu komutları uygulamalı bir depo üzerinden açıklar; ardından gerçek geliştirme sorularını yanıtlamak için filtreleri, revision sözdizimini, path geçmişini, içerik aramalarını ve dokümantasyon araçlarını nasıl birlikte kullanacağınızı gösterir.

Neler Öğreneceksiniz?

• Git geçmişinin commit grafiği olarak nasıl düzenlendiğini.

• Kısa ve ayrıntılı log çıktılarının nasıl okunduğunu.

• Geçmişin author, tarih, mesaj, path ve merge durumuna göre nasıl filtrelendiğini.

• Log çıktılarının insanlar, raporlar ve script’ler için nasıl biçimlendirildiğini.

• Tek bir commit’in git show ile nasıl incelendiğini.

• Commit’lerin, dalların, dosyaların ve aralıkların git diff ile nasıl karşılaştırıldığını.

• HEAD~2, A..B ve A...B gibi revision adlarının nasıl çalıştığını.

• Belirli kodu ekleyen, kaldıran veya değiştiren commit’in nasıl bulunduğunu.

• Bir dosyanın yeniden adlandırmalar boyunca nasıl takip edildiğini.

• git blame komutunun sorumlu biçimde nasıl kullanıldığını.

• Yerel reflog’ların yakın zamanda hareket ettirilen referansları kurtarmaya nasıl yardımcı olabileceğini.

• Git’in kısa yardımının, manual sayfalarının, rehberlerinin ve komut keşif araçlarının nasıl kullanıldığını.

Geçmiş Bir Yedek Klasörü Değil, Commit Grafiğidir

Her normal commit; proje anlık görüntüsüne bir referans, meta veriler, bir mesaj ve bir veya daha fazla parent commit saklar.

Basit doğrusal bir geçmiş şu şekilde görünür:

A---B---C---D  main

Her commit kendi parent’ına işaret eder. Git D noktasından başlayıp C, B ve A üzerinden geriye doğru yürüyebilir.

Dallar ayrılıp daha sonra merge edildiğinde geçmiş bir grafiğe dönüşür:

A---B---C-------F  main
         \     /
          D---E    feature

Merge commit’i F iki parent’a sahiptir. Geçmiş komutları grafiği gösterebilir, tüm parent’ları izleyebilir veya seçilmiş bir dal yoluna odaklanabilir.

Bu grafik modeli, Git geçmiş araçlarının neden yalnızca commit’leri zamana göre listelemek yerine revision başlangıç noktaları ve aralıkları kabul ettiğini açıklar.

Deneme Deposu Oluşturun

Aşağıdaki depo filtreleri, dosya değişikliklerini, dallanmayı ve merge işlemlerini gösterecek kadar geçmiş oluşturur.

macOS, Linux veya Git Bash

mkdir git-history-demo
cd git-history-demo
git init -b main

cat > app.txt <<'EOF'
Task Notes
Sürüm: 1
EOF

git add app.txt
git commit -m "Task Notes uygulamasını oluştur"

cat > README.md <<'EOF'
# Task Notes

Git geçmişini uygulamak için küçük bir proje.
EOF

git add README.md
git commit -m "Proje dokümantasyonunu ekle"

cat >> app.txt <<'EOF'
Depolama: yerel dosya
EOF

git add app.txt
git commit -m "Yerel depolama modunu belgele"

git switch -c feature/search

cat > search.txt <<'EOF'
Görevleri anahtar kelimeye göre ara.
EOF

git add search.txt
git commit -m "Anahtar kelime arama açıklamasını ekle"

cat >> README.md <<'EOF'

## Arama

Görevler anahtar kelimeye göre aranabilir.
EOF

git add README.md
git commit -m "Görev aramasını belgele"

git switch main

cat >> app.txt <<'EOF'
Biçim: düz metin
EOF

git add app.txt
git commit -m "Görev depolama biçimini belgele"

git merge --no-ff feature/search -m "Görev arama özelliğini merge et"

PowerShell

New-Item -ItemType Directory git-history-demo
Set-Location git-history-demo
git init -b main

@"
Task Notes
Sürüm: 1
"@ | Set-Content app.txt

git add app.txt
git commit -m "Task Notes uygulamasını oluştur"

@"
# Task Notes

Git geçmişini uygulamak için küçük bir proje.
"@ | Set-Content README.md

git add README.md
git commit -m "Proje dokümantasyonunu ekle"

"Depolama: yerel dosya" | Add-Content app.txt
git add app.txt
git commit -m "Yerel depolama modunu belgele"

git switch -c feature/search

"Görevleri anahtar kelimeye göre ara." | Set-Content search.txt
git add search.txt
git commit -m "Anahtar kelime arama açıklamasını ekle"

@"

## Arama

Görevler anahtar kelimeye göre aranabilir.
"@ | Add-Content README.md

git add README.md
git commit -m "Görev aramasını belgele"

git switch main

"Biçim: düz metin" | Add-Content app.txt
git add app.txt
git commit -m "Görev depolama biçimini belgele"

git merge --no-ff feature/search -m "Görev arama özelliğini merge et"

Depoyu doğrulayın:

git status
git log --oneline --graph --decorate --all

git log ile Başlayın

Temel komut:

git log

Git varsayılan olarak geçerli dalın en son noktasından başlar ve ulaşılabilir parent commit’ler boyunca ilerler. Normal çıktı şunları içerir:

• Tam commit kimliği.

• Author.

• Author tarihi.

• Commit mesajı.

Git çıktıyı genellikle bir pager üzerinden gösterir. Yaygın pager tuşları:

• Space veya Page Down: İleri git.

• b: Yaygın pager’larda geri git.

• /metin: Görüntülenen çıktı içinde ara.

• n: Sonraki arama sonucuna git.

• q: Çık.

git log sonrasında terminal takılmış gibi görünüyorsa çoğu zaman pager içinde giriş bekliyordur. q tuşuna basın.

--oneline ile Kısa Geçmiş

git log --oneline

Bu komut kısaltılmış commit kimliğini ve commit başlığını kullanarak her satıra bir commit yazdırır.

Örnek:

f84b2d1 Görev arama özelliğini merge et
29d41ea Görev depolama biçimini belgele
d00394c Görev aramasını belgele
8021abc Anahtar kelime arama açıklamasını ekle
29c22f8 Yerel depolama modunu belgele
b012890 Proje dokümantasyonunu ekle
44aa731 Task Notes uygulamasını oluştur

Sizin commit kimlikleriniz farklı olacaktır.

--oneline gezinme için kullanışlıdır; ancak author, tarih, commit gövdesi ve değişen içeriği gizler. Tek geçmiş görünümü olarak değil, genel bakış amacıyla kullanın.

Dal Grafiğini Gösterin

git log --oneline --graph --decorate --all

Bu seçenekler birlikte çalışır:

• --graph, parent ilişkilerinin ASCII gösterimini çizer.

• --decorate, commit’lerin yanında dal adlarını, tag’leri ve diğer referansları gösterir.

• --all, yalnızca geçerli dal yerine tüm referanslardan başlar.

Örnek yapı:

*   f84b2d1 (HEAD -> main) Görev arama özelliğini merge et
|\
| * d00394c (feature/search) Görev aramasını belgele
| * 8021abc Anahtar kelime arama açıklamasını ekle
* | 29d41ea Görev depolama biçimini belgele
|/
* 29c22f8 Yerel depolama modunu belgele
* b012890 Proje dokümantasyonunu ekle
* 44aa731 Task Notes uygulamasını oluştur

Grafik topolojiyi gösterir. Yalnızca commit tarihleri, hangi commit’lerin diğerlerinin parent’ı olduğunu güvenilir biçimde açıklayamaz.

Commit Sayısını Sınırlayın

Son üç commit’i gösterin:

git log -3

Eşdeğer uzun biçim:

git log --max-count=3

Kısa biçimlendirmeyle birlikte kullanın:

git log -5 --oneline

Dosya ve Satır İstatistiklerini Gösterin

Değişen dosyaları ve satır sayılarını gösterin:

git log --stat

Yalnızca dosya durum kodlarını gösterin:

git log --name-status

Yaygın durum harfleri:

• A: Eklendi.

• M: Değiştirildi.

• D: Silindi.

• R: Rename algılama bunu tespit ettiğinde yeniden adlandırıldı.

Durum harfleri olmadan dosya adlarını gösterin:

git log --name-only

Seçilen her commit için tam patch gösterin:

git log -p

Depo büyükse patch çıktısını son commit’lerle sınırlandırın:

git log -p -2

Özel Log Biçimlendirmesi

Git yerleşik pretty format’lar sunar:

git log --pretty=short
git log --pretty=full
git log --pretty=fuller
git log --pretty=reference

Özel çıktı için --format kullanın:

git log --format="%h | %an | %ad | %s" --date=short

Yararlı placeholder’lar:

Placeholder	Anlamı
%H	Tam commit kimliği
%h	Kısaltılmış commit kimliği
%an	Author adı
%ae	Author e-postası
%cn	Committer adı
%ad	Author tarihi
%cd	Committer tarihi
%ar	Göreli author tarihi
%s	Commit başlığı
%b	Commit gövdesi
%d	Referans işaretleri
%P	Parent kimlikleri

Ekip kullanımına uygun yeniden kullanılabilir bir biçim:

git log --graph --date=short \
  --format="%C(auto)%h%d %s %C(dim white)(%an, %ad)%C(reset)" \
  --all

Renk placeholder’ları terminal desteğine bağlıdır. Script’lerde süslemeli ve renkli insan odaklı çıktıları parse etmeyin.

Geçmişi Tarihe Göre Filtreleyin

Belirli bir tarihten sonraki commit’leri gösterin:

git log --since="2026-01-01"

Belirli bir tarihten önceki commit’leri gösterin:

git log --until="2026-06-30"

Göreli ifadeler kullanın:

git log --since="2 weeks ago"
git log --since="yesterday"
git log --until="last month"

Tekrarlanabilir script ve raporlarda açık tarih biçimlerini tercih edin ve saat dilimi varsayımlarını doğrulayın.

Her iki sınırı birlikte kullanın:

git log --since="2026-01-01" --until="2026-03-01" --oneline

Author veya Committer’a Göre Filtreleyin

Author kimliğini arayın:

git log --author="Jane"

Değer bir pattern olarak değerlendirilir; bu nedenle adları veya e-postaları eşleştirebilir.

Committer kimliğini arayın:

git log --committer="Alex"

Rebase, patch uygulama veya cherry-pick gibi işlemlerden sonra author ve committer farklı olabilir.

Tek bir commit’in tam meta verisini inceleyin:

git log -1 --format=fuller

Commit Mesajına Göre Filtreleyin

Commit mesajlarında arama yapın:

git log --grep="search"

Büyük-küçük harf duyarsız eşleşme kullanın:

git log --grep="storage" -i

Birden fazla pattern arayın:

git log --grep="fix" --grep="bug"

Birden fazla --grep pattern’ı normalde en az biri eşleştiğinde sonuç döndürür. Komutun filtreleme kurallarına göre sağlanan tüm sınırlayıcı pattern’ların eşleşmesi gerektiğinde --all-match kullanın.

Mesaj araması yalnızca commit mesajları açıklayıcıysa faydalıdır. Belirsiz mesajlar geçmiş araştırmasını çok daha zor hale getirir.

Merge ve Merge Olmayan Commit’leri Filtreleyin

Yalnızca merge commit’lerini gösterin:

git log --merges --oneline

Merge commit’lerini hariç tutun:

git log --no-merges --oneline

First-parent yolunu izleyin:

git log --first-parent --oneline

--first-parent, integration dalında kullanışlıdır; çünkü merge edilen tüm topic dallarına girmek yerine dalın ana merge sırasını öne çıkarır.

Alttaki geçmişi silmez, yalnızca traversal’ın nasıl görüntülendiğini değiştirir.

Tek Dosya veya Dizin Geçmişini Görüntüleyin

Path öncesinde -- kullanın:

git log -- README.md

Kısa biçim:

git log --oneline -- README.md

Dosyayı etkileyen patch’leri gösterin:

git log -p -- README.md

Bir dizinin geçmişini gösterin:

git log --oneline -- src/

Çift tire, revision’lar ile path’ler arasındaki belirsizliği ortadan kaldırır.

Dosyayı Yeniden Adlandırmalar Boyunca Takip Edin

Tek bir dosya için:

git log --follow -- path/to/file

Patch’leri de ekleyin:

git log --follow -p -- path/to/file

--follow, tek dosyada yeniden adlandırma öncesindeki geçmişi sürdürmeye çalışır. Rename algılama kalıcı yeniden adlandırma meta verisi yerine benzerliğe dayanır; bu nedenle aynı anda yapılan büyük içerik değişiklikleri sonucu etkileyebilir.

Yeniden adlandırma açıksa name-status çıktısını da inceleyin:

git log --name-status --follow -- path/to/file

Geçmişi Eskiden Yeniye Doğru Gösterin

git log --reverse --oneline

Bir özelliğin ilk commit’inden itibaren nasıl oluşturulduğunu incelerken kullanışlıdır.

Bir path ile birleştirin:

git log --reverse -p -- README.md

git show ile Tek Bir Commit’i İnceleyin

git show, bir veya daha fazla Git nesnesi hakkında bilgi gösterir. Bir commit verildiğinde normalde commit mesajını ve metinsel diff’i gösterir.

Geçerli commit’i gösterin:

git show

Seçilen commit’i gösterin:

git show 29c22f8

Özet istatistikleri gösterin:

git show --stat 29c22f8

Yalnızca adları ve durumları gösterin:

git show --name-status 29c22f8

Patch olmadan meta veriyi gösterin:

git show --no-patch --format=fuller 29c22f8

Seçilen commit’te saklanan tek bir dosyayı inceleyin:

git show 29c22f8:app.txt

Bu komut dal değiştirmeden veya working tree’yi değiştirmeden tarihsel içeriği okur.

git log ve git show Farkı

Komut	Temel Amaç
git log	Commit dizisi veya grafiğinde gezinmek ve filtrelemek
git show	Seçilen nesneleri, özellikle tek commit’i ve patch’ini incelemek

İlgili commit’i bulmak için git log, ayrıntılı incelemek için git show kullanın.

git diff ile Durumları Karşılaştırın

git diff, git log komutundan farklı bir soruyu yanıtlar. İki durum arasındaki içeriği karşılaştırır.

Working Tree ile Staging Area

git diff

Bu komut unstaged değişiklikleri gösterir.

Staging Area ile HEAD

git diff --staged

Bu komut önerilen bir sonraki commit’i gösterir.

Working Tree ile HEAD

git diff HEAD

Geçerli commit’e göre staged ve unstaged farkları birleştirir.

Bir Commit ile Başka Bir Commit

git diff commitA commitB

Git iki revision’ın belirttiği anlık görüntüleri karşılaştırır.

Revision’lar Arasında Yalnızca Tek Bir Dosya

git diff commitA commitB -- README.md

Tam Patch Yerine Özet

git diff --stat commitA commitB
git diff --name-status commitA commitB

Revision Adlarını Anlayın

Birçok Git komutu revision kabul eder. Revision; dal, tag, commit kimliği, özel referans veya göreli ifade ile adlandırılabilir.

Dal ve Tag Adları

git show main
git show feature/search
git show v1.0.0

HEAD

HEAD normalde checkout edilmiş geçerli commit’i ifade eder:

git show HEAD

^ ile Parent Sözdizimi

HEAD’in ilk parent’ı:

HEAD^
HEAD^1

Bir merge commit’inin ikinci parent’ı:

HEAD^2

Merge commit’leri birden fazla parent’a sahip olduğu için ikinci parent biçimi önemlidir.

~ ile First-Parent Ataları

HEAD’den iki first-parent adımı önce:

HEAD~2

Doğrusal bir dizide HEAD^^ ve HEAD~2 aynı commit’e ulaşır. Merge geçmişlerinde tekrarlanan first-parent traversal ile belirli bir parent seçimi farklı niyetleri ifade eder.

Önceki Checkout Konumu

@{-1}

Bu ifade genellikle daha önce checkout edilmiş dalı veya commit’i belirtir ve git switch gibi komutlarla kullanışlı olabilir.

Revision Aralıkları: A..B

İki noktalı aralık:

A..B

B’den ulaşılabilen ancak A’dan ulaşılamayan commit’leri seçer.

Örnek:

git log --oneline main..feature/search

Bu soru şu anlama gelir: feature/search üzerinden ulaşılabilen ancak main üzerinde bulunmayan commit’ler hangileridir?

Aralığı ters çevirin:

git log --oneline feature/search..main

Git artık main üzerinden ulaşılabilen ancak feature dalında bulunmayan commit’leri gösterir.

Yön önemlidir.

Simetrik Fark: A...B

git log için üç noktalı gösterim:

A...B

iki taraftan birinden ulaşılabilen ancak her ikisinden de ortak olarak ulaşılamayan commit’leri seçer.

git log --left-right --oneline main...feature/search

--left-right, her commit’in hangi tarafa ait olduğunu işaretler.

Dallar ayrıştığında ve her iki taraftaki benzersiz commit’leri görmek istediğinizde kullanışlıdır.

git diff İçinde İki Nokta ve Üç Nokta Farklı Anlamlara Gelir

Revision gösterimi bağlama göre değişebilir.

Şu komut:

git diff A B

A anlık görüntüsü ile B anlık görüntüsünü karşılaştırır.

Şu biçim:

git diff A..B

git diff için temelde aynı endpoint karşılaştırmasının başka bir yazımıdır.

Ancak:

git diff A...B

A ile B’nin merge base’ini B ile karşılaştırır. Şuna benzer bir soruyu yanıtlar: sağ taraftaki dal, dallar ayrıldıktan sonra neyi değiştirdi?

Aralık sözdiziminin her komutta tamamen aynı seçme anlamına sahip olduğunu varsaymayın. Kesinlik önemli olduğunda ilgili komutun dokümantasyonunu okuyun.

Bir Metni Ekleyen veya Kaldıran Commit’i Bulun

Pickaxe seçeneği -S kullanın:

git log -S"Depolama: yerel dosya" --oneline

Bu komut, tam metnin tekrar sayısının değiştiği commit’leri arar.

Patch’leri gösterin:

git log -S"Depolama: yerel dosya" -p

Aramayı bir path ile sınırlandırın:

git log -S"Depolama: yerel dosya" -p -- app.txt

Şu soruları yanıtlarken kullanışlıdır:

• Bu fonksiyon adı ne zaman eklendi?

• Bu yapılandırma anahtarını hangi commit kaldırdı?

• Bu hata mesajı ilk kez ne zaman göründü?

-G ile Değişen Satırlarda Arama Yapın

Eklenen veya kaldırılan satırların bir regular expression ile eşleşmesi gerektiğinde -G kullanın:

git log -G"Depolama:.*dosya" --oneline -p

Pratik fark:

• -Smetin, bir string’in sayısındaki değişikliği arar.

• -Gregex, regular expression ile eşleşen eklenmiş veya kaldırılmış satırları arar.

Kod değişikliğine bağlı olarak biri diğerinin bulamadığı commit’i bulabilir. Önce yanıtlamaya çalıştığınız soruyu belirleyin, ardından patch sonuçlarını inceleyin.

Bir Fonksiyonun veya Satır Aralığının Geçmişini İzleyin

git log -L, bir dosyadaki satır aralığının veya desteklenen fonksiyon pattern’ının gelişimini takip edebilir.

Satır numarası örneği:

git log -L 1,3:app.txt

Desteklenen kaynak dilleri ve pattern’lar için fonksiyon tabanlı biçimler kullanılabilir:

git log -L :function_name:path/to/file

Her tam dosya commit’ini okumadan tek bir fonksiyonun nasıl geliştiğini araştırırken güçlü bir özelliktir.

Sözdizimi ve fonksiyon algılama hedef dosyaya ve Git’in yapılandırılmış diff driver’larına göre değişir. Tam biçimler için git help log kullanın.

git grep ile Tracked İçeriği Arayın

git grep varsayılan olarak working tree içindeki tracked dosyalarda pattern arar:

git grep "Task Notes"

Satır numaralarını gösterin:

git grep -n "Task Notes"

Tarihsel bir tree içinde arayın:

git grep "Depolama" HEAD~2

Yalnızca seçilen path’lerde arayın:

git grep -n "Arama" -- "*.md"

git grep içeriği arar. git log -S ve -G ise içerik değişikliklerinin geçmişini arar.

Satırları İzlemek İçin git blame Kullanın

Çalıştırın:

git blame app.txt

Git her satırı; o satırı en son değiştiren commit’in kimliği, author, tarih ve satır numarası gibi bilgilerle işaretler.

Sonucu belirli satırlarla sınırlandırın:

git blame -L 1,3 app.txt

Gerektiğinde yalnızca whitespace değişikliklerini yok sayın:

git blame -w app.txt

Araştırma gerektiğinde taşınmış veya kopyalanmış satırları ek seçeneklerle algılayın:

git blame -M -C app.txt

Bu seçenekler özellikle büyük geçmişlerde analizi daha maliyetli hale getirebilir.

Blame’i Karar Değil, Başlangıç Noktası Olarak Kullanın

Satırı en son değiştiren kişi davranışı tasarlayan kişi olmayabilir. Bir biçimlendirme commit’i, dosya taşıma, mekanik refactoring veya conflict çözümü en son kayıtlı değişiklik haline gelebilir.

Sorumlu bir araştırma şöyle ilerler:

1. Aday commit’i bulmak için git blame çalıştırın.

2. git show ile inceleyin.

3. Commit mesajını ve çevresindeki patch’i okuyun.

4. git log -p -- path ile daha eski dosya geçmişini kontrol edin.

5. Mevcutsa ilgili issue veya pull request’leri inceleyin.

Geçmişi kişisel suç atamak için değil, bağlamı anlamak için kullanın.

git reflog ile Yerel Referans Geçmişini İnceleyin

Dal log’ları, dal geçmişi üzerinden ulaşılabilir commit’leri gösterir. Reflog’lar ise dal uçları ve HEAD gibi yerel referansların ne zaman hareket ettiğini kaydeder.

Çalıştırın:

git reflog

Örnek yapı:

f84b2d1 HEAD@{0}: merge feature/search: Merge made by the 'ort' strategy.
29d41ea HEAD@{1}: checkout: moving from feature/search to main
d00394c HEAD@{2}: commit: Görev aramasını belgele

Reflog kayıtları şu işlemlerden sonra commit bulmaya yardımcı olabilir:

• Reset bir dalı geriye taşıdı.

• Rebase commit’leri değiştirdi.

• Bir dal yerelde silindi.

• Birkaç commit checkout edildi ve önceki konum unutuldu.

• Amend önceki commit’i değiştirdi.

Seçilen eski konumu gösterin:

git show HEAD@{2}

Başka işlem yapmadan önce recovery dalı oluşturun:

git branch recovery HEAD@{2}

Reflog’un Önemli Sınırlamaları

• Reflog’lar her repository clone’una özeldir.

• Başka bir geliştiricinin clone’u kendi reflog’larına sahiptir.

• Kayıtlar sonsuza kadar değil, expiration ve bakım politikalarına göre tutulur.

• Reflog; commit edilmiş işin, remote kopyaların veya yedeklerin yerini tutmaz.

• Commit edilmemiş dosya içeriği reflog geçmişi üzerinden otomatik olarak kurtarılamaz.

Bir commit’in unreachable hale geldiğinden şüpheleniyorsanız reflog’u hızlı biçimde kullanın.

git shortlog ile Katkıda Bulunanları Özetleyin

Commit başlıklarını author’a göre gruplayın:

git shortlog

Commit sayılarını ve author adlarını gösterin:

git shortlog -sn

E-posta adreslerini dahil edin:

git shortlog -sne

Bazı bağlamlarda çalıştırırken revision belirtin:

git shortlog -sn HEAD

Shortlog release note’ları ve katkı özetleri için kullanışlıdır; ancak kimlik farklılıkları aynı kişiyi birden fazla kayda bölebilir. Proje bilinen adları ve e-postaları normalize etmek için .mailmap dosyası kullanabilir.

git bisect ile Regression Bulun

Bir commit’in iyi, daha sonraki bir commit’in kötü olduğunu biliyorsanız git bisect geçmiş üzerinde ikili arama yapar.

Başlatın:

git bisect start

Geçerli commit’i kötü olarak işaretleyin:

git bisect bad

Bilinen daha eski bir commit’i iyi olarak işaretleyin:

git bisect good <good-commit>

Git bir orta noktayı checkout eder. Test edin ve sonucu işaretleyin:

git bisect good
# veya
git bisect bad

Git ilk kötü commit’i belirleyene kadar tekrarlayın.

Bitirin ve ilk duruma dönün:

git bisect reset

Bisect ile otomatik test komutları da kullanılabilir; ancak test güvenilir biçimde başarı veya hata exit code’u döndürmelidir.

Git’in Yerleşik Yardım Sistemini Kullanın

Git çeşitli yardım seviyeleri sunar.

Kısa Seçenek Özeti

git log -h
git diff -h
git blame -h

-h biçimi terminalde kısa kullanım özetini gösterir. Komutu hatırlayıp seçenek adını hatırlamadığınızda kullanışlıdır.

Tam Manual Sayfası

git help log
git log --help

Bu biçimler yapılandırılmış yardım görüntüleyicisini kullanarak komutun tam dokümantasyonunu açar.

Web Biçimi

git help --web log

Ortam destekliyorsa HTML manual’ın tarayıcıda açılmasını ister.

Yaygın Komutları Listeleyin

git help

Belirli bir komut verilmediğinde Git genel özeti ve sık kullanılan komutları gösterir.

Mevcut Tüm Komutları Listeleyin

git help --all

Kavramsal Rehberleri Listeleyin

git help --guides

Yararlı kavramsal dokümantasyon örnekleri:

git help revisions
git help gitrevisions
git help gitglossary
git help gitignore
git help gitattributes
git help gitcli

Yapılandırma Değişkenlerini Listeleyin

git help --config

Git yapılandırma değişkenlerinin aranabilir bir özetini verir.

Git Manual Sayfasını Okumayı Öğrenin

Bir Git manual sayfası genellikle şu bölümleri içerir:

• Name: Tek satırlık açıklama.

• Synopsis: Kabul edilen komut biçimleri.

• Description: Komutun modeli ve davranışı.

• Options: Flag’ler ve argümanlar.

• Examples: Uygulamalı birleşimler.

• Configuration: Komutu etkileyen değişkenler.

• See Also: İlgili komutlar ve rehberler.

Synopsis gösterimi yoğundur:

• [option] gibi köşeli parantezler genellikle isteğe bağlı olduğunu belirtir.

• <commit> gibi açılı parantezler sizin sağlayacağınız değeri temsil eder.

• Üç nokta tekrar veya birden fazla değer anlamına gelir.

• Dikey çizgi çoğu zaman alternatifleri gösterir.

• --, seçenekleri veya revision’ları path’lerden ayırır.

Shell açısından güvenli bir örneğin parçası olmadıkça açılı parantezleri doğrudan yapıştırmayın.

Yardım İçinde Arama Yapın

Manual pager içinde açıldığında şu biçimle arayın:

/pattern

Örnekler:

/--author
/pretty
/revision range

Yaygın pager ortamlarında sonraki sonuç için n, çıkmak için q tuşuna basın.

Bu yöntem çoğu zaman manual’ı baştan sona okumaktan daha hızlıdır.

Tahmin Etmeden Komut Keşfi

Geniş komut kategorileriyle başlayın:

git help
git help --all
git help --guides

Ardından kısa kullanımı isteyin:

git log -h

Son olarak tam dokümantasyonu açın:

git help log

Bu üç adımlı yöntem rastgele komut denemelerini azaltır.

Güvenli Geçmiş Alias’ları Oluşturun

Kısa bir grafik alias’ı tekrar tekrar yazmayı azaltabilir:

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

Ardından çalıştırın:

git lg

Daha ayrıntılı bir alias:

git config --global alias.hist \
"log --graph --date=short --format=%h%d%x20%s%x20[%an,%x20%ad] --all"

Alias’lar kolaylık sağlar, ancak alttaki komutları anlamanın yerini tutmaz. Dokümantasyon ve ekip arkadaşları genellikle standart komut adlarını kullanır.

Uygulamalı Araştırma: Bir Ayar Ne Zaman Eklendi?

Soru: Depolama: yerel dosya projeye ne zaman girdi?

1. Sayı Değişikliği Arayın

git log -S"Depolama: yerel dosya" --oneline -- app.txt

2. Aday Commit’i İnceleyin

git show <commit>

3. Yakın Dosya Geçmişini Okuyun

git log -p -- app.txt

4. Dosyanın Önceki ve Sonraki Halini İnceleyin

git show <commit>^:app.txt
git show <commit>:app.txt

Bu iş akışı yalnızca son satır atfına güvenmek yerine kanıt sunar.

Uygulamalı Araştırma: Feature Dalında Ne Değişti?

Bir dalı merge etmeden önce:

git log --oneline main..feature/search
git diff --stat main...feature/search
git diff main...feature/search

Log, feature dalına özgü commit’leri listeler. Üç noktalı diff ise main ile merge base’inden itibaren feature tarafında yapılan değişiklikleri gösterir.

Dal grafiğini de inceleyin:

git log --graph --decorate --oneline --all

Uygulamalı Araştırma: Sorunlu Satırı En Son Kim Değiştirdi?

app.txt dosyasının 3. satırının şüpheli olduğunu varsayın.

git blame -L 3,3 app.txt

Aday kimliği kopyalayın ve inceleyin:

git show <commit>

Aynı satır bölgesindeki önceki değişiklikleri arayın:

git log -p -- app.txt

Metnin kendisini arayın:

git log -S"Depolama:" -p -- app.txt

Birleşik kanıt, yalnızca blame çıktısında durmaktan daha güvenilirdir.

Uygulamalı Araştırma: reset Sonrasında Commit Kurtarmak

Yerel bir dalın geriye taşındığını ve yeni bir commit’in normal log çıktısında görünmediğini varsayın.

1. Reflog’u İnceleyin

git reflog --date=local

2. Aday Kaydı İnceleyin

git show HEAD@{1}

3. Koruyun

git branch recovery-before-reset HEAD@{1}

4. Doğrulayın

git log --oneline --graph --decorate --all

Daha fazla deneme yapmadan önce recovery dalı oluşturun. Reflog kayıtları kalıcı arşiv değildir.

Yaygın Geçmiş Hataları

git log Komutunun Depodaki Her Commit’i Gösterdiğini Sanmak

Düz git log, geçerli revision’dan başlar ve ulaşılabilir commit’leri gösterir. Diğer dallar, geçerli daldan ulaşılamayan commit’ler içerebilir. Uygun başlangıç noktalarını veya --all seçeneğini kullanın.

Geçmişi Yalnızca Tarihe Göre Okumak

Git geçmişi bir parent grafiğidir. Author tarihleri değiştirilebilir, rebase commit’leri yeniden yazabilir ve dallar çakışan zaman aralıklarına sahip olabilir.

A..B ile B..A Aralığını Karıştırmak

İki noktalı log aralığında sağ taraf dahil edilen reachability tarafıdır. Operand’ları ters çevirmek sonucu değiştirir.

Üç Noktanın Her Yerde Aynı Anlama Geldiğini Sanmak

git log A...B ile git diff A...B birbiriyle ilişkili ancak farklı soruları yanıtlar.

git blame Komutunu Suç Atamak İçin Kullanmak

Blame, geçmişe göre satırın kaynağını gösterir; sorumluluğu, tasarım sahipliğini veya niyeti göstermez.

Yalnızca Commit Mesajlarında Arama Yapmak

İlgili değişiklik kötü bir mesaja sahip olabilir. Ek kanıt olarak path filtrelerini, -S, -G, diff ve blame kullanın.

Reflog’un Her Yerde ve Sonsuza Kadar Bulunacağını Sanmak

Reflog’lar yereldir ve bakım politikalarına göre süresi dolar.

Otomasyonda İnsan Odaklı Log Çıktısını Parse Etmek

İnsan biçimleri renk, süslemeler, yerelleştirme ve değişen boşluklar içerebilir. Script’lerde bilinçli makine odaklı format ve ayırıcılar kullanın.

Pager’ı Unutmak

Çıktı donmuş gibi görünüyorsa Git’in başarısız olduğunu düşünmeden önce q tuşuna basın.

Git Geçmişini Okumak İçin En İyi Uygulamalar

• Geçerli dalı ve çalışma durumunu bilmek için git status ile başlayın.

• Dal topolojisini anlamak için grafik görünümü kullanın.

• Tam patch eklemeden önce geçmişi path, tarih, author veya mesajla sınırlandırın.

• Aday commit’leri tek tek incelemek için git show kullanın.

• Mesajlardan tahmin etmek yerine anlık görüntüleri git diff ile karşılaştırın.

• İçerik değişikliklerini araştırmak için -S ve -G kullanın.

• git blame komutunu bağlama giriş noktası olarak değerlendirin.

• Reflog değerli bir commit gösterdiğinde recovery dalı oluşturun.

• İlgisiz örneklerden yıkıcı komutlar kopyalamadan önce yerleşik yardımı kullanın.

• Gelecekteki araştırmaları hızlandırmak için açık commit mesajları yazın.

Geçmiş Komutları Referansı

Komut	Amacı
git log	Geçerli revision’dan commit geçmişinde yürümek
git log --oneline	Kısa commit listesi göstermek
git log --graph --decorate --all	Depo topolojisini ve referansları görüntülemek
git log -p	Seçilen commit’lerin patch’lerini göstermek
git log --stat	Dosya ve satır istatistiklerini göstermek
git log -- path	Geçmişi bir path ile sınırlandırmak
git log --follow -- file	Tek dosyayı yeniden adlandırmaların ötesinde takip etmeye çalışmak
git log --author="name"	Author kimliğine göre filtrelemek
git log --grep="text"	Commit mesajı pattern’ına göre filtrelemek
git log -S"text" -p	String sayısının değiştiği commit’leri bulmak
git log -G"regex" -p	Pattern ile eşleşen değişmiş satırlara sahip commit’leri bulmak
git show revision	Seçilen nesneyi veya commit’i incelemek
git diff A B	İki anlık görüntüyü karşılaştırmak
git blame file	Satırları en son değiştiren commit’lerle işaretlemek
git reflog	Yerel referans hareketlerini göstermek
git shortlog -sn HEAD	Commit sayılarını author’a göre özetlemek
git grep -n "text"	Tracked içerikte arama yapmak
git bisect start	İkili arama ile regression araştırmasını başlatmak

Yardım Komutları Referansı

Komut	Amacı
git command -h	Kısa kullanım ve seçenek özetini göstermek
git help command	Tam komut manual’ını açmak
git command --help	Aynı tam komut dokümantasyonunu açmak
git help --web command	HTML dokümantasyonu istemek
git help	Yaygın komutları ve genel özeti göstermek
git help --all	Mevcut komutları listelemek
git help --guides	Kavramsal rehberleri listelemek
git help --config	Yapılandırma değişkenlerini listelemek
git help revisions	Revision ve aralık sözdizimi dokümantasyonunu okumak
git help gitglossary	Git terminolojisi tanımlarını okumak

Geçmiş Araştırması Kontrol Listesi

Bir değişikliği araştırırken şunları sorun:

• Geçmiş hangi dal veya revision’dan başlamalı?

• Tüm dallara mı, yalnızca geçerli daldan ulaşılabilen commit’lere mi ihtiyacım var?

• Arama path ile sınırlandırılabilir mi?

• Mesaj, author, tarih, tam string veya değişen satır pattern’ı mı arıyorum?

• Commit listesine mi, anlık görüntü karşılaştırmasına mı ihtiyacım var?

• Merge commit’leri dahil edilmeli mi?

• Dosya yeniden adlandırılmış olabilir mi?

• Blame yalnızca mekanik veya biçimlendirme değişikliğini mi gösteriyor?

• Eksik yerel commit reflog içinde hâlâ görünüyor olabilir mi?

• Daha fazla geçmiş yazma komutu çalıştırmadan önce aday commit’i korudum mu?

Sık Sorulan Sorular

git log Başka Bir Daldaki Commit’i Neden Göstermiyor?

Düz git log, geçerli başlangıç revision’ından ulaşılabilen commit’leri gösterir. Diğer dal adını doğrudan kullanın veya --all ekleyin.

git log ile git reflog Arasındaki Fark Nedir?

git log commit ancestry’si boyunca ilerler. git reflog ise HEAD ve dal uçları gibi yerel referansların hareketlerini kaydeder.

Tek Bir Commit’in Neyi Değiştirdiğini Nasıl Görürüm?

git show <commit> çalıştırın. Özet için --stat, değişen path’ler için --name-status ekleyin.

Bir Dosyanın Eski Commit’teki Halini Nasıl Görürüm?

git show <commit>:path/to/file kullanın.

Bir Fonksiyonun Ne Zaman Eklendiğini Nasıl Bulurum?

git log -S"functionName" -p -- path deneyin. Değişen satırlar üzerinde regular expression daha uygunsa -G kullanın.

git diff Neden Hiçbir Şey Göstermiyor?

Karşılaştırdığınız durumlar aynı olabilir veya değişiklikler stage edilmiş olabilir. Staged içerik için git diff --staged, tarihsel karşılaştırmalar için revision belirtin.

HEAD~3 Ne Anlama Gelir?

HEAD’den first parent üç kez izlenerek ulaşılan commit’i ifade eder.

main..feature Ne Anlama Gelir?

Log traversal için feature üzerinden ulaşılabilen ancak main üzerinden ulaşılamayan commit’leri seçer.

git blame Yeniden Adlandırılmış Dosyaları Takip Edebilir mi?

Blame, taşınmış ve kopyalanmış satırları algılamak için seçeneklere sahiptir; ancak tarihsel araştırma çoğu zaman blame’i git log --follow, git show ve path geçmişiyle birleştirerek daha iyi çalışır.

Reflog Commit Edilmemiş Değişiklikleri Kurtarabilir mi?

Güvenilir biçimde hayır. Reflog referans hareketlerini izler. Esas olarak yerelde var olmuş commit ve referans konumları için kullanışlıdır.

Önce Hangi Yardım Komutunu Kullanmalıyım?

Hızlı seçenek hatırlatması için git command -h kullanın. Tam davranış, sözdizimi veya yapılandırma ayrıntıları için git help command kullanın.

Sonuç

Git geçmişi, kanıt olarak ele alındığında en yararlı haline gelir. Kısa log yön bulmanızı sağlar, grafik ancestry’yi açıklar, filtreler gürültüyü azaltır, git show tek tek commit’leri gösterir ve git diff tam anlık görüntüleri karşılaştırır.

Daha derin araştırmalarda revision aralıkları dal farklarını açıklar, -S ve -G içerik değişikliklerini bulur, dosya geçmişi gelişimi izler, blame aday kaynak bilgisi sunar ve reflog yakın zamanda hareket ettirilmiş yerel referansları gösterebilir.

Her seçeneği ezberlemeniz gerekmez. Git’in yerleşik yardım sistemi iş akışının bir parçasıdır. Hatırlatmalar için kısa yardımı, kesin davranış için tam manual’ları, revision sözdizimi veya komut modelleri belirsiz olduğunda kavramsal rehberleri kullanın.

Bir sonraki makale Git dalları ve merge işlemlerine odaklanacaktır. Dal oluşturma, geçiş, fast-forward ve three-way merge, merge conflict’leri, dal temizleme ve uygulamalı integration iş akışları ele alınacaktır.

Resmî Kaynaklar ve Ek Okumalar

• Resmî git-log Belgeleri

• Resmî Pretty Formats Belgeleri

• Resmî git-show Belgeleri

• Resmî git-diff Belgeleri

• Resmî gitrevisions Belgeleri

• Resmî git-blame Belgeleri

• Resmî git-reflog Belgeleri

• Resmî git-grep Belgeleri

• Resmî git-bisect Belgeleri

• Resmî git-help Belgeleri

• Pro Git: Commit Geçmişini Görüntülemek

• Pro Git: Revision Seçimi

• Pro Git: Arama

• Pro Git: Git ile Hata Ayıklama