Site dağıtımı için Git temelleri

Git Neden Site Dağıtımı İçin Gereklidir?

Hâlâ site dosyalarını FTP veya dosya yöneticisi paneli ile sunucuya yüklüyorsanız, muhtemelen şu senaryoya aşinasınızdır: Kodda küçük bir değişiklik, atlanan bir dosya ve site çöker. Git (Git), bu karmaşayı izlenebilir ve geri alınabilir bir sürece dönüştürür. Git ile koddaki her değişiklik, belirli bir mesaj ve benzersiz bir kimlik ile bir "commit" (commit) alır; bir şey bozulursa, tam olarak önceki sürüme dönebilirsiniz.

Bu eğitimde, Git'in temel kavramlarına aşina olduğunuzu ve bunu bir Linux sunucusuna (Ubuntu veya Debian gibi) site dağıtımı için kullanmak istediğinizi varsayıyoruz. Nihai hedef, sunucuda tek bir git pull komutu ile sitenin en son sürümünü dağıtmaktır; dosyaları manuel olarak yüklemeye gerek kalmadan.

Dağıtım için Önerilen Depo Yapısı

Her şeyden önce, Git deponuzun nasıl bir yapıya sahip olacağına karar vermelisiniz. Basit bir site için genellikle tüm proje tek bir depoda tutulur. Ancak ayrı hizmetleriniz varsa (ön yüz, arka uç ve yapılandırma gibi), her birinin ayrı bir deposu olması daha iyidir.

.gitignore Dosyasını Ciddiye Alın

İlk adım, proje kökünde .gitignore dosyası oluşturmaktır. Bu dosya, hangi dosyaların depoya girmemesi gerektiğini belirler. Bir PHP veya Node.js sitesi için genellikle şunları yok sayarsınız:

# Bağımlılıklar
/vendor/
/node_modules/

# Ortam dosyaları
.env
.env.local

# Günlük dosyaları
*.log

# Geçici dosyalar
/tmp/
/cache/

Önemli not: .env dosyası veritabanı şifrelerini ve API anahtarlarını içerir. Bunu depoya commit ederseniz, sitenin güvenliği tehlikeye girer. Sunucuda bu dosyayı ayrıca ve manuel olarak oluşturun.

Sunucuda Depo Kurulumu

git pull ile dağıtım için önce depoyu sunucuya klonlamanız gerekir. İki durumunuz vardır: özel (Private) veya genel (Public) depo. Depo özel ise, sunucuda SSH anahtarı ayarlamanız gerekir.

Sunucuda SSH Anahtarı Oluşturma

Sunucuya giriş yapın ve aşağıdaki komutu çalıştırın:

ssh-keygen -t ed25519 -C "deploy@yourserver"

Genel anahtarı aşağıdaki komutla görüntüleyin ve depo ayarlarına (GitHub veya GitLab gibi) Deploy Keys bölümüne ekleyin:

cat ~/.ssh/id_ed25519.pub

Şimdi depoyu istediğiniz yola klonlayın. Örneğin, /var/www/mysite içinde bulunan bir site için:

cd /var/www
git clone git@github.com:username/mysite.git

Depo genel ise HTTPS kullanabilirsiniz, ancak SSH daha güvenlidir ve otomatik dağıtım için daha uygundur.

Branch'ler ile Dağıtım İş Akışı

En yaygın hatalardan biri, doğrudan main veya master branch'inden dağıtım yapmaktır. Bu tehlikelidir; çünkü her eksik commit anında ana siteye uygulanır. Dağıtım için özel bir branch kullanmak daha iyidir.

Önerilen Branch: production

Sadece kararlı sürümleri alan production adında ayrı bir branch oluşturun. İş akışı şu şekildedir:

1. Geliştirici develop branch'inde çalışır ve değişiklikleri commit eder.
2. Testten sonra develop branch'i production branch'ine merge edilir.
3. Sunucuda sadece production branch'inden pull alırsınız.

Sunucuda aktif branch'i değiştirin:

cd /var/www/mysite
git checkout production

Artık yeni bir sürüm dağıtmak istediğinizde şunu yapmanız yeterlidir:

git pull origin production

Bu komut, production branch'indeki son değişiklikleri sunucuya uygular. Sunucuda manuel olarak değiştirilmiş ve depo ile çakışan bir dosya varsa, Git hata verir ve sorunu çözmenizi ister.

git pull'da Yaygın Hataları Yönetme

Dağıtım sırasında hatalarla karşılaşabilirsiniz. Burada iki yaygın durumu inceliyoruz.

"local changes would be overwritten" Hatası

Bu hata, sunucuda bir dosyanın manuel olarak değiştirilmesi ve depodaki yeni değişikliklerle çakışması durumunda ortaya çıkar. Güvenli çözüm, yerel değişiklikleri saklamaktır:

git stash
git pull origin production
git stash pop

Manuel değişikliklere artık ihtiyaç yoksa, bunları atabilirsiniz:

git checkout -- .
git pull origin production

Not: İkinci komut tüm yerel değişiklikleri siler. Yalnızca önemli bir şeyin kaybolmayacağından emin olduğunuzda kullanın.

Clone Sırasında "Permission denied" Hatası

SSH kullanıyorsanız ve bu hatayı görüyorsanız, muhtemelen genel anahtarı doğru eklememişsinizdir. Anahtarı deponun Deploy Keys bölümüne eklediğinizden ve okuma (Read) izni verdiğinizden emin olun. Ayrıca bağlantıyı test edebilirsiniz:

ssh -T git@github.com

Başarılı bir mesaj alırsanız, sorun depo ayarlarındadır.

Webhook ile Dağıtımı Otomatikleştirme

Her seferinde sunucuya manuel olarak giriş yapıp git pull çalıştırmak istemiyorsanız, Webhook kullanabilirsiniz. Webhook, depo barındırma hizmetinin (GitHub gibi) push yapıldığında istek gönderdiği bir HTTP adresidir.

Otomatik Dağıtım için Basit Betik

Sunucuda pull komutunu çalıştıran basit bir PHP dosyası oluşturun. Örneğin, /var/www/mysite/deploy.php içinde:

<?php
// Sadece belirli adreslere izin verin
$allowed_ips = ['192.30.252.0/22'];
$ip = $_SERVER['REMOTE_ADDR'];

// pull komutunu çalıştır
$output = shell_exec('cd /var/www/mysite && git pull origin production 2>&1');
echo "<pre>{$output}</pre>";
?>

Ardından depo ayarlarında https://yoursite.com/deploy.php adresine bir Webhook ekleyin. Artık production branch'ine her push yaptığınızda, sunucu otomatik olarak en son sürümü pull eder.

Güvenlik Uyarısı: Bu betiği IP kısıtlaması olmadan bırakmayın. Adresi bilen herkes pull çalıştırabilir. En azından gizli bir token ekleyin:

<?php
if ($_GET['token'] !== 'YOUR_SECRET_TOKEN') {
    http_response_code(403);
    exit('Forbidden');
}
// Betiğin devamı
?>

Ve Webhook ayarlarına token'ı parametre olarak ekleyin.

Önceki Sürüme Dönme (Rollback)

Git'in dağıtımdaki en önemli avantajı hızlı geri dönüş imkânıdır. Yeni sürüm sorunluysa, önceki commit'e dönebilirsiniz. İki yönteminiz vardır:

Birinci Yöntem: git revert

Bu yöntem, sorunlu commit'in değişikliklerini geri alan yeni bir commit oluşturur. Depo geçmişi bozulmadan kalır:

git log --oneline -5
git revert HEAD

Ardından değişiklikleri push edin ve sunucuda pull alın.

İkinci Yöntem: git reset

Bu yöntem geçmişi yeniden yazar ve henüz push yapmadığınız durumlar için uygundur. Daha önce push yaptıysanız bu yöntemi kullanmayın, çünkü başkaları için depo geçmişini bozar:

git reset --hard HEAD~1

Sunucuda belirli bir commit'e dönmek istiyorsanız:

git checkout <commit-hash> -- .

Bu komut dosyaları o commit'in durumuna döndürür, ancak branch'i değiştirmez.

Profesyonel Dağıtım için Son İpuçları

Git ile dağıtım sürecini gerçekten profesyonel hale getirmek için şu ipuçlarını izleyin:

• Pull'dan önce her zaman veritabanı yedeği alın. Git yalnızca kodu yönetir, verileri değil.
• Pull'dan sonra site Composer veya npm kullanıyorsa, bağımlılıkları güncelleyin: composer install --no-dev veya npm ci --production.
• Kullanıcıların yüklediği dosyaları (görseller gibi) depoda tutmayın. Bunları /var/www/mysite/uploads gibi ayrı bir yola koyun ve .gitignore içinde yok sayın.
• Büyük siteler için dağıtımı önce bir test sunucusunda yapın, ardından ana sunucuda yapın. Git bunu kolaylaştırır: her iki sunucuda da aynı branch'i pull etmeniz yeterlidir.

Bu süreci sorunsuz çalıştıracak bir altyapı arıyorsanız, ServerNet web hosting ve bulut sunucu hizmetleri uygun bir seçenek olabilir; ancak nihai karar size aittir ve bu eğitim her hizmetten bağımsız olarak uygulanabilir.

Bu yöntemle site dağıtımı artık riskli bir işlem değil; öngörülebilir, test edilebilir ve geri alınabilir bir süreçtir. Bu iş akışını bir kez kurun ve getirdiği huzurun tadını çıkarın.