SSH Üzerinden Git Deployment: 5 Adımda Kolay Rehber

SSH Üzerinden Git Deployment Nasıl Yapılır? Hakkında Bilmeniz Gerekenler

Şöyle düşünün: Localde geliştirdiğiniz kod, aslında bir “kaynak”. Canlı sunucu ise, bu kaynağın çalıştığı “motor”. SSH üzerinden Git deployment, bu motor ile kaynağı düzenli ve kontrollü şekilde senkron tutmanın yöntemi. SFTP ile dosya kopyaladığınızda, neyin değiştiğini takip etmek zor; hangi sürümün canlıda olduğunu çoğu zaman bilemiyorsunuz. Git ile yaptığınızda ise her commit bir etiket gibi, hangi versiyonun yayında olduğunu net şekilde görebiliyorsunuz.

İşin püf noktası şurada: Sunucuda bir Git repo oluşturup, localden oraya push yapmak veya tam tersine sunucunun, GitHub/GitLab gibi bir remote repodan kod çekmesini sağlamak. İkisi de aynı kapıya çıkar, ama güvenlik, erişim ve CI/CD süreçlerine göre tercih değişir. Genelde kullanıcılarımızdan duyduğumuz en büyük şikayet şu oluyor: “Canlıda bir şey bozuldu, ama tam olarak ne değiştirdiğimi hatırlamıyorum.” Git deployment bu noktada hayat kurtarıyor, çünkü her değişiklik loglu, her sürüm geri alınabilir.

Bir efsaneyi de aradan çıkaralım: “Sunucu ne kadar güçlü olursa olsun, deploy yöntemi önemli değil, site zaten hızlı olur.” Hayır. Tıpkı bir araba motoru gibi, sunucular da yüksek devirde (trafikte) doğru soğutmaya (kaynağa) ihtiyaç duyar. Uygulama tarafındaki yanlış deploy süreçleri, cache’in sürekli bozulmasına, gereksiz dosya taşımaya ve hatta yanlış izinlere yol açarak en güçlü sunucuyu bile diz çöktürebilir.

Bu arada, performansınızı artırmak için Geliştirici Araçları sayfamızdaki diğer çözümlere de bakabilirsiniz.

Kaynak Yönetimi – Limitleri Zorlamayın

SSH üzerinden Git deployment kurarken ilk akla gelen genelde repository yapısı oluyor; ama dürüst olmak gerekirse, RAM miktarından ziyade işlemci mimarisi bazen çok daha kritiktir – her ne kadar herkes önce RAM’e baksa da. Deploy sürecinde CPU, disk I/O ve RAM aynı anda yük altında kalır: Git, dosya karşılaştırırken CPU ve disk kullanır; build script’leri (örneğin Node.js, Composer, npm, vite) RAM ve CPU’yu yer.

Pratik bir kural: Canlı ortamda “build” yapmak yerine, mümkünse localde veya CI ortamında build alıp, sunucuya sadece “çalışmaya hazır” dosyaları gönder. Böylece hem CPU’yu hem diski yormazsın. VDS veya Cloud kullanıyorsan, I/O limiti düşük paketlerde sık sık “site yavaşladı” şikayeti gelir; aslında sorun PHP değil, altta dosya sistemi sıkışıyordur. Bu yüzden logları okumak önemli.

“Aşırı kaynak kullanımı” uyarısı geldiğinde panik yapmadan önce kontrol edilecek ilk dosya genelde şudur: /var/log/syslog veya sistemine göre /var/log/messages. Apache/Nginx loglarına da bakarsın ama asıl tabloyu bu genel log dosyası verir. Orada yoğun IO hataları, out-of-memory (OOM) kill kayıtları veya dosya izin hataları görüyorsan, problemi sadece “hosting yavaş” diye etiketlemek pek adil olmuyor.

Güvenlik Duvarı ve Port Ayarları

Dış dünyaya açık her port, açık bir penceredir. SSH üzerinden Git deployment yaparken genelde 22 numaralı port kullanılır, ama güvenlik için bunu değiştirmenin faydası büyük. Özellikle VDS veya Cloud sunucu kullanıyorsan, SSH portunu değiştirmek, root login’i kapatmak ve sadece key-based authentication kullanmak neredeyse temel seviye tedbir sayılır.

Güvenlik duvarı tarafında işin mantığı basit: Sunucunun sadece gerçekten ihtiyaç duyduğu portlar açık kalmalı. Örneğin:

• SSH (22 veya değiştirdiysen farklı port) → Sadece IP’niz veya ofis IP’leriniz için açılabilir.
• HTTP/HTTPS (80/443) → Zorunlu olarak açık; burada da SSL kullanmak artık lüks değil, standart. İhtiyacınız varsa SSL sertifikasına mutlaka göz atın.
• FTP → SSH üzerinden Git deployment kullanıyorsan, klasik FTP’yi çoğu zaman tamamen kapatabilirsin. Bu, saldırı yüzeyini daraltır.

SSH üzerinden Git deployment kurarken özellikle şu senaryoyu görüyorum: Kullanıcı repo’yu sunucudan GitHub’a bağlamak istiyor, ama outbound bağlantılar firewall’da kısıtlı. Eğer sunucun CI/CD aracı olarak GitHub/GitLab’a erişecekse, ilgili outbound portlarına (genelde 22, 443) izin vermek gerektiğini unutma.

Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi

SSH üzerinden Git deployment nasıl yapılır sorusunda kimse ilk anda PHP versiyonunu düşünmüyor; ama production’da ortam uyumsuzluğu deploy’ların en sinsi düşmanı. En güncel sürüm her zaman en iyisi mi? Teknik olarak evet, ama pratikte “en stabil çalışan” sürüm daha önemli. Örneğin PHP 8.3 yeni özelliklerle gelir, fakat kullandığın framework veya eski bir eklenti tam uyumlu değilse, canlı ortamda fatal errorlarla boğuşursun.

Gözü kapalı yükseltme yerine, staging bir ortamda test edip sonra canlıya almak en sağlıklısı. Aynı şey veritabanı için de geçerli. MySQL, MariaDB veya PostgreSQL fark etmiyor; kullandığın ORM veya driver’ın versiyon uyumluluğunu kontrol etmeden major upgrade yapmak deployment sürecini raydan çıkarabilir.

Veritabanı optimizasyonu için altın kural: “Önce sorguyu düzelt, sonra sunucuyu büyüt.” Index olmayan bir sorguyu 2 CPU’dan 8 CPU’ya taşırsın, belki biraz hızlanır ama asıl problem çözülmez. Deployment sonrasında performans şikayetleri geliyorsa, ilk iş slow query log’a bakmak, sonra da cache katmanını (Redis, OpCache, object cache vb.) doğru konumlandırmak olmalı. Bu noktada performans odaklı hosting paketleri de işini ciddi anlamda kolaylaştırabilir.

Uygulama: Kurulum ve Yayına Alma

Terminali açın, şu komutu girin demiyorum ama mantık şu: SSH üzerinden Git deployment nasıl yapılır sorusunun temeli, sunucu ile kod deposu arasındaki ilişkiyi doğru kurmak. İki ana yol var:

1. Sunucu, uzak repodan kod çeker (pull)
   Bu senaryoda GitHub/GitLab/Bitbucket gibi bir remote repo’nuz olur, sunucuya SSH ile bağlanırsınız ve orada bir bare olmayan repo ile çalışırsınız. Deploy mantığı şuna benzer:
   • Localde commit ve push yaparsın.
   • Sunucuya SSH ile girer, proje klasöründe git pull çalıştırırsın.
   • İsteğe göre bir post-pull script’i ile cache temizler, migration çalıştırırsın.
2. Local, sunucuya direkt push eder (bare repo + hook)
   Bu daha “profesyonel” sayılabilecek bir yöntem. Sunucuda bare bir repo açarsın, local repo’yu oraya push edersin, ardından sunucuda post-receive hook ile dosyalar deployment klasörüne kopyalanır. Otomatikleşmiş bir akış elde edersin.

Her iki yöntemde de işin püf noktası, config dosyaları ve environment değişkenlerini doğru yönetmek. Canlı ortamın .env dosyası normalde Git’e girmez. Örneğin Laravel kullanıyorsan, .env dosyasını .gitignore içinde tutup, sunucudaki .env’yi elle yönetmek daha güvenli. Aynı şekilde, API anahtarları, ödeme sistemi secret’ları, veritabanı şifreleri repoda olmamalı.

Uygulamayı yayına alırken aklında böyle bir sıralama olabilir:

• Bağımlılıkları kontrol et (PHP versiyonu, Node.js, Composer, Git sürümü).
• Sunucuda proje için ayrı bir kullanıcı ve klasör oluştur.
• Git repo’yu uygun klasöre klonla veya bare repo kurup hook yapılandır.
• Config dosyasındaki ortam ayarlarını (DB, cache, mail) canlıya göre düzenle.
• Gerekliyse build/migration/script adımlarını çalıştır.
• Web sunucusunun (Nginx/Apache) doküman kök dizinini doğru klasöre yönlendir.

Genelde 5 dakikadan fazla sürmez; tabii ilk seferde logları okuyup ufak tefek izin sorunlarını çözmek gerekebilir. Bu arada WordPress gibi projelerde bile Git deployment kullanmak mümkün; sadece WordPress hosting tarafında otomatik cache ve güvenlik ayarlarını devre dışı bırakmamak gerekiyor.

Sık Karşılaşılan Sorunlar ve Pratik Çözümler

SSH üzerinden Git deployment özelinde biraz daha sahaya inelim. Sık görülen problemlerden bazıları şöyle:

• “Permission denied (publickey)” hatası
  Genelde SSH key’in sunucuya veya Git remote’una doğru eklenmemiş olması sebebiyle çıkar. Çözüm: Sunucudaki ~/.ssh/authorized_keys dosyasını kontrol edin, key formatını doğrulayın ve izinleri 600 olacak şekilde ayarlayın.
• Deploy sonrası boş sayfa (500 hata)
  En sık nedenler: PHP versiyonu uyumsuzluğu, eksik environment değişkeni veya bozuk cache. Çözüm: Sunucu error loguna (Nginx/Apache) bakın, ardından PHP error logunu inceleyin. İlk iş olarak uygulama cache’ini temizleyin ve gerekiyorsa composer install --no-dev veya benzeri komutla prod bağımlılıklarını yeniden kurun.
• Git pull ile dosya çatışmaları
  Canlı ortamda kodu el ile düzenlediyseniz, Git ile çektiğinizde conflict yaşarsınız. Aslında production ortamda direkt dosya değiştirmemek en temizi. Çözüm: Canlıda değişiklik yapmayın, hepsini localde commit edip push edin; gerektiğinde canlıdaki değişiklikleri localinize çekip merge edin.

Sıkça Sorulan Sorular

SSH üzerinden Git deployment güvenli mi?

Doğru yapılandırıldığında evet, oldukça güvenli. SSH key tabanlı bağlantı, güçlü şifreleme ile çalışır ve şifre yerine key kullandığınız için brute-force saldırı riski ciddi oranda azalır. Ek olarak, sadece ihtiyacınız olan kullanıcı ve IP’lere erişim vererek, firewall’da 22 veya özel SSH portunu sınırlandırarak ve mutlaka HTTPS/SSL ile yayına çıkarak güvenliği artırabilirsiniz. SSL tarafında desteğe ihtiyacınız varsa SSL sertifika paketlerine göz atmanız iyi olur.

Fiyat/Performans dengesi nasıl kurulur?

Aslında iki ayağı var: Donanım ve yazılım. Donanım tarafında, projenizin trafiği ve teknolojisine göre makul bir VDS veya Cloud sunucu seçmek, gereksiz yere “en üst paketi alayım, kafam rahat olsun” demekten daha mantıklı. Yazılım tarafında ise veritabanı optimizasyonu, cache kullanımı ve doğru deployment akışı ile daha küçük bir sunucudan bile ciddi performans alabilirsiniz. Kısaca: Önce optimizasyon, sonra kaynak artırma.

Taşıma (Migration) işlemi zor mu?

Klasik FTP ile dosya taşıyıp, veritabanı import etmeye alışkınsan ilk bakışta karmaşık görünebilir. Ama SSH üzerinden Git deployment mantığını bir kez kurduktan sonra, sonraki migration’lar çok daha düzenli ve kontrollü ilerler. Yeni bir sunucuya geçerken repo’yu klonlarsınız, .env ve veritabanını uyarlarsınız, hepsi bu. Bilhost tarafında, proje taşıma süreçlerinde genelde SSH ve Git destekli kurulum öneriyoruz; ihtiyacınız olursa teknik ekip bu akışı birlikte kurmanızda yardımcı oluyor. Yani “migration gözümde büyüyor” diyorsanız, yalnız değilsiniz; ama süreci doğru planladığınızda iş düşündüğünüzden çok daha kolay.

Sonuç

İşin özü şu: SSH üzerinden Git deployment nasıl yapılır sorusunun cevabı, sihirli bir komut dizisinden çok, doğru kurgulanmış bir akışta yatıyor. Localde yaptığın her değişikliği, kontrollü, loglu ve geri alınabilir şekilde canlıya aktarmak mümkün. Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma hayat kurtarır. Eğer bir yerde takılırsan biz buradayız, yorumlarda sorularını bekliyorum.