Git Status, Log ve Diff ile Değişiklikleri İnceleme
Yıllar önce bir prodüksiyon sunucusunda “az önce ne değiştirdim ki?” diye saatlerce ekrana baktığımı hatırlıyorum. O dönemde git’i yeni öğreniyordum ve değişiklikleri takip etmek için hâlâ eski alışkanlıklarla, dosyaları elle karşılaştırıyordum. Sonra birisi bana git diff komutunu gösterdi ve o andan itibaren hayatım değişti. Abartmıyorum. Bu yazıda, git’in en temel ama en güçlü araçlarından üçünü, yani status, log ve diff komutlarını gerçek dünya senaryolarıyla ele alacağız.
Git Status: Şu An Ne Oluyor?
git status komutu, çalışma dizinizin anlık görüntüsünü verir. Hangi dosyalar değiştirilmiş, hangileri sahneye (staging area) alınmış, hangileri henüz takip edilmiyor? Bunların hepsini tek komutla görebilirsiniz.
git status
Tipik bir çıktı şöyle görünür:
On branch main
Your branch is up to date with 'origin/main'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: config/nginx.conf
new file: scripts/deploy.sh
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
modified: src/app.py
Untracked files:
(use "git add <file>..." to include in what will be committed)
logs/debug.log
Bu çıktıyı okumayı öğrenmek, git’in mantığını kavramak demektir. Üç farklı alan var burada:
- Changes to be committed: Staging area’ya eklenmiş, bir sonraki commit’e dahil edilecek dosyalar
- Changes not staged for commit: Değiştirilmiş ama henüz sahneye alınmamış dosyalar
- Untracked files: Git’in hiç takip etmediği yeni dosyalar
Kısa Çıktı ile Hızlı Bakış
Büyük projelerde git status çıktısı çok uzun olabilir. Kısa format için -s veya --short parametresini kullanın:
git status -s
M config/nginx.conf
A scripts/deploy.sh
M src/app.py
?? logs/debug.log
Buradaki iki sütuna dikkat edin. Sol sütun staging area’daki durumu, sağ sütun çalışma dizinindeki durumu gösterir. M modified, A added, ?? untracked demektir.
Branch Bilgisini Görmek
Uzak dal ile aranızdaki farkı görmek için --branch veya -b parametresini ekleyin:
git status -sb
Bu özellikle birden fazla branch ile çalışırken hangi dalda olduğunuzu ve uzak sunucudan ne kadar geride ya da ileride olduğunuzu anlamak için kullanışlıdır.
Git Log: Geçmişi Okumak
git log komutu, commit geçmişini görüntüler. Ama sadece git log yazmak çoğu zaman yeterli olmaz. Gerçek gücü, çeşitli parametreleriyle ortaya çıkar.
Temel Kullanım
git log
Her commit için hash, yazar, tarih ve mesajı gösterir. Ancak büyük projelerde bu çıktı çok uzun olabilir. q tuşuyla çıkabilirsiniz.
Tek Satır Format
Günlük işlerimde en sık kullandığım format budur:
git log --oneline
a3f9d12 Fix nginx upstream timeout değerleri
8bc1e45 Deploy script'e rollback fonksiyonu eklendi
2de7891 PostgreSQL bağlantı havuzu ayarları güncellendi
f4a8c23 Yeni monitoring endpoint'leri eklendi
Her commit tek satırda, kısa hash ve mesajla görünür. Hızlı tarama için ideal.
Görsel Dal Yapısı
Birden fazla branch ve merge işlemiyle çalışıyorsanız, dal yapısını görselleştirmek çok işe yarar:
git log --oneline --graph --all
* a3f9d12 (HEAD -> main, origin/main) Fix nginx upstream timeout
| * 7f2e890 (feature/monitoring) Prometheus metrikleri eklendi
|/
* 8bc1e45 Deploy script rollback eklendi
* 2de7891 PostgreSQL bağlantı havuzu güncellendi
Bu görünüm, hangi commit’in hangi daldan geldiğini, merge noktalarını ve dal ayrışmalarını net biçimde gösterir.
Belirli Parametrelerle Filtreleme
Gerçek dünyada “şu kişinin geçen hafta ne değiştirdiğini bul” gibi talepler çok gelir. Bunun için:
# Son 5 commit
git log --oneline -5
# Belirli bir yazar
git log --oneline --author="Ahmet Yilmaz"
# Belirli bir tarih aralığı
git log --oneline --after="2024-01-01" --before="2024-02-01"
# Commit mesajında arama
git log --oneline --grep="nginx"
Log ile Dosya Geçmişi
Bir dosyanın tarihsel değişimini takip etmek istiyorsanız:
git log --oneline -- config/nginx.conf
Bu komut, sadece o dosyayı etkileyen commit’leri listeler. Bir konfigürasyon dosyasında sorun çıktığında, “bu dosyaya kim ne zaman ne dokundu?” sorusuna dakikalar içinde cevap bulabilirsiniz.
Detaylı Stat Bilgisi
Hangi dosyalarda kaç satır değiştiğini görmek için:
git log --stat --oneline -3
a3f9d12 Fix nginx upstream timeout değerleri
config/nginx.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
8bc1e45 Deploy script'e rollback fonksiyonu eklendi
scripts/deploy.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
Bu format, büyük commit’leri tespit etmek için de kullanışlıdır. Bir commit’te binlerce satır değişmişse, o commit’e dikkatli bakmak gerekir.
Git Diff: Farkı Görmek
git diff, iki şey arasındaki farkı satır satır gösterir. Hangi iki şey? Bu, nasıl kullandığınıza bağlıdır.
Çalışma Dizini ile Staging Arasındaki Fark
Parametresiz git diff, staging area’ya alınmamış değişiklikleri gösterir:
git diff
diff --git a/src/app.py b/src/app.py
index 8a3f9d1..b2c4e78 100644
--- a/src/app.py
+++ b/src/app.py
@@ -45,7 +45,9 @@ def connect_database():
host = config.get('DB_HOST', 'localhost')
port = config.get('DB_PORT', 5432)
- timeout = 30
+ timeout = 60
+ retry_count = 3
+ retry_delay = 5
return psycopg2.connect(host=host, port=port, connect_timeout=timeout)
Çıktıyı okumayı öğrenmek önemli. - ile başlayan satırlar silinen, + ile başlayan satırlar eklenen kısımlardır. @@ ile başlayan satır ise değişikliğin hangi satır numarasında olduğunu gösterir.
Staging Area ile Son Commit Arasındaki Fark
git add ile sahneye aldıktan sonra commit etmeden önce bir kez daha kontrol etmek iyi bir alışkanlıktır:
git diff --staged
ya da eşdeğeri:
git diff --cached
Bu komut, “commit etmek üzere olduğum değişiklikler neler?” sorusuna cevap verir. Yanlış bir şeyi commit etmeden önce son kontrol noktanız.
İki Commit Arasındaki Fark
Zaman içindeki değişimi görmek için iki commit hash’ini karşılaştırabilirsiniz:
git diff a3f9d12 8bc1e45
Ya da HEAD göreceli:
# Son commit ile önceki arasındaki fark
git diff HEAD~1 HEAD
# 3 commit öncesi ile şimdiki arasındaki fark
git diff HEAD~3 HEAD
Belirli Bir Dosya için Diff
Büyük projelerde tüm fark çıktısı çok gürültülü olabilir. Belirli bir dosyaya odaklanmak için:
git diff HEAD~1 HEAD -- config/nginx.conf
Bu komut gerçek hayatta çok işe yarar. Bir deployment sonrası sorun çıktığında “konfigürasyonda ne değişti?” sorusuna anında cevap verir.
Branch’ler Arası Fark
İki dal arasındaki farkı görmek için:
git diff main feature/monitoring
Bu komutu özellikle code review öncesinde kullanıyorum. Feature branch’i main’e merge etmeden önce tüm farkı bir kez daha gözden geçirmek, beklenmedik değişiklikleri yakalamak için değerli bir adım.
Diff Stat ile Özet Görünüm
Tam diff çıktısı yerine sadece hangi dosyaların değiştiğini ve ne kadar değiştiğini görmek için:
git diff --stat HEAD~5 HEAD
config/nginx.conf | 4 ++--
scripts/deploy.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
src/app.py | 12 ++++++------
3 files changed, 53 insertions(+), 8 deletions(-)
Gerçek Dünya Senaryoları
Senaryo 1: Prodüksiyon Sorunu Sonrası Analiz
Sabah 3’te prodüksiyon alarm verdi. Sorun giderildikten sonra “tam olarak ne değişmişti?” diye bakmanız gerekiyor. İşte bu durumda kullandığım akış:
# Son 10 commit'i görüntüle
git log --oneline -10
# Şüpheli commit'teki değişiklikleri görüntüle
git show a3f9d12
# Sadece o commit'te değişen dosyaları listele
git diff --name-only HEAD~1 HEAD
# Belirli bir konfigürasyon dosyasının son değişimini bul
git log --oneline -p -- config/nginx.conf | head -50
git show komutu özellikle değerlidir. Tek bir commit’in hem mesajını hem de tüm değişikliklerini gösterir.
Senaryo 2: Deployment Öncesi Kontrol
Bir deployment öncesi standart kontrol rutinini şöyle kurabilirsiniz:
# Hangi dosyalar değişmiş?
git status -s
# Staging area'daki değişiklikleri gözden geçir
git diff --staged
# Son commit'ten bu yana ne değişti?
git diff HEAD
# Bu deployment'ta kaç dosya, kaç satır değişecek?
git diff --stat origin/main HEAD
Bu rutini ekibe alışkanlık haline getirmek, “yanlışlıkla test config’ini prodüksiyona atmak” gibi klasik hataları önler.
Senaryo 3: Kimse Hatırlamıyor, Git Hatırlıyor
“Bu satır neden böyle yazılmış?” sorusu varsa, git log ile birleşik arama yapabilirsiniz:
# Belirli bir string'in ne zaman eklendiğini bul
git log --all -S "retry_count = 3" --oneline
# Bir regex pattern'i ne zaman değiştirildi?
git log --all -G "timeouts*=s*[0-9]+" --oneline -p
-S parametresi bir string’in eklendiği veya silindiği commit’leri, -G ise bir regex pattern’iyle eşleşen değişiklikleri bulur. Kod arkeolojisi için biçilmiş kaftan.
Senaryo 4: İki Ortam Arasındaki Konfigürasyon Farkı
Staging ve prodüksiyon ortamlarının konfigürasyonunu ayrı branch’lerde tutuyorsanız, aralarındaki farkı takip etmek kolaylaşır:
# Staging'de olan ama prodüksiyonda olmayan değişiklikler
git diff production..staging -- config/
# Her iki tarafta da değişmiş dosyaları listele
git diff --name-only production..staging
Log ve Diff’i Birleştirmek
Bu iki komut birlikte kullanıldığında gerçek gücünü gösterir. Örneğin, bir dosyanın belirli bir commit’te nasıl göründüğünü almak için:
# Belirli bir commit'teki dosyanın içeriği
git show a3f9d12:config/nginx.conf
# Commit geçmişini diff'le birlikte göster
git log -p --follow -- scripts/deploy.sh
--follow parametresi, dosya yeniden adlandırılmış olsa bile geçmişi takip eder.
Faydalı Alias’lar
Sık kullandığım komutlar için .gitconfig dosyama şu alias’ları ekliyorum:
git config --global alias.st "status -sb"
git config --global alias.lg "log --oneline --graph --all -15"
git config --global alias.df "diff --staged"
git config --global alias.last "log -1 HEAD --stat"
Artık git st, git lg, git df ve git last ile hızlıca ilerliyorum. Özellikle git lg alias’ı, hangi branch’te ne olduğunu anlık görsel olarak kavramak için günlük rutinimin vazgeçilmezi oldu.
Renkli ve Okunabilir Diff Çıktısı
Git’in varsayılan diff çıktısı bazen gözü yorabilir. Satır bazlı yerine kelime bazlı diff için:
git diff --word-diff
[-timeout = 30-]{+timeout = 60+}
Konfigürasyon dosyalarındaki küçük değişiklikleri takip ederken bu format çok daha okunabilir olur.
Renk ayarlarını global olarak açmak için:
git config --global color.ui auto
Bu ayar, tüm git komutlarının çıktısını terminal renkleriyle daha okunabilir hale getirir.
Önemli Parametreler Özeti
git status parametreleri:
- -s, –short: Kısa format, her dosya tek satırda
- -b, –branch: Branch bilgisini kısa formatla birlikte göster
- -u, –untracked-files: Takip edilmeyen dosyaları nasıl göstereceğini ayarla
git log parametreleri:
- –oneline: Her commit tek satırda
- –graph: ASCII dal grafiği göster
- –all: Tüm branch’leri dahil et
- –stat: Her commit’teki dosya değişim istatistiklerini göster
- -p: Her commit’in tam diff’ini göster
- –author: Belirli bir yazara göre filtrele
- –grep: Commit mesajında metin ara
- -S: Eklenen veya silinen belirli bir string’i ara
- –follow: Dosya yeniden adlandırılmış olsa bile geçmişi takip et
git diff parametreleri:
- –staged, –cached: Staging area ile son commit arasındaki fark
- –stat: Satır bazlı diff yerine istatistik özeti
- –name-only: Sadece değişen dosya adlarını listele
- –word-diff: Satır bazlı yerine kelime bazlı diff
- HEAD~n: n commit öncesine göreceli referans
Sonuç
git status, git log ve git diff üçlüsü, git dünyasındaki “ne oluyor?” sorusunun cevabıdır. Çoğu sysadmin ve DevOps mühendisi bu komutları yüzeysel kullanır, oysa gerçek güç parametrelerde ve kombinasyonlarda gizlidir.
Bu komutları günlük rutininize dahil edin. Deployment öncesi git diff --staged ile son kontrol, deployment sonrası git log --stat -5 ile hızlı özet, bir sorun çıktığında git log -p -- ile ayrıntılı araştırma. Bu alışkanlıklar zamanla ikinci doğanız haline gelir ve “az önce ne değiştirdim ki?” sorusunu bir daha sormazsınız.
Git’in gücü, geçmişin her anına ulaşabilmekte yatar. O geçmişi okumayı öğrenmek ise her sistem yöneticisinin temel becerisi olmalıdır.
