Git ile Otomatik Deploy: cPanel, Plesk ve VPS’te Adım Adım Kurulum

Web projeleriniz büyüdükçe, canlı ortama kod göndermek (deploy) en zayıf halkalardan biri haline gelir. Elle FTP ile dosya atmak, yanlış klasöre yüklemek, eski dosyaları silmeyi unutmak veya son komiti değil de bir önceki komiti göndermek; hepsi gerçek hayatta gördüğümüz, can sıkıcı hatalar. Oysa Git tabanlı otomatik deploy iş akışları ile bu süreci hem tekrarlanabilir hem de geri alınabilir hale getirmek mümkün.

Bu yazıda, Git ile otomatik deploy mantığını sade bir dille anlatıp, üç farklı senaryo üzerinden adım adım ilerleyeceğiz: cPanel kullanan paylaşımlı hosting hesapları, Plesk panelli sunucular ve tam kontrol sahibi olduğunuz VPS’ler. Amacımız; ister basit bir WordPress teması, ister Laravel/Node.js tabanlı gelişmiş bir uygulama olsun, kodu tek komutla veya otomatik olarak güvenle canlıya alabileceğiniz bir düzen kurmanıza yardımcı olmak.

DCHost ekibi olarak, müşterilerimizin projelerinde Git tabanlı yayın iş akışlarını oldukça sık kurguluyoruz. Bu rehberi, sahada gerçekten çalışan pratikleri süzerek hazırladık. Yazının sonunda; kendi ortamınıza en uygun yaklaşımı seçebilecek, riskli manuel adımları minimuma indirip, küçük bir hatanın tüm siteyi bozmasını engelleyecek bir yapı kurmuş olacaksınız.

Git ile Otomatik Deploy Kurmanın Avantajları

Önce motivasyonu netleştirelim: Neden Git ile otomatik deploy için zaman harcamaya değer?

• Tekrarlanabilirlik: Aynı komutu çalıştırdığınızda her zaman aynı sonucu alırsınız. “Ben bunu geçen sefer nasıl yapmıştım?” sorusu ortadan kalkar.
• Geri dönüş (rollback) kolaylığı: Yeni sürüm sorun çıkardıysa, bir önceki etikete veya komite dönmek birkaç komutla mümkündür.
• İnsan hatasını azaltma: FTP ile yanlış klasöre dosya atmak, bazı dosyaları unutmak, staging kodunu canlıya karıştırmak gibi riskler ciddi oranda düşer.
• Sürüm takibi: Canlıda hangi commit’in çalıştığını bilirsiniz. Hata takibi ve log incelemesi çok daha kolay hale gelir.
• Takım çalışması: Geliştiriciler ortak Git deposuna push eder, deploy süreci standart bir pipeline üzerinden akar; kişiye bağımlılık azalır.
• Staging–canlı ayrımı: Aynı Git deposundan staging ve prod ortamlara, farklı branch’ler veya tag’ler üzerinden kontrolü sizde olan bir akış kurabilirsiniz. Bu konuyu daha önce geliştirme–staging–canlı yolculuğu yazımızda ayrıntılı ele almıştık.

Kısacası, Git ile otomatik deploy; hız kadar güven ve <strongizlenebilirlik kazandırır. Özellikle e-ticaret, yoğun trafikli blog/haber siteleri veya SaaS uygulamaları için bu yapı artık “lüks” değil, neredeyse zorunluluk haline geldi.

Temel Mimari: Git Deposu ve Sunucu Arasındaki Akış

cPanel, Plesk veya çıplak bir VPS kullanıyor olmanızdan bağımsız olarak, Git tabanlı deploy’un temel fikri aynıdır:

1. Geliştiriciler lokal repo üzerinde çalışır ve değişiklikleri commit eder.
2. Değişiklikler bir merkezi uzak repoya (örneğin kendi Git sunucunuz veya Git hizmeti) push edilir.
3. Sunucuda, bu merkezi repoya bağlı bir deploy repo bulunur.
4. Bir hook, cron job veya panel özelliği sayesinde, yeni commit geldiğinde sunucu tarafındaki kodlar güncellenir.

Bu akışın, panel türüne göre farklı uygulanış biçimleri vardır:

• cPanel’de: Genellikle SSH üzerinden bir bare repo ve post-receive hook ile çalışırız.
• Plesk’te: Dahili Git uzantısı, push geldiğinde otomatik olarak git pull ve deploy yapabilir.
• VPS’te: Tamamen size ait bir mimari kurar, hatta sıfır kesinti CI/CD gibi gelişmiş senaryoları dahi uygulayabilirsiniz.

Şimdi her bir ortam için somut adımlara geçelim.

cPanel Üzerinde Git ile Otomatik Deploy

Paylaşımlı hosting kullanıyorsanız veya DCHost üzerinde cPanel’li bir sunucunuz varsa, genellikle SSH erişiminiz ve home dizininde çalışabileceğiniz alanınız vardır. Bu, Git ile otomatik deploy kurmak için fazlasıyla yeterli.

1. cPanel’de Dizayn: Bare Repo ve Çalışma Dizini

Tipik senaryo şöyle olabilir:

• Alan adınızın doküman kökü: /home/kullanici/public_html
• Bare repo: /home/kullanici/repos/proje.git

Önce SSH ile hesabınıza bağlanın ve repo klasörünü oluşturun:

mkdir -p ~/repos/proje.git
cd ~/repos/proje.git
git init --bare

Bare repo, çalışma dosyası barındırmaz; yalnızca Git objelerini içerir. Bu repo, lokal makinenizden push alacak “merkez” görevi görür.

2. post-receive Hook ile Otomatik Çekme ve Deploy

Şimdi sunucuda, bare repo’ya her push geldiğinde kodu public_html içine açacak bir hook yazalım. hooks klasörüne girin:

cd ~/repos/proje.git/hooks
nano post-receive

İçeriğe şu basit script’i ekleyebilirsiniz:

#!/bin/bash
GIT_WORK_TREE=/home/kullanici/public_html
GIT_DIR=/home/kullanici/repos/proje.git

cd "$GIT_WORK_TREE"
# Gerekirse bakım moduna al, cache temizle vb.
/usr/bin/git --work-tree="$GIT_WORK_TREE" --git-dir="$GIT_DIR" checkout -f main

Burada:

• main branch’ini canlıya alıyoruz (siz master veya farklı bir branch kullanıyorsanız onu yazın).
• checkout -f ile çalışma dizinini zorla güncelliyoruz; local değişiklik kalmamasını istiyoruz.

Dosyayı kaydedip, çalıştırılabilir hale getirin:

chmod +x post-receive

3. Lokal Geliştirme Ortamını Sunucuya Bağlama

Artık lokal bilgisayarınızdaki projeyi bu bare repo’ya push edebiliriz. Lokal repoda aşağıdaki komutları çalıştırın:

git remote add production ssh://kullanici@sunucu-adresi:22/home/kullanici/repos/proje.git

İlk deploy için:

git push production main

Bu push işlemi tamamlandığında, sunucudaki post-receive hook tetiklenecek ve kodunuz public_html içine açılacaktır. Bundan sonra her git push production main komutu, canlıya deploy anlamına gelir.

4. Örnek Senaryo: WordPress Child Tema veya Eklenti Deploy’u

WordPress tabanlı bir siteniz varsa, tüm WordPress çekirdeğini değil; sık değişen kısımları Git ile yönetmek daha pratik olabilir:

• Child tema klasörünüzü (wp-content/themes/proje-child) Git ile takip edebilirsiniz.
• Özel bir eklenti (örneğin siteye özel fonksiyonlarınızı içeren wp-content/plugins/proje-custom) için ayrı bir repo oluşturabilirsiniz.

Bu yaklaşım, WordPress çekirdeğinin veya üçüncü parti eklentilerin güncellemelerini panelden yönetmenize imkân tanırken, sizin kodunuzu Git ile güvenle taşımanızı sağlar. WordPress güncellemeleri tarafında ise WooCommerce güncellemelerini güvenle yapmak yazımızdaki yöntemleri Git deploy ile birleştirerek daha güvenli bir süreç kurabilirsiniz.

5. Staging–Canlı Ayrımı ve cPanel’de Alt Alan Adı

Çoğu projede, önce staging ortamda test edip sonra canlıya almak isteyeceksiniz. cPanel’de sık kullanılan model:

• staging.ornekalanadi.com için bir alt alan adı ve ayrı doküman kökü açmak.
• Aynı bare repo’dan iki farklı working copy yaratmak: biri staging klasörüne, diğeri public_html içine.
• post-receive içinde branch’e göre farklı dizinlere deploy yapmak (örneğin develop → staging, main → prod).

WordPress tarafında staging ortamı kurma konusunda daha detaylı bir rehbere ihtiyacınız varsa, cPanel’de alt alan adıyla staging ortamı anlatımına göz atabilirsiniz.

Plesk Üzerinde Git ile Otomatik Deploy

Plesk, Git entegrasyonunu gömülü bir özellik olarak sunduğu için, pek çok durumda hook veya ek script yazmanıza bile gerek kalmaz. DCHost üzerinde Plesk panelli bir VPS veya dedicated sunucunuz varsa, aşağıdaki adımlarla pratik bir otomatik deploy kurabilirsiniz.

1. Plesk’te Git Deposu Oluşturma

Plesk kontrol paneline giriş yaptıktan sonra:

1. İlgili domain’in üzerine tıklayın.
2. Git veya Git Repositories menüsünü açın.
3. “Add Repository” ile yeni bir repo tanımlayın.

Burada iki ana seçenek göreceksiniz:

• Remote Git repository: Kendi Git sunucunuzdan veya bir Git hizmetinden çekmek için.
• Local Git repository: Sunucunun kendisinde repo tutmak için (çoğu zaman remote ile çalışmak daha pratiktir).

Genellikle, geliştiricilerin push ettiği merkezi repoyu remote olarak Plesk’e tanımlayıp, oradan otomatik git pull yaptırmak en temiz yoldur.

2. Deploy Modunu Seçmek: Manuel mi, Otomatik mi?

Plesk’te repo tanımlarken veya sonrasında ayarlarda şu seçenekleri görebilirsiniz:

• Deploy to the domain’s document root: Kod doğrudan httpdocs gibi doküman köküne açılır.
• Deploy to a subdirectory: Uygulamanız başka bir klasöre açılır; örneğin app, api vb.
• By clicking “Deploy”: Manuel deploy; Plesk arayüzünde butona basınca yayınlanır.
• On push: Git push geldiğinde otomatik deploy; genellikle webhook veya Plesk’in polling mekanizması ile çalışır.

Bizim hedefimiz otomatik deploy olduğu için, çoğunlukla “On push” modunu seçmek isteyeceksiniz. Bunun için merkezi repo tarafında Plesk’in verdiği URL’ye bir webhook tanımlamanız gerekir. Böylece her push sonrası Plesk haberdar olur ve otomatik olarak git pull + deploy yapar.

3. PHP/Laravel Örneği: Plesk’te Deploy Sonrası Komutlar

Plesk’in Git entegrasyonunda, deploy sonrası otomatik çalışacak komutlar tanımlayabilirsiniz. Örneğin bir Laravel uygulaması için her deploy sonrası:

• composer install --no-dev --optimize-autoloader
• php artisan migrate --force
• php artisan config:cache

gibi komutları tetiklemek isteyebilirsiniz.

Plesk Git ayarlarında “Additional deployment actions” veya benzeri bir alan görüyorsanız, bu komutları buraya ekleyebilirsiniz. Daha detaylı bir Laravel prod ortam rehberi arıyorsanız, Laravel prod ortam optimizasyonu yazımızı da bu yapı ile birlikte okuyabilirsiniz.

4. Plesk’te Staging Ortamı ve Branch Yönetimi

Plesk, aynı domain için birden fazla Git repo veya aynı repo için farklı hedef dizinler kullanmanıza izin verir. Bu sayede:

• main branch’ini canlıya,
• develop branch’ini staging alt alanına,

deploy edecek iki ayrı repo tanımı oluşturabilirsiniz. Staging domain’inizi örneğin staging.ornekalanadi.com olarak kurgulayıp, doküman kökünü farklı bir klasöre ayarlayarak üretim öncesi son kontrol ortamını kurabilirsiniz.

VPS Üzerinde Git Tabanlı Deploy Mimarisi

VPS veya dedicated sunucuda tam yetkiniz olduğunda, Git deploy mimarisini çok daha esnek ve güçlü şekilde tasarlayabilirsiniz. DCHost’un NVMe diskli Linux VPS’leri üzerinde en sık kurduğumuz yapı; özel bir deploy kullanıcısı, bare repo, çalışma dizininde sürüm klasörleri ve sembolik link ile sıfıra yakın kesinti sağlayan bir mimari.

1. Deploy Kullanıcısı Oluşturma

Önce root ile bağlanıp, ayrı bir kullanıcı açalım:

adduser deploy
usermod -aG www-data deploy   # web sunucusu grubuna ekleyebilirsiniz

Ardından SSH anahtarınızı bu kullanıcının ~/.ssh/authorized_keys dosyasına ekleyin. Böylece repo push/pull işlemlerini root olmadan yönetebilirsiniz.

2. Bare Repo ve Sürüm Klasörleri

Deploy kullanıcısıyla giriş yapıp dizinleri oluşturalım:

mkdir -p ~/repos/proje.git
mkdir -p ~/apps/proje/releases
mkdir -p ~/apps/proje/shared
cd ~/repos/proje.git
git init --bare

Burada:

• repos/proje.git: Bare repo; push buraya gelir.
• apps/proje/releases: Her deploy için ayrı bir sürüm klasörü.
• apps/proje/shared: Log, upload gibi paylaşılan klasörler.

3. Zero-Downtime’a Yakın Deploy İçin post-receive Hook

post-receive hook’unda, her deploy’da yeni bir sürüm klasörü oluşturup sembolik link’i güncelleyebilirsiniz. Örneğin:

cd ~/repos/proje.git/hooks
nano post-receive

İçerik:

#!/bin/bash
set -e

APP_DIR=/home/deploy/apps/proje
RELEASES_DIR="$APP_DIR/releases"
SHARED_DIR="$APP_DIR/shared"
NOW=$(date +%Y%m%d%H%M%S)
NEW_RELEASE="$RELEASES_DIR/$NOW"

mkdir -p "$NEW_RELEASE"
GIT_WORK_TREE="$NEW_RELEASE" GIT_DIR=/home/deploy/repos/proje.git 
  git checkout -f main

# Paylaşılan klasörleri bağla (örnek)
ln -sfn "$SHARED_DIR/storage" "$NEW_RELEASE/storage"

# Gerekirse composer/npm, migrate vs.
cd "$NEW_RELEASE"
# composer install --no-dev --optimize-autoloader
# php artisan migrate --force

# Sembolik link ile canlı sürümü güncelle
ln -sfn "$NEW_RELEASE" "$APP_DIR/current"

Dosyayı çalıştırılabilir yapın:

chmod +x post-receive

Artık ~/apps/proje/current her zaman en güncel sürümü işaret ediyor olacak. Nginx veya Apache sanal host’unuzu bu current klasörünü doküman kökü olarak kullanacak şekilde ayarlarsanız, deploy sırasında mevcut istekler eski sürümden yanıtlanırken, yeni istekler saniyeler içinde yeni sürüme yönlenir. Bu mimariyi daha da detaylandırmak isterseniz, sıfır kesinti CI/CD rehberimizi mutlaka inceleyin.

4. Lokal Repo’dan VPS’e Push

Lokal gelişim ortamınızda, VPS’e bir remote ekleyin:

git remote add production ssh://deploy@vps-ip-adresi/home/deploy/repos/proje.git

İlk deploy:

git push production main

Bu push tamamlandığında post-receive tetiklenecek, yeni bir sürüm klasörü oluşturulacak ve current link’i güncellenecek. Böylece manuel FTP veya kopyalama ile uğraşmadan, tek komutla canlıya kod göndermiş olursunuz.

5. Geri Dönüş (Rollback) Stratejisi

Her deploy’un kendi klasöründe durması, rollback’i de son derece basit hale getirir. Örneğin bir önceki klasöre dönmek için:

cd /home/deploy/apps/proje/releases
ls -1    # Sürüm klasörlerini görün

Ardından istediğiniz sürümü seçip:

ln -sfn /home/deploy/apps/proje/releases/20241202153000 /home/deploy/apps/proje/current

komutuyla sembolik link’i geriye alabilirsiniz. İsterseniz bu işlemi küçük bir rollback.sh script’i haline getirip, etiket adıyla otomatik eşleştirecek bir sistem de geliştirebilirsiniz.

Gizli Bilgiler, .env ve Güvenlik Konuları

Git ile otomatik deploy kurarken en sık gördüğümüz hatalardan biri, .env dosyası gibi gizli bilgilerin repoya dahil edilmesi. Bu, hem güvenlik hem de operasyonel açıdan ciddi risk oluşturur.

1. .gitignore ve Ortam Dosyaları

Öncelikle .gitignore dosyanıza en azından şunları ekleyin:

.env
.env.*
/storage/
/node_modules/
/vendor/

.env dosyasını her ortamda (lokal, staging, prod) ayrı ayrı oluşturun ve Git’e asla eklemeyin. VPS tarafında ortam değişkenlerini:

• systemd unit dosyasında Environment= satırlarıyla,
• veya web sunucusu (Nginx/Apache) konfigürasyonunda,

tanımlamak daha güvenlidir. VPS’te gizli bilgiler için daha gelişmiş bir yaklaşım arıyorsanız, VPS’te secrets yönetimi rehberimiz tam bu konuya odaklanıyor.

2. Dosya İzinleri ve Sahiplik

Deploy sonrasında dosya izinlerinin doğru olması, özellikle PHP tabanlı projelerde kritik önem taşır:

• Uygulama dosyaları genellikle okunabilir olmalı; yazılabilir olmamalı.
• Cache, log, upload klasörleri ise web sunucusunun yazma iznine sahip olmalı.

VPS senaryosunda, post-receive içinde chown ve chmod komutları ile bu izinleri her deploy sonrası otomatik olarak düzenleyebilirsiniz.

3. SSH Anahtarları ve Yetkiler

Git ile deploy’un en güvenli yöntemi, SSH anahtarı kullanmaktır. Paylaşımlı hosting veya cPanel senaryosunda:

• cPanel’in “SSH Access” bölümünden public key’inizi ekleyin.
• Gerekirse anahtarı “authorized” hale getirin.
• Şifreli root/ana kullanıcı parolası ile değil, sadece anahtar ile giriş yapmaya çalışın.

VPS’lerde ise, SSH güvenliği rehberimizde anlattığımız FIDO2 anahtarları ve anahtar rotasyonu gibi yöntemlerle erişimi çok daha sağlam hale getirebilirsiniz.

Hangi Senaryoda cPanel, Plesk veya VPS Daha Mantıklı?

Elinizdeki proje ve ekibin yetkinlikleri, hangi yaklaşımın sizin için ideal olduğunu belirler.

cPanel ile Git Deploy Ne Zaman Yeterli?

• Küçük/orta ölçekli WordPress veya PHP tabanlı siteleriniz varsa,
• Tek geliştirici veya küçük bir ekiple çalışıyorsanız,
• SSH erişimi var ama root yetkisi yoksa,

bare repo + post-receive modeli fazlasıyla iş görür. DCHost’un cPanel’li hosting ve reseller çözümlerinde bu yapıyı rahatlıkla uygulayabilirsiniz. Birden fazla müşteri sitesini yöneten ajanslar için, Git tabanlı deploy’u ajanslara özel hosting mimarisi yazımızdaki önerilerle birlikte düşünmek iyi bir başlangıç olur.

Plesk ile Git Deploy Hangi Projelere Uygun?

• PHP/Laravel başta olmak üzere, .NET veya Node.js gibi çoklu stack yönetiyorsanız,
• Panel üzerinden otomatik deploy’u daha görsel ve yönetilebilir buluyorsanız,
• Deploy sonrası komutları panelden tanımlamak istiyorsanız,

Plesk’in Git uzantısı oldukça konforlu bir deneyim sunar. DCHost üzerinde Plesk’li VPS veya dedicated sunucu tercih ederek, hem panel kolaylığını hem de Git tabanlı otomatik deploy’u bir arada kullanabilirsiniz.

Tam Esneklik İçin VPS’te Git Deploy

Aşağıdaki özelliklerden birkaçına ihtiyaç duyuyorsanız, VPS tarafındaki mimariyi düşünme zamanı gelmiş demektir:

• Sembolik link ile zero-downtime’a yakın deploy,
• Birden fazla uygulama, mikroservis veya özel portta çalışan servisler,
• Özel firewall, WAF, mTLS gibi gelişmiş güvenlik politikaları,
• Ölçeklenebilir kaynaklar (vCPU, RAM, NVMe disk) ve esnek altyapı.

Bu noktada Git deploy’u; Nginx, PHP-FPM, Redis, veritabanı kümeleri ve izleme araçları ile entegre, daha büyük resmin bir parçası olarak düşünmek gerekir. DCHost’un VPS hosting rehberi ve farklı uygulama türlerine özel yazılarımız (Laravel, Node.js, WooCommerce vb.) ile birlikte okuduğunuzda, uçtan uca bir üretim mimarisi planlayabilirsiniz.

Sonuç: Git ile Otomatik Deploy’u Bugün Kurmaya Değer mi?

Git tabanlı otomatik deploy, ilk bakışta birkaç ekstra adım gibi görünebilir; ancak gerçek hayatta kazandırdığı süre ve azalan hata oranı, bu maliyeti fazlasıyla geri öder. Bugün küçük görünen bir proje bile, birkaç ay sonra onlarca commit, eklenti, konfigürasyon ve yama içeren karmaşık bir yapıya dönüşebiliyor. Böyle bir ortamda manuel FTP veya kopyalama ile ilerlemek, hem geliştirme ekibini hem de altyapıyı gereksiz risklere açık bırakıyor.

Bu rehberde; cPanel, Plesk ve VPS için Git ile otomatik deploy iş akışlarını adım adım ele aldık. Artık elinizde üç temel araç var: paylaşımlı hostingte pratik bare repo + hook yaklaşımı, Plesk’in dahili Git uzantısının sunduğu konfor ve VPS üzerinde tam kontrolle kurabileceğiniz, neredeyse kesintisiz çalışan gelişmiş bir dağıtım mimarisi.

Eğer DCHost üzerinde yeni bir proje planlıyorsanız veya mevcut sitenizi Git tabanlı deploy yapısına taşımak istiyorsanız, ihtiyaç duyduğunuz cPanel hosting, Plesk’li VPS, NVMe diskli Linux VPS, dedicated sunucu veya colocation çözümlerini birlikte değerlendirebiliriz. Altyapı tarafını biz stabilize ederken, siz Git repo’nuzdan tek komutla, güvenle üretime kod göndermenin rahatlığını yaşayabilirsiniz.