Git’i Doğru Kullanmak: Commit Mesajları, Branch Stratejisi ve Temiz Geçmiş

Git Sadece Yedekleme Aracı Değildir

Git’i yeni öğrenen birçok kişi onu ilk başta “kodları kaydedip GitHub’a göndermek” gibi görür. Bu bakış yanlış değil ama eksiktir. Evet, Git kodu saklar. Evet, GitHub veya GitLab gibi platformlarla uzaktaki bir depoya gönderebilirsin. Ama Git’in asıl gücü, projenin geçmişini anlamlı bir şekilde tutmasındadır.

İyi kullanılmış bir Git geçmişi sana şunu söyler: Bu özellik ne zaman eklendi? Bu hata ne zaman düzeltildi? Bu dosya neden değişti? Bu satırı kim, hangi amaçla yazdı? Bir şey bozulduysa hangi commit’ten sonra bozulmuş olabilir?

Kötü kullanılmış bir Git geçmişi ise çoğu zaman sadece şunu söyler: “fix”, “update”, “son hali”, “deneme”, “final”, “final2”. Böyle bir geçmiş, teknik olarak commit içerir ama bilgi taşımaz. Dosyalar kaydedilmiştir; fakat projenin hikayesi kaybolmuştur.

Kötü Git Alışkanlıkları

Git kullanırken en yaygın kötü alışkanlıklardan biri, her değişikliği topluca sahneye alıp anlamsız bir mesajla commit etmektir. Bu genellikle şu döngüye benzer:

git add .
git commit -m "fix"
git push

Buradaki sorun sadece git add . kullanılması değildir. Bazen bu komut gayet işe yarar. Asıl sorun, neyi eklediğini kontrol etmeden her şeyi commit’e almak ve commit mesajının hiçbir şey anlatmamasıdır.

Örneğin aynı commit içinde hem login hatasını düzeltiyor, hem CSS değiştiriyor, hem gereksiz dosya siliyor, hem de rapor ekranına yeni özellik ekliyorsan; o commit ileride okunabilir bir kayıt olmaktan çıkar. Bir şey bozulduğunda hangi değişikliğin sebep olduğunu bulmak zorlaşır.

İyi Commit Nasıl Olmalı?

İyi commit küçük, odaklı ve açıklayıcıdır. Tek bir mantıksal değişikliği anlatır. Mesajı okuyan kişi, diff’e bakmadan önce kabaca ne değiştiğini anlayabilmelidir.

İyi commit şu iki soruya cevap verir: Ne değişti? ve mümkünse neden değişti? Her commit roman gibi uzun olmak zorunda değildir. Ama mesaj, gelecekteki geliştiriciye bir ipucu bırakmalıdır.

Commit Mesajı Formatı: Ne Değişti, Neden Değişti?

Commit mesajı için çok karmaşık bir formata gerek yok. Küçük projelerde sade Türkçe cümleler bile yeterli olabilir. Önemli olan mesajın anlamlı olmasıdır.

git commit -m "Login formundaki boş şifre kontrolünü düzelt"

git commit -m "Müşteri listesine Excel export özelliği ekle"

git commit -m "Rapor ekranındaki tarih filtresi hatasını düzelt"

Daha profesyonel ve standart bir yapı istersen Conventional Commits formatını kullanabilirsin. Bu yaklaşımda commit mesajı genellikle şu yapıya benzer:

type(scope): kısa açıklama

Buradaki type, değişikliğin türünü anlatır. scope, değişikliğin hangi modülle ilgili olduğunu gösterir. Kısa açıklama ise yapılan işi özetler.

fix(auth): boş şifre gönderildiğinde hata mesajını göster

feat(report): aylık satış raporu export özelliği ekle

refactor(api): müşteri sorgularını ayrı servis sınıfına taşı

docs(readme): kurulum adımlarını güncelle

style(ui): mobil görünümde kart boşluklarını düzenle

test(payment): ödeme hesaplama fonksiyonu için test ekle

chore(deps): bağımlılık sürümlerini güncelle

Küçük ve Anlamlı Commit Mantığı

İyi Git geçmişi, büyük ve karışık commit’lerden değil, küçük ve anlamlı commit’lerden oluşur. Küçük commit demek her satırı ayrı commit yapmak değildir. Küçük commit, tek bir mantıksal işi temsil eden commit demektir.

Örneğin login formunda boş şifre kontrolünü düzeltiyorsan, bu bir commit olabilir. Aynı anda rapor ekranını refactor etmek, CSS düzeltmek ve README güncellemek başka commit’ler olmalıdır.

Bu noktada git status ve git diff komutları çok değerlidir. Commit atmadan önce neyi eklediğini görmek, temiz geçmişin ilk şartıdır.

# Hangi dosyalar değişti?
git status

# Henüz staged olmayan değişiklikleri gör
git diff

# Staged değişiklikleri gör
git diff --staged

# Sadece seçili parçaları eklemek için
git add -p

Branch Nedir ve Neden Kullanılır?

Branch, ana geliştirme hattından ayrılarak izole şekilde çalışmanı sağlayan daldır. Yeni bir özellik geliştirirken, hata düzeltirken veya riskli bir deneme yaparken doğrudan kararlı kod üzerinde çalışmak yerine ayrı branch açarsın.

Böylece ana dal bozulmadan geliştirme yapabilirsin. İş tamamlandığında değişiklikleri inceleyebilir, test edebilir ve sonra ana dala merge edebilirsin.

# Yeni branch oluştur ve ona geç
git switch -c feature/report-export

# Mevcut branch'leri listele
git branch

# main branch'e dön
git switch main

Tek Kişilik Projede Branch Kullanmak Mantıklı mı?

Evet, çoğu zaman mantıklıdır. Tek başına çalışıyor olman, projenin geçmişini düzenli tutmaya ihtiyacın olmadığı anlamına gelmez. Hatta tek kişilik projelerde branch kullanmak gelecekteki kendin için çok faydalıdır.

Örneğin yeni bir admin panel ekranı geliştiriyorsun. Doğrudan main üzerinde çalışırsan, yarım kalmış kodla kararlı kod birbirine karışabilir. Ama feature/admin-panel branch’i açarsan, iş bitene kadar ana dal temiz kalır.

Basit Branch Stratejisi

Git Flow gibi detaylı modeller büyük ekiplerde ve düzenli release süreçlerinde işe yarayabilir. Ama her projeye ağır bir branch modeli kurmak gerekmez. Özellikle küçük ekiplerde veya tek kişilik projelerde sade bir strateji daha sağlıklıdır.

Tek kişilik küçük bir projede bu yapıyı daha da sadeleştirebilirsin:

main
feature/yeni-ozellik
fix/hata-duzeltme

Bu kadar basit bir yapı bile doğrudan main üzerinde gelişigüzel çalışmaktan çok daha sağlıklıdır.

Merge ve Rebase Farkı Sade Anlatım

Branch üzerinde çalıştın ve değişiklikleri ana dala almak istiyorsun. Burada genellikle iki kavram karşına çıkar: merge ve rebase.

Merge, iki geliştirme hattını birleştirir ve çoğu durumda geçmişte dallanma olduğunu açıkça gösterir. Rebase ise senin branch’indeki commit’leri alır, hedef branch’in en güncel halinin üzerine yeniden uygular. Bu daha düz ve lineer bir geçmiş oluşturabilir.

Pull Request Tek Kişilik Projede Bile İşe Yarar mı?

Pull request genellikle ekip çalışmasıyla ilişkilendirilir. Bir geliştirici değişiklik yapar, diğerleri inceler, yorumlar ve onaydan sonra merge edilir. Ama tek kişilik projelerde de pull request mantığı faydalı olabilir.

Çünkü pull request sadece başkasına göstermek için değil, kendine küçük bir kontrol noktası oluşturmak için de kullanılabilir. Değişiklikleri topluca görürsün, dosya bazında inceleyebilirsin, açıklama yazabilirsin ve merge etmeden önce son kez düşünürsün.

.gitignore Dosyasının Önemi

Temiz Git geçmişinin önemli parçalarından biri .gitignore dosyasıdır. Bu dosya Git’e hangi dosya ve klasörleri takip etmemesi gerektiğini söyler.

Log dosyaları, geçici dosyalar, build çıktıları, bağımlılık klasörleri, yerel ayar dosyaları, .env gibi gizli bilgiler ve sistem dosyaları genellikle repoya girmemelidir.

# Environment
.env
.env.local
.env.production

# Logs
*.log
logs/

# Dependencies
node_modules/
vendor/

# Build outputs
dist/
build/
.cache/

# OS / editor
.DS_Store
Thumbs.db
.vscode/
.idea/

# Secrets
*.pem
*.key
id_rsa
id_ed25519

Burada önemli bir detay var: .gitignore, daha önce Git tarafından takip edilmeye başlanmış dosyaları otomatik olarak geçmişten çıkarmaz. Bir dosya zaten tracked durumdaysa, onu ayrıca Git takibinden çıkarmak gerekir.

# Dosyayı çalışma klasöründe bırak, Git takibinden çıkar
git rm --cached .env

# Sonra .gitignore içine ekle
echo ".env" >> .gitignore

git add .gitignore
git commit -m "chore: env dosyasını Git takibinden çıkar"

Temiz Geçmiş Ne Demek?

Temiz Git geçmişi, geçmişin kusursuz olması demek değildir. Yazılım geliştirirken denemeler, hatalar, düzeltmeler ve fikir değişiklikleri olur. Temiz geçmiş, bütün bu sürecin okunabilir ve takip edilebilir kalmasıdır.

Temiz geçmişte commit mesajları anlamlıdır. Branch isimleri niyet anlatır. Gereksiz dosyalar repoya girmez. Hassas bilgiler sızmaz. Büyük değişiklikler küçük mantıksal parçalara ayrılır. Bir hata olduğunda geçmişi okumak mümkün olur.

Git Geçmişini Okumak: log, diff ve blame

Git sadece commit atmak için değil, geçmişi okumak için de kullanılır. Bazen en önemli iş, kod yazmak değil “bu kod neden böyle?” sorusuna cevap bulmaktır.

# Kısa commit geçmişi
git log --oneline

# Branch yapısını grafik gibi göster
git log --oneline --graph --decorate --all

# Son commit detayını göster
git show HEAD

# Belirli dosyanın satır geçmişini göster
git blame app/Services/ReportService.php

Geri Alma Senaryoları

Git kullanırken hata yapmak normaldir. Yanlış dosya ekleyebilirsin, commit mesajını eksik yazabilirsin, yanlış branch’te çalışabilirsin veya bir değişikliği geri almak isteyebilirsin. Önemli olan hangi durumda hangi komutun güvenli olduğunu bilmektir.

Commit mesajını düzeltmek

Son commit mesajını henüz paylaşmadıysan --amend ile düzeltebilirsin.

git commit --amend -m "fix(auth): boş şifre kontrolünü düzelt"

Staged dosyayı geri almak

Yanlışlıkla bir dosyayı staged yaptıysan çalışma dosyasını silmeden sahneden çıkarabilirsin.

git restore --staged config/local.php

Dosyadaki yerel değişikliği geri almak

Bir dosyada yaptığın değişikliği tamamen geri almak istiyorsan dikkatli olmalısın. Bu işlem çalışma alanındaki değişikliği siler.

git restore app/Controllers/UserController.php

Paylaşılmış commit’i güvenli şekilde geri almak

Eğer commit zaten remote’a gönderildiyse ve başkaları da görmüş olabilirse, geçmişi silmek yerine yeni bir geri alma commit’i oluşturmak daha güvenlidir.

git revert abc1234

Günlük Git Rutini Nasıl Olmalı?

Git’i doğru kullanmak için her gün karmaşık komutlar bilmek gerekmez. Basit ama düzenli bir rutin çoğu projede yeterlidir.

# 1. Güncel branch'i kontrol et
git status

# 2. Yeni iş için branch aç
git switch -c feature/report-export

# 3. Değişiklikleri yap

# 4. Ne değiştiğini kontrol et
git diff

# 5. Sadece ilgili değişiklikleri ekle
git add -p

# 6. Anlamlı commit at
git commit -m "feat(report): aylık satış raporu export özelliği ekle"

# 7. Branch'i remote'a gönder
git push -u origin feature/report-export

Bu akış ilk başta yavaş gibi görünebilir. Ama projeler büyüdükçe seni çok hızlandırır. Çünkü neyin ne zaman değiştiğini bilirsin, geçmişi okuyabilirsin ve hataları daha kolay toparlarsın.

Tek Kişilik Projeler İçin Basit Kural Seti

Tek başına geliştiriyorsan ağır süreçlere ihtiyacın yok. Ama küçük bir disiplin büyük fark yaratır.

Git’i Daha Profesyonel Kullanmak İçin Küçük Alışkanlıklar

Git uzmanı olmak için tüm komutları ezberlemek gerekmez. Daha önemli olan, doğru alışkanlıkları oturtmaktır.

Faydalı Resmi Kaynaklar