git log, diff, show ve blame: Git'te proje geçmişi nasıl okunur?

Dört komut, proje geçmişiyle ilgili soruların neredeyse tamamını karşılar. git log «ne oldu» sorusunu, git diff «tam olarak ne değişti» sorusunu, git show «belirli bir commit'in içinde ne var» sorusunu, git blame ise «bu satırı kim ve ne zaman yazdı» sorusunu yanıtlar. Aşağıda her biri için günlük geliştirmede gerçekten kullanılan bayraklarla birlikte pratik teknikler var.

git log: commit listesi

Argümansız git log, mevcut branch'in commit'lerini yeniden eskiye doğru listeler: tam SHA-1 hash, yazar, tarih ve mesaj. Çıktı bir pager'da (genellikle less) açılır: boşluk — sonraki sayfa, /metin — arama, q — çıkış.

commit 7be41d0c9a2e4f1b8d6c3e5a7f9b0c2d4e6f8a1b
Author: Anna Petrova <anna@example.com>
Date:   Mon Oct 5 14:22:10 2026 +0300

    feat: API yanıtlarını önbelleğe alma

Hash'i tamamen kopyalamanıza gerek yok: Git, 4 karakterden başlayan herhangi bir benzersiz öneki anlar; pratikte 7 karakter yeterlidir.

Kompakt çıktı: git log --oneline

git log --oneline -10
# 7be41d0 (HEAD -> main, origin/main) feat: API yanıtlarını önbelleğe alma
# 1c02e8f fix: istek zaman aşımı
# 9a4b3c2 refactor: istemciyi modüle taşıdım

-10 bayrağı (veya -n 10) commit sayısını sınırlar. Parantez içinde işaretçiler vardır: HEAD'in, yerel ve uzak branch'lerin ve tag'lerin nerede olduğu.

Branch grafiği: git log --graph

«git graph» araması genellikle tam olarak bunu kasteder: dallanmaların ve merge'lerin doğrudan terminalde görselleştirilmesi.

git log --oneline --graph --all
# * 3e1f0aa (feature/auth) feat: token ile giriş
# | * 7be41d0 (HEAD -> main) feat: API yanıtlarını önbelleğe alma
# |/
# * 1c02e8f fix: istek zaman aşımı
# *   5d2c7b1 Merge branch 'feature/search'
# |\
# | * 8f3a9e0 feat: arama
# |/
# * 9a4b3c2 refactor: istemciyi modüle taşıdım

--all yalnızca mevcut branch'i değil, tüm branch'leri gösterir. Bir alias tanımlamak kullanışlıdır: git config --global alias.lg "log --oneline --graph --all --decorate"; bundan sonra git lg yeterlidir.

Özel format: --pretty=format

git log --pretty=format:"%h %ad %an %s" --date=short
# 7be41d0 2026-10-05 Anna Petrova feat: API yanıtlarını önbelleğe alma

Temel yer tutucular: %h — kısa hash, %H — tam hash, %an — yazar, %ae — yazarın e-postası, %ad — yazar tarihi, %ar — göreli tarih («2 days ago»), %s — mesaj başlığı.

git log'da geçmiş nasıl filtrelenir?

Yazara ve tarihe göre

git log --author="Anna"
git log --since="2 weeks ago" --until="2026-10-01"
git log --since=yesterday --oneline

--author bir düzenli ifade alır ve ad ile e-postada arar. Git tarihleri hem serbest biçimde hem ISO biçiminde anlar.

Mesaj metnine göre

git log --grep="fix" -i --oneline

-i aramayı büyük/küçük harfe duyarsız yapar. Ekibiniz mesajlara görev numaralarını yazıyorsa, bir göreve ait tüm commit'ler bu şekilde hızla bulunur.

Dosyaya veya klasöre göre

git log --oneline -- src/api/client.py
git log --follow -p -- src/api/client.py

Çift tire, yolları branch'lerden ayırır. --follow, dosya geçmişini yeniden adlandırmalar boyunca sürdürür (tek dosya için çalışır), -p her commit'in patch'ini gösterir.

Değişen koda göre: «pickaxe» araması

git log -S "retry_count" --oneline     # dizenin geçme sayısının değiştiği commit'ler
git log -G "timeout\s*=" --oneline    # diff'inde regex'e uyan satırlar olan commit'ler

-S, bir fonksiyonun veya değişkenin eklendiği ya da silindiği commit'i bulur; bir kod parçasının nereye kaybolduğunu anlamanız gerektiğinde vazgeçilmezdir.

Commit aralıkları

git log main..feature      # feature'da olup main'de olmayanlar
git log origin/main..HEAD  # henüz gönderilmemiş yerel commit'lerim
git log --no-merges        # merge commit'leri hariç
git log --stat             # hangi dosyalar ve kaç satır değişti

git diff: tam olarak ne değişti?

git diff hakkında anlaşılması gereken en önemli şey, hangi iki durumu karşılaştırdığıdır. Buradaki karışıklık, «her şeyi değiştirdim, diff neden boş?» sorusunun sebebidir.

git add yaptıysanız normal git diff boş olur; değişiklikler artık index'tedir, --staged'e bakın. Hiç eklenmemiş yeni dosyaları diff hiç göstermez.

diff çıktısı nasıl okunur?

diff --git a/config.py b/config.py
index 3b18e51..a1c4f02 100644
--- a/config.py
+++ b/config.py
@@ -10,7 +10,7 @@ DEFAULTS = {
     "host": "localhost",
-    "timeout": 5,
+    "timeout": 30,
     "retries": 3,

- ile başlayan satırlar silinmiş, + ile başlayanlar eklenmiştir; geri kalanı bağlamdır. @@ -10,7 +10,7 @@ başlığı şu anlama gelir: parça 10. satırdan başlar ve eski ve yeni sürümlerde 7 satır kaplar.

Kullanışlı git diff bayrakları

git diff --stat main feature      # dosya bazında özet
git diff --name-only HEAD~3       # yalnızca değişen dosyaların adları
git diff --word-diff               # kelime bazında değişiklikler, metinler için kullanışlı
git diff -w                        # boşluk değişikliklerini yok say
git diff main feature -- src/      # bir klasörle sınırla

Her commit'ten önce git diff --staged'e bakmak faydalıdır: hata ayıklama için bırakılmış bir print'i veya yanlışlıkla eklenmiş bir dosyayı fark etmek için son şanstır.

git show: tek bir commit'in tamamı

git show, commit'in meta verilerini ve parent'ına göre diff'ini gösterir. Argümansız — son commit.

git show 7be41d0
git show HEAD~2 --stat           # patch olmadan, yalnızca özet
git show v1.2.0                  # tag: açıklama ve commit
git show main:src/config.py      # dosyanın commit'teki hali

Son biçim olan <revizyon>:<yol> özellikle kullanışlıdır: bir dosyanın eski sürümünü ona geçmeden görüntüleyebilirsiniz. Çıktıyı bir dosyaya yönlendirirseniz, silinmiş içeriği checkout yapmadan geri yüklersiniz.

git blame: bu satırı kim değiştirdi?

git blame dosya, her satır için onu en son değiştiren commit'i, yazarı ve tarihi gösterir. Adı suçlayıcı gelse de aslında bağlam bulma aracıdır: commit'i bulmak, mesajını okumak ve neden böyle yapıldığını anlamak için.

git blame -L 40,60 src/api/client.py
# 1c02e8f3 (Anna Petrova 2026-09-28 11:04:51 +0300 41)     timeout = settings.timeout
# 9a4b3c2e (Ivan Smirnov 2026-09-14 18:30:02 +0300 42)     session = build_session()

• -L 40,60 — yalnızca bir satır aralığı; -L :fonksiyon_adi da kullanılabilir.
• -w — boşluk değişikliklerini yok say, böylece biçimlendirme commit'lerine takılmazsınız.
• -C — başka dosyalardan taşınan satırları izle.
• --ignore-rev <hash> veya .git-blame-ignore-revs dosyası — otomatik biçimlendirme gibi toplu commit'leri atla.

Tipik bir inceleme senaryosu: git blame commit'i bulur, git show onu bütünüyle gösterir, dosyaya göre git log ise komşu değişiklikleri verir.

Geçmişte gezinme: HEAD~ ve HEAD^

Commit'lere yalnızca hash'lerle değil başka yollarla da başvurulabilir. HEAD~1 mevcut commit'in parent'ı, HEAD~3 ise üç nesil öncesidir. HEAD^2, bir merge commit'in ikinci parent'ıdır. Branch, tag ve uzak branch adları da çalışır: origin/main~2. Projenin tamamını eski bir commit'te görmek için git switch --detach <hash>, geri dönmek için git switch - kullanılır.

İyi ve kötü geçmiş

Bu komutların hepsi, geçmiş ne kadar anlamlıysa o kadar faydalıdır. «fix», «wip», «biraz daha düzeltme» gibi mesajlar git log --grep ve git blame'i işe yaramaz hale getirir. İyi bir commit, tek bir mantıksal değişiklik ve neyin ve neden yapıldığını açıklayan bir başlıktır: fix: yavaş gateway nedeniyle API zaman aşımı 30 sn'ye çıkarıldı. Altı ay sonra blame tam olarak böyle bir commit'i bulur ve size bir saat kazandırır.

Uygulama: bir hatayı geçmiş üzerinden araştırmak

Diyelim ki son sürümden sonra API istekleri zaman aşımıyla düşmeye başladı. Komutların birlikte kullanımı birkaç dakikada nedene şöyle ulaştırır.

1. Sürüme neyin girdiğine bakıyoruz: git log v1.4.0..v1.5.0 --oneline. Liste kısa, ama başlıklardan suçlu belli değil.
2. Dosyaya göre daraltıyoruz: git log v1.4.0..v1.5.0 --oneline -- src/api/. İki commit kalıyor.
3. Kodda arıyoruz: git log -S "timeout" --oneline -- src/api/, zaman aşımı değerinin değiştiği commit'i buluyor.
4. Onu bütünüyle görüntülüyoruz: git show 1c02e8f. Diff'te zaman aşımının 30'dan 5 saniyeye düşürüldüğü, mesajda ise açıklamanın «UI tepkisini hızlandırıyoruz» olduğu görülüyor.
5. Bu satıra başka kimin dokunduğunu kontrol ediyoruz: git blame -L :build_session src/api/client.py.

Bundan sonrası mühendislik kararıdır: değeri geri almak, zaman aşımını ayarlara taşımak veya commit'i git revert ile geri almak. Commit sayısı yüzlerceyse ve suçluyu gözle bulmak imkânsızsa, yardıma git bisect gelir: geçmişte ikili arama yapar ve birkaç adımda davranışı bozan commit'i gösterir.

Hayatı kolaylaştıran ayarlar

git config --global log.date iso            # log'da tarih biçimi
git config --global diff.colorMoved zebra   # diff'te taşınan satırları vurgula
git config --global core.pager "less -FRX"  # kısa çıktı için pager açma

Çıktıyı bir betikle işlemeniz gerekiyorsa renkleri ve pager'ı kapatın: git --no-pager log --format="%H %s" --no-color. Makine işlemesi için tam hash %H kullanın: kısa önekler büyük bir repository'de zamanla belirsiz hale gelebilir.

Özet

--oneline, --graph, --author, -S filtreleri ve yollarla git log «ne oldu» sorusunu yanıtlar. git diff çalışma klasörünü, index'i ve commit'leri karşılaştırır; asıl önemli olan, varsayılan olarak neyi karşılaştırdığını hatırlamaktır. git show tek bir commit'i veya bir dosyanın eski sürümünü açar, git blame ise bir kod satırından onu doğuran karara götürür. Geçmişi okumak ve commit'ler arasında gezinmek Git kursunda uygulamalı olarak ele alınıyor.