Git ile Verimli Sürüm Kontrolü: Günlük İş Akışı Rehberi

Çoğu geliştirici Git'i günde onlarca kez kullanır ama çoğu zaman yalnızca üç komutla: git add, git commit, git push. Oysa Git, doğru kullanıldığında sadece bir yedekleme aracı değil; cesaretle deney yapmanızı, hataları geri almanızı ve ekip içinde temiz bir tarih bırakmanızı sağlayan bir güvenlik ağıdır. Bu rehberde günlük çalışma akışınızı gerçekten hızlandıracak pratiklere odaklanıyoruz.

Her şey küçük ve anlamlı commit'lerle başlar

İyi bir commit, "tek bir mantıksal değişikliği" temsil eder. 400 satırlık dev bir commit yerine, birbirinden bağımsız işleri ayrı commit'lere bölmek; ileride bir hatayı izlemeyi, tek bir değişikliği geri almayı ve kod incelemesini kat kat kolaylaştırır.

Bir dosyanın yalnızca bazı satırlarını commit'lemek isterseniz -p (patch) bayrağı işinizi görür:

git add -p

Git size her değişiklik bloğunu tek tek sorar; y ile dahil eder, n ile atlarsınız. Böylece tek dosyada karışmış iki ayrı işi iki ayrı commit yapabilirsiniz.

Commit mesajında da basit bir kural büyük fark yaratır: özet satırı 50 karakteri geçmesin, emir kipinde yazılsın.

Kullanıcı girişinde boş şifre kontrolü ekle

Boş şifreyle gönderilen formlar 500 hatası veriyordu.
Artık sunucu tarafında doğrulama yapılıp 400 dönülüyor.

İlk satır "ne yaptığını", gövde ise "neden yaptığını" anlatır. Altı ay sonra bu mesajı okuyan kişi muhtemelen siz olacaksınız.

Dallanma: korkmadan deney yapmanın yolu

Git'in en güçlü yanı dallardır (branch). Yeni bir özelliğe başlarken main üzerinde çalışmak yerine ayrı bir dal açın:

git switch -c feature/yeni-ozellik

Burada istediğiniz kadar deneyebilir, bozabilir, baştan yazabilirsiniz; main her zaman çalışır durumda kalır. İş bittiğinde dalı ana koda birleştirirsiniz.

git switch ve git restore, eski git checkout'un karışıklığını gidermek için geldi: dal değiştirmek için switch, dosya geri almak için restore kullanın. Tek komutun iki işi yapması yerine niyetiniz koddan okunur hâle gelir.

Yarıda kalan işi kenara koymak: stash

Bir hata düzeltmesi için aniden başka bir dala geçmeniz gerektiğinde, yarım kalan değişiklikleri commit'lemek zorunda değilsiniz:

git stash push -m "yarım kalan form tasarımı"
git switch main
# acil işi hallet...
git switch feature/form
git stash pop

git stash list ile biriktirdiğiniz tüm zulaları görür, git stash pop ile en sonuncusunu geri alırsınız. Stash, "bir dakikalığına buraya koyayım" demenin temiz yoludur.

Geçmişi düzeltmek: rebase ve amend

Henüz paylaşmadığınız (push etmediğiniz) commit'leri düzeltmek tamamen güvenlidir. Son commit'e küçük bir ek yapmayı unuttuysanız:

git add unutulan-dosya.js
git commit --amend --no-edit

Birden fazla commit'i birleştirmek, sıralamak veya mesajlarını düzeltmek için etkileşimli rebase kullanılır:

git rebase -i HEAD~3

Açılan listede pick yerine squash yazarak commit'leri birleştirir, reword ile mesaj düzeltirsiniz. Böylece kod incelemesine "deneme 1", "yine olmadı", "tamam şimdi oldu" gibi commit'lerle değil; tertemiz bir tarihle gidersiniz.

Altın kural: Başkalarının da kullandığı (push edilmiş) bir dalın geçmişini rebase ile değiştirmeyin. Rebase, yalnızca yerelde, henüz paylaşılmamış commit'ler için güvenlidir.

Bir şeyi batırdığınızda: reflog hayat kurtarır

Yanlışlıkla bir dalı sildiniz, sert bir reset ile commit'leri uçurdunuz? Panik yapmayın. Git, HEAD'in nereye gittiğini bir süre kaydeder:

git reflog

Listede her hareketin bir referansı vardır (HEAD@{2} gibi). Kaybettiğiniz noktaya geri dönmek için:

git reset --hard HEAD@{2}

Reflog sayesinde "geri alınamaz" sandığınız çoğu işlem aslında geri alınabilir. Git'te bir şeyi tamamen kaybetmek düşündüğünüzden çok daha zordur.

Merge mi, rebase mi?

İki dalı birleştirmenin iki yolu vardır ve hangisini seçeceğiniz çoğu zaman kafa karıştırır. İkisinin de yeri ayrıdır:

Pratikte en temiz akış şudur: özellik dalınızda çalışırken main'deki yenilikleri git rebase main ile alın; iş bittiğinde dalınızı main'e bir merge (veya squash merge) ile bağlayın. Böylece main tarihi okunabilir kalır, sizin dalınız da hep güncel olur.

Çakışma (conflict) çıktığında panik yapmayın; Git çakışan bölgeleri <<<<<<< işaretleriyle gösterir. Dosyayı düzeltin, git add ile işaretleyin ve git rebase --continue deyin. İçinden çıkamadığınız bir durumda git rebase --abort her şeyi başladığınız noktaya döndürür — yani denemekten zarar gelmez.

Tarihte iz sürmek: log'u verimli kullanın

git log ham hâliyle kalabalıktır. Şu üç varyasyon günlük kullanımın %90'ını karşılar:

# Her commit tek satır, dallar grafikle
git log --oneline --graph --all

# Bir dosyanın geçmişi
git log --oneline -- server.js

# "Bu fonksiyon ne zaman değişti?" — pickaxe araması
git log -S "generateShareHTML" --oneline

-S bayrağı (pickaxe), verdiğiniz metnin eklendiği veya silindiği commit'leri bulur. "Bu satır ne ara böyle oldu?" sorusunun en hızlı cevabıdır. Satır bazında sorumlu arıyorsanız git blame dosya.js -L 120,140 ile yalnızca ilgili aralığa bakın.

Hatalı commit'i otomatik bulmak: bisect

Uygulama iki hafta önce çalışıyordu, bugün bozuk — ama hangi commit bozdu? Yüzlerce commit'i elle taramak yerine ikili arama yapın:

git bisect start
git bisect bad                  # şu anki durum bozuk
git bisect good v1.4.0          # bu sürümde çalışıyordu

Git sizi otomatik olarak ortadaki bir commit'e götürür. Test edin; git bisect good veya git bisect bad deyin. Her adımda arama alanı yarıya iner: 200 commit'lik bir aralıkta suçluyu en fazla 8 adımda bulursunuz. Bitince git bisect reset ile normale dönün. Testiniz komutla çalışıyorsa git bisect run npm test ile süreci tamamen otomatikleştirebilirsiniz.

Tek bir commit'i başka dala taşımak: cherry-pick

Bazen yanlış dala commit atarsınız ya da bir düzeltmeyi hem main'e hem eski sürüm dalına uygulamanız gerekir:

git switch release/1.4
git cherry-pick a1b2c3d

cherry-pick, verdiğiniz commit'in değişikliğini bulunduğunuz dala yeni bir commit olarak uygular. Commit'i yanlış daldan silmek için o dala dönüp git reset --hard HEAD~1 diyebilirsiniz (tabii push etmediyseniz).

.gitignore ve depo hijyeni

Depoya girmemesi gerekenler en baştan .gitignore'a yazılmalı: node_modules/, derleme çıktıları, .env gibi gizli bilgiler, editör ayarları. Sonradan eklenmiş bir dosyayı izlemeden çıkarmak için:

git rm --cached .env
echo ".env" >> .gitignore

--cached bayrağı dosyayı diskten silmez, yalnızca Git'in takibinden çıkarır. Bir kez push edilmiş gizli bir anahtar içinse .gitignore yetmez: anahtarı iptal edip yenisini üretmek tek güvenli çözümdür, çünkü eski değer depo geçmişinde yaşamaya devam eder.

Günlük akışı özetleyen pratik bir döngü

1. Güncel kalın: git pull --rebase ile uzaktaki değişiklikleri temiz şekilde alın.
2. Yeni iş için dal açın: git switch -c feature/...
3. Küçük, anlamlı commit'ler atın: git add -p + iyi mesaj.
4. İşi bitirince geçmişi toparlayın: gerekiyorsa rebase -i.
5. Gönderin ve birleştirme isteği (pull request) açın.

Sonuç

Git'i bir yedekleme kutusu değil, bir deney laboratuvarı olarak görmeye başladığınızda çalışma şekliniz değişir. Dallarla cesaretle deneyersiniz, stash ile akışınızı bölmeden iş değiştirirsiniz, rebase ile tertemiz bir tarih bırakırsınız, bisect ile hatanın kaynağını dakikalar içinde bulursunuz ve reflog sayesinde hata yapmaktan korkmazsınız. Bu birkaç komutu günlük rutininize kattığınızda Git, en sessiz ama en güvenilir takım arkadaşınız hâline gelir.