Git'e geçiş: FTP ile dosya atmayı bırakmak

Altı yıldır kod yazıyorum ve bu sürenin büyük bir bölümünde FTP ile dosya attım. Bir değişiklik yapıyordum, FileZilla’yı açıyordum, değişen dosyayı sunucuya yüklüyordum. Hata çıkınca bir önceki sürümü hatırlamak için beyin gücü harcıyordum. Zaman zaman “acaba bu değişikliği yapmadan önce nasıldı?” diye kafayı yiyordum.

Bu ay Git’i düzgün öğrenmeye karar verdim. “Kullanmalıyım” diyordum yıllardır; ancak bu proje beni zorunlu kıldı.

Git nedir?

Sürüm kontrolü (Version Control), dosyalarınızdaki değişiklikleri zaman içinde takip etmenizi sağlayan sistemdir. Git, şu an en yaygın kullanılan dağıtık sürüm kontrol sistemidir.

Somut faydası: her değişikliği kayıt altına alırsınız, istediğiniz noktaya dönebilirsiniz, farklı özellikler için ayrı dallar (branch) açabilirsiniz ve ne zaman, neden değiştirildiğini geçmişte görebilirsiniz.

Temel kurulum

Git kurulumunun ardından kimlik bilgilerini ayarlıyorsunuz:

git config --global user.name "Muhammet Şafak"
git config --global user.email "[email protected]"

Projeyi Git’e almak için proje klasöründe:

git init

Bu komut gizli bir .git/ klasörü oluşturur. Artık proje bir Git deposu (repository).

İlk commit

Değişiklikleri kaydetmek iki adımda gerçekleşiyor: önce hangi dosyaları ekleyeceğinizi seçiyorsunuz (staging), sonra kayıt yapıyorsunuz (commit).

# Tek dosya eklemek
git add src/Models/User.php

# Tüm değişimleri eklemek
git add .

# Kayıt oluşturmak
git commit -m "Kullanıcı modeli eklendi"

Commit mesajı geçmişe bakıldığında ne yapıldığını anlatmalı. “Güncellendi” ya da “düzeltildi” gibi belirsiz mesajlar sonradan işe yaramıyor.

Başlangıçta bunu hafife aldım ve ilk hafta commit mesajlarım tam anlamıyla işe yaramazdi: “değişiklik”, “düzeltme”, “tekrar”. İki hafta sonra log’a bakınca hiçbir satırın ne zaman ne olduğunu söylemediğini fark ettim. O günden beri her mesajı “neyi ve neden yaptım” sorusunu yanıtlar biçimde yazmaya çalışıyorum.

Dal (branch) açmak

Yeni bir özellik geliştirirken ana dal üzerinde çalışmak riskli. Bir şeyler bozulursa her şey bozuluyor. Bunun için dal kullanıyorsunuz:

# Yeni dal oluşturup geçiş yapmak
git checkout -b yorum-ozelligi

# Dallar arasında geçiş
git checkout main

yorum-ozelligi dalında rahatça çalışabilirsiniz. Ana dal etkilenmiyor. İşi bitirdiğinizde birleştiriyorsunuz:

git checkout main
git merge yorum-ozelligi

Bu akışı kavradıktan sonra FTP ile çalışmanın ne kadar kör bir uçuş olduğunu fark ettim.

Özellikle şu an üzerinde çalıştığım projede müşteri ortasında bir şey değiştirmemi istedi; ama aynı anda başka bir özelliği de geliştiriyordum. Dala geçtim, değişikliği yaptım, birleştirdim, devam ettim. FTP döneminde bunu yapmak için ya değişiklikleri zihinsel olarak takip etmek ya da tek tek dosyaları farklı adlarla yedeklemek zorunda kalırdım. İkisi de çürük bir çözüm.

Durum ve geçmişe bakış

# Neyin değiştiğini görmek
git status

# Detaylı farkları görmek
git diff

# Geçmiş commit listesi
git log --oneline

git log --oneline çıktısı şöyle görünüyor:

a3f2c1b Yorum formu doğrulaması eklendi
9d1e4a0 Kullanıcı profil sayfası düzenlendi
7b2f3c1 Veritabanı bağlantısı yapılandırıldı

Her satırda commit kimliği (hash) ve mesaj var. Hangi değişikliğin ne zaman yapıldığını görmek için bu liste yeterli.

Hata yapıldığında geri dönmek

Git’in en rahatlatıcı özelliği bu. Bir commit’e geri dönmek için:

# Son commit'i geri almak (değişiklikler kaybolmaz, staging'e döner)
git reset HEAD~1

# Belirli bir commit'e dönmek
git checkout 9d1e4a0 -- src/Models/User.php

FTP döneminde bir dosyayı yanlışlıkla üzerine yazınca geri alma yoktu. Şimdi Git tarihçesine bakıp istediğim noktayı geri getirebiliyorum.

Bunu ilk gerçek anlamda hissettiğim an şuydu: ödeme entegrasyonunu test ederken bir mantık hatasını fark ettim ama nereden geldiğini bilmiyordum. git diff ile son iki saatte tam olarak neyi değiştirdiğime baktım, hatayı üç dakikada buldum. FTP ile çalışıyor olsaydım hangi dosyayı değiştirdiğimi bile net hatırlamıyor olabilirdim.

GitHub ile uzak depo

Projeyi yalnızca yerel tutmak yerine uzak bir depoya (remote repository) göndermek hem yedek hem de erişilebilirlik sağlıyor. GitHub bunun için en yaygın platform:

# Uzak depo bağlamak
git remote add origin https://github.com/kullanici/proje.git

# Değişiklikleri göndermek
git push -u origin main

Artık başka bir bilgisayarda da git clone ile projeyi indirip çalışabiliyorum.

FTP ile farkı

FTP ile çalışırken sunucudaki dosya tek gerçekti; yerel çalışma kopyası yalnızca bir ara durumdu. Eğer kötü bir şey yaptıysanız bunu ancak sunucuya attıktan sonra fark ediyordunuz.

Git ile her şey yerel geçmişte kayıtlı. Sunucuya atmadan önce değişikliği inceleyebiliyorsunuz, test edebiliyorsunuz, gerekirse geri alabiliyorsunuz. Bu güven hissi çalışma biçimini değiştiriyor; daha rahat denemeler yapıyorsunuz.

Pratik olarak FTP ile Git arasındaki en büyük psikolojik fark şu: FTP’de her hamle geri dönülmez hissettiriyordu, bu yüzden daha az deneme yapıyordum. Git’te ise “denerim, olmadı geri alırım” eğilimi var. Bu cesaret, beklenmedik biçimde daha iyi kod üretmenize de katkı sağlıyor.

Şu an tüm aktif projelerimi Git’e aldım. Geç kalmış bir adım ama atılmış.