Git rehberleri komut listesine bayılır. Kırk komut, üç staging area şeması ve ilk haftanda yine bir günlük işini kaybedersin. Yıllardır görüntü hatlarında, gömülü projelerde ve tez yazarken Git kullandıktan sonra şuna inanıyorum: komutlar, beş alışkanlığın yanında tali kalıyor. İşte beni kurtardıkları sırayla.
Şekil: kendi çizimim.
1. Ne’yi değil, niye’yi yaz
git log -p neyin değiştiğini zaten gösteriyor. Diff orada duruyor. Mesajın
görevi niye’yi kaydetmek. “Tracker düzeltildi” gelecekteki bana hiçbir şey
söylemiyor. “Eşleştirmeden önce kutular kare kenarına kırpıldı, negatif
genişlik filtre güncellemesini çökertiyordu” her şeyi söylüyor; güvenle geri
alıp alamayacağım dahil.
Veri seti yazısında her şeyi biri
denetleyecekmiş gibi kur demiştim. Commit’lerde o biri, altı hafta sonra gece
yarısı git log açan sensin.
2. Deney başına bir dal
SUAS görüntü işinde her eğitim deneyi kendi dalını aldı: bir karolama değişikliği, bir augmentation çarpanı, bir config ayarı. Kod büyük olduğu için değil. mAP oynadığında elimde tam olarak tek bir aday açıklama olsun diye.
Kazananları birleştir, kaybedenleri sil. Dalın maliyeti sıfır. İzini bir değişikliğe süremediğin bir iyileşmenin maliyeti ise büyük.
3. Veri dışarıda, tarif içeride
Eğitim setimiz 15.000 görüntü civarı. Hiçbiri Git’e ait değil. Git’e ait olan, ham karelerden veri setini üreten script ve her parametreyi sabitleyen config. Repo tarifi saklar. Depolama malzemeyi.
.gitignore’u onuncu commit’te değil ilkinde kur: build klasörleri,
ağırlıklar, export edilmiş engine’ler, veri seti klasörleri. GitHub büyük
dosyayı zaten reddediyor. Git LFS de tasarımla çözemediğin durumların yaması,
varsayılan değil.
4. Push’lamadan önce kendi diff’ini oku
git diff --staged, her seferinde, istisnasız. Otuz saniye sürüyor ve debug
print’i, elle gömülmüş yolu, silmeyi unuttuğun yorum satırına alınmış bloğu
yakalıyor.
GitHub’da repoda tek kişi olsam bile pull request açıyorum. Kendi değişikliğini başka bir arayüzde okumak kafanda bir düğmeye basıyor: kastettiğini okumayı bırakıp gerçekten yazdığını okumaya başlıyorsun.
5. Masandan çıkanı etiketle
Bir derleme sahadaki takip işinde bir Jetson’a gittiğinde ya da bir ağırlık dosyası gerçekten uçan sürüm olduğunda, o commit bir etiket alıyor. Haftalar sonra bir hata kaydı ya da tuhaf bir saha sonucu geliyor ve etiket, önemli olan tek soruyu yanıtlıyor: bu davranışı hangi kod üretti?
Etiket yoksa hafızaları diff’lersin. git tag -a bir satır. Etiketsiz bir
sürümü sonradan kazıp bulmak bir öğleden sonra sürer ve bunu hep en kötü
zamanda ödersin.
Bunların hiçbiri ileri seviye değil. Mesele de bu. Git’in değeri egzotik komutlarda değil; bir şeyin ters gittiği gün kendi geçmişine güvenebilmekte.