Git ile Çalışma: Günlük Akış ve Zor Anlarda Kurtarma

Git, günlük kullanımda birkaç komutla yürüyen ama işler karıştığında insanı çaresiz bırakabilen bir araçtır. İyi haber şu: kurtarma senaryolarının neredeyse tamamı mümkündür, çünkü Git nadiren gerçekten veri siler. Bu yazıda hem sağlıklı bir günlük akışı hem de zor anlarda işe yarayan komutları ele alıyoruz.

Günlük akış: basit ve tekrarlanabilir

Küçük ekipler için karmaşık dallanma modelleri genellikle gereksizdir. Sade bir akış çoğu ekibe yeter:

1. Ana dal her zaman çalışır durumda tutulur; doğrudan buraya kod yazılmaz.
2. Her iş için tanımlayıcı adla bir dal açılır: duzeltme/izin-bakiyesi, ozellik/rapor-disa-aktarma.
3. İş bittiğinde testler çalıştırılır ve birleştirme isteği açılır.
4. İnceleme sonrası ana dala alınır ve dal silinir.

Uzun yaşayan dallar en büyük risktir. Üç hafta boyunca ayrı kalan bir dal, birleştirme sırasında yüzlerce çakışma üretir. Kural: dallar günlerle ölçülmeli, haftalarla değil.

Commit disiplini

Commit, geçmişe bırakılan bir nottur. İyi bir commit tek bir konuyu içerir ve mesajı ne yapıldığını açıkça söyler. "düzeltmeler", "güncelleme", "son hâli" gibi mesajlar, altı ay sonra hiçbir işe yaramaz.

Küçük commit’lerin asıl faydası geri alma kolaylığıdır. Bir hata fark edildiğinde, tek konulu commit’ler arasında sorunlu olanı bulmak ve yalnızca onu geri almak mümkündür. On farklı değişikliği içeren tek bir commit’te bu imkân kaybolur.

Pratik ipucu: Commit mesajını yazarken zorlanıyorsanız, muhtemelen tek commit’te birden fazla iş yapmışsınızdır.

Çakışmaları çözmek

Çakışma, aynı satırların iki farklı dalda değişmesiyle oluşur ve normaldir. Panik yaratan şey, çözüm sırasında yanlış kod bırakma korkusudur. Güvenli yöntem şudur: çakışan her bölümde iki tarafın da ne yapmak istediğini anlayın, gerekirse ilgili commit’lerin mesajlarına bakın ve çözümden sonra mutlaka testleri çalıştırın.

Çakışmaları azaltmanın en etkili yolu ise sıklıktır: ana daldaki değişiklikleri günlük olarak kendi dalınıza almak, çakışmaları küçük ve yönetilebilir tutar.

Kurtarma: en çok işe yarayan komutlar

• Son commit’i düzeltmek: Henüz paylaşılmamış bir commit’e ekleme yapmak veya mesajını değiştirmek mümkündür.
• Yanlış dalda çalışmak: Yapılan değişiklikler geçici olarak bir kenara alınıp doğru dalda geri uygulanabilir.
• Yayınlanmış bir commit’i geri almak: Geçmişi silmek yerine, değişikliği tersine çeviren yeni bir commit oluşturulmalıdır. Paylaşılan dallarda tek güvenli yöntem budur.
• Kaybolan çalışmayı bulmak: Geçmişteki tüm hareketleri gösteren kayıt sayesinde, yanlışlıkla silinen dallar ve sıfırlanan commit’ler çoğu zaman geri getirilebilir.
• Hatanın hangi commit’te girdiğini bulmak: İkili arama yöntemiyle geçmiş taranarak sorunlu commit tespit edilebilir; yüzlerce commit arasında bu işlem birkaç dakika sürer.

Uzak depo ile çalışmak

Yerel çalışmanın yanında, uzak depoyla ilişkinin de sağlıklı kurulması gerekir. En sık yaşanan karışıklık, uzaktaki değişiklikleri almadan gönderim yapmaya çalışmaktan doğar.

Sağlıklı alışkanlık şudur: güne başlarken uzak değişiklikleri alın, gönderim yapmadan önce tekrar alın. Böylece çakışmalar küçükken ve bağlam aklınızdayken çözülür.

Zorla gönderim (force push) ise özel bir dikkat ister. Yalnızca kendinize ait, kimsenin üzerinde çalışmadığı dallarda kullanılmalıdır. Paylaşılan bir dalda geçmişi ezmek, o dalı kullanan herkesin çalışmasını bozar ve toparlanması zaman alır.

Depoya girmemesi gerekenler

Yapılandırma dosyaları, ortam değişkenleri, bağımlılık klasörleri, derleme çıktıları ve kişisel editör ayarları depoya girmemelidir. Bunun için yok sayma dosyası projenin ilk gününde hazırlanmalıdır.

Sır bir kez geçmişe girdiyse, dosyayı silmek yeterli değildir: geçmişte kalmaya devam eder ve depoyu klonlayan herkes erişebilir. Bu durumda yapılacak ilk iş, sızan parola veya anahtarı iptal edip yenilemektir. Geçmiş temizliği ikinci adımdır ve tek başına yeterli sayılmamalıdır.

Etiketleme ve sürümleme

Yayına çıkan her sürümü etiketlemek, sonradan "hangi kod canlıda çalışıyordu" sorusunu cevaplanabilir kılar. Etiketsiz bir depoda, üç ay önceki bir hatayı incelemek tahmin işine döner.

Yaygın yaklaşım anlamsal sürümlemedir: kırıcı değişikliklerde ana numara, geriye uyumlu yeni özelliklerde ikinci numara, düzeltmelerde üçüncü numara artırılır. Bu şema, kütüphane geliştirenler için zorunlu, uygulama geliştirenler için ise faydalı bir disiplindir.

Etiketlere ek olarak, her sürümde nelerin değiştiğini özetleyen kısa bir değişiklik günlüğü tutulmalıdır. Bu günlük hem destek ekibine hem de kullanıcıya doğrudan fayda sağlar.

İnceleme kültürü

Birleştirme isteği, Git’in teknik değil kültürel tarafıdır. Küçük istekler gerçekten incelenir; 2.000 satırlık istekler ise göstermelik onay alır. İnceleme yaparken kod stiline değil davranışa odaklanılmalıdır; stil zaten otomatik araçlarla denetlenmelidir. Komutların ayrıntılı açıklamaları için resmî Git dokümantasyonu en güvenilir kaynaktır.

Sonuç

Git’i rahat kullanmanın sırrı çok komut ezberlemek değil, birkaç alışkanlığı korumaktır: kısa ömürlü dallar, küçük ve tek konulu commit’ler, sık güncelleme ve depoya sır koymamak. Bu dördü yerindeyse, karışan durumların neredeyse tamamı birkaç komutla düzelir.