Değişikliği FTP ile yüklemek, küçük siteler için uzun süre yeterli görünür. Sonra bir gün yanlış dosya yüklenir, hangi sürümün canlıda olduğu bilinmez ve "dün çalışıyordu" cümlesi kurulur.
Sürüm kontrolü bu belirsizliği ortadan kaldırır. Ve bunun için hosting hesabından vazgeçmeniz gerekmez — paylaşımlı ortamda da uygulanabilir yollar vardır.
FTP ile Yayının Üç Sorunu
- Geçmiş kaydı yok. Ne zaman ne değişti bilinmez, geri dönüş yapılamaz.
- Kısmi yükleme riski. Bağlantı koparsa yarısı yeni yarısı eski bir site kalır.
- Ekip çalışması imkânsız. İki kişi aynı dosyayı düzenlerse biri diğerinin işini siler.
Üçüncü madde tek kişilik projelerde de yaşanır: farklı bilgisayarlardan çalışıyorsanız hangi kopyanın güncel olduğunu bilemezsiniz.
Üç Uygulanabilir Yaklaşım
| Yöntem | Gereksinim | Uygunluk |
|---|---|---|
| Panel Git aracı | Panelde Git desteği | En kolay |
| SSH üzerinden çekme | Terminal erişimi | Esnek |
| Otomatik FTP dağıtımı | Yalnızca FTP | Her yerde çalışır |
Üçüncü satır önemli bir imkândır: sunucuda Git olmasa bile sürüm kontrolü kullanabilirsiniz. Depoya gönderdiğiniz değişiklikleri, bir dağıtım servisi otomatik olarak FTP ile sunucuya yükler. Sürüm kontrolü sizde, yükleme otomatik.
Panel Üzerinden Git
Birçok kontrol paneli Git deposu klonlama ve güncelleme özelliği sunar. Tipik akış:
- Panelde depo adresini tanımlarsınız
- Depo, hesabınızdaki bir klasöre klonlanır
- Değişiklik yaptığınızda panelden güncelleme tetiklersiniz
Bu yöntemin kritik ayrıntısı: depoyu web kök dizinine doğrudan klonlamayın. Aksi hâlde depo klasörünüz dışarıdan erişilebilir hâle gelir ve tüm kod geçmişiniz — silinmiş şifreler dahil — ifşa olur.
Doğru yapı: depoyu web kökü dışına klonlayın, yalnızca genel dosyaları web köküne bağlayın veya kopyalayın.
Depoda Ne Olmamalı?
Sürüm kontrolüne alınmaması gerekenler:
- Yapılandırma ve ortam dosyaları. Veritabanı şifresi ve API anahtarları depoya girmemelidir.
- Kullanıcı yüklemeleri. Medya dosyaları depoyu şişirir ve sürümlenmesi anlamsızdır.
- Önbellek ve geçici dosyalar. Sürekli değişir, gürültü üretir.
- Bağımlılık klasörleri. Bunlar tanım dosyasından yeniden kurulabilir.
- Log dosyaları. Depoda yeri yoktur.
Birinci madde en kritiğidir. Bir şifre bir kez depoya girdiyse, sonradan silseniz bile geçmişte kalır ve okunabilir. Böyle bir durumda yapılacak tek doğru şey, o şifreyi ve anahtarları değiştirmektir.
Basit Bir Yayın Akışı
Küçük ekipler ve tek kişilik projeler için yeterli bir düzen:
- Ana dal her zaman yayınlanabilir olsun. Canlıdaki hâl budur.
- Yeni işleri ayrı dalda yapın. Yarım kalan iş ana dalı bozmasın.
- Test ortamında deneyin. Alt alan adında bir kopya bu iş için yeterlidir.
- Ana dala birleştirin ve yayınlayın. Yayın tek bir işlemdir.
- Sürüm etiketi koyun. Geri dönmeniz gerekirse hangi noktaya döneceğinizi bilirsiniz.
Beşinci madde çoğu zaman atlanır ama en çok işe yarayan adımdır: bir sorun çıktığında "üç gün önceki hâle dön" demek yerine, belirli bir sürüme dönersiniz.
Veritabanı: Sürüm Kontrolünün Sınırı
Git kod dosyalarını yönetir, veritabanınızı yönetmez. Bu, sık karşılaşılan bir yanılgıdır.
Kod geri alındığında veritabanı yapısı eski hâline dönmez. Bu yüzden:
- Veritabanı değişikliklerini ayrı bir düzenle takip edin
- Yayın öncesi mutlaka veritabanı yedeği alın
- Yapısal değişiklikleri geri alınabilir biçimde planlayın
Yayın sırasında hem kodu hem veritabanını birlikte düşünmek, geri dönüşü mümkün kılan tek yaklaşımdır.
Nereden Başlamalı?
Hâlâ FTP ile çalışıyorsanız, geçiş kademeli olabilir:
- Mevcut sitenizin kopyasını yerel bir depoya alın
- Hassas dosyaları depo dışında tutacak kuralları tanımlayın
- Depoyu uzak bir servise gönderin
- Otomatik dağıtımı kurun — panel aracı, SSH veya FTP dağıtımı
- Bir test değişikliğiyle akışın çalıştığını doğrulayın
Bu geçiş bir günlük iştir ve sonrasında "hangi sürüm canlıda" sorusu bir daha sorulmaz. Panelinizde Git desteği yoksa, bu özelliği sunan bir hosting paketi geçişi belirgin şekilde kolaylaştırır.
Sonuç
Sürüm kontrolü büyük ekiplere özgü bir lüks değil, tek kişilik projelerde bile geri dönüş imkânı sağlayan temel bir düzendir. Sunucunuzda Git desteği olmasa bile kullanabilirsiniz — depo sizde, yükleme otomatik FTP dağıtımıyla yapılır. İki kuralı atlamayın: depoyu web kök dizinine klonlamayın ve şifre içeren dosyaları depoya koymayın — bir kez girdiyse geçmişte kalır ve o anahtarları değiştirmeniz gerekir. Son olarak sınırını bilin: Git kodu yönetir, veritabanınızı yönetmez.
Sıkça Sorulan Sorular (SSS)
Hostingimde Git yok, sürüm kontrolü kullanabilir miyim?
Evet. Depoyu kendi bilgisayarınızda ve uzak bir serviste tutup, değişiklikleri otomatik FTP dağıtımıyla sunucuya gönderebilirsiniz. Sunucuda Git bulunması zorunlu değildir; sürüm kontrolünün faydasını yine de alırsınız.
Depoyu web kök dizinine klonlayabilir miyim?
Klonlamayın. Depo klasörünüz dışarıdan erişilebilir hâle gelirse tüm kod geçmişiniz — geçmişte silinmiş şifreler dahil — okunabilir. Depoyu web kökü dışına klonlayın, yalnızca genel dosyaları web köküne alın.
Yapılandırma dosyamı depoya koyabilir miyim?
Şifre veya API anahtarı içeriyorsa hayır. Bir kez depoya giren bilgi, sonradan silinse bile geçmişte kalır ve okunabilir. Böyle bir şey olduysa dosyayı silmek yetmez; ilgili tüm şifre ve anahtarları değiştirin.
Git veritabanımı da yönetir mi?
Hayır. Git yalnızca dosyaları sürümler. Kodu geri aldığınızda veritabanı yapısı eski hâline dönmez. Veritabanı değişikliklerini ayrı takip edin ve her yayın öncesi mutlaka yedek alın.
