آموزش گیت برای استقرار سایت؛ از مخزن تا دیپلوی روی سرور

چرا گیت برای استقرار سایت ضروری است؟

اگر هنوز فایل‌های سایت را با FTP یا پنل مدیریت فایل روی سرور آپلود می‌کنید، احتمالاً با این صحنه آشنا هستید: یک تغییر کوچک در کد، یک فایل از قلم افتاده، و سایت از کار می‌افتد. گیت (Git) این آشفتگی را به یک فرایند قابل‌ردیابی و برگشت‌پذیر تبدیل می‌کند. با گیت، هر تغییر در کد یک «کامیت» (commit) با پیام مشخص و شناسه یکتا می‌گیرد؛ اگر چیزی خراب شد، می‌توانید دقیقاً به نسخه قبلی برگردید.

در این آموزش فرض می‌کنیم که با مفاهیم پایه گیت آشنا هستید و می‌خواهید آن را برای استقرار سایت روی یک سرور لینوکسی (مثل اوبونتو یا دبیان) به کار بگیرید. هدف نهایی این است که با یک دستور git pull روی سرور، آخرین نسخه سایت را مستقر کنید؛ بدون نیاز به آپلود دستی فایل‌ها.

ساختار پیشنهادی مخزن برای استقرار

قبل از هر چیز، باید تصمیم بگیرید که مخزن گیت شما چه ساختاری داشته باشد. برای یک سایت ساده، معمولاً کل پروژه در یک مخزن نگهداری می‌شود. اما اگر چند سرویس مجزا دارید (مثل فرانت‌اند، بک‌اند و کانفیگ)، بهتر است هر کدام مخزن جداگانه داشته باشند.

فایل .gitignore را جدی بگیرید

اولین قدم، ایجاد فایل .gitignore در ریشه پروژه است. این فایل تعیین می‌کند کدام فایل‌ها نباید وارد مخزن شوند. برای یک سایت PHP یا Node.js، معمولاً این موارد را نادیده می‌گیرید:

# وابستگی‌ها
/vendor/
/node_modules/

# فایل‌های محیطی
.env
.env.local

# فایل‌های لاگ
*.log

# فایل‌های موقت
/tmp/
/cache/

نکته مهم: فایل .env حاوی رمزهای دیتابیس و کلیدهای API است. اگر آن را در مخزن commit کنید، امنیت سایت به خطر می‌افتد. روی سرور، این فایل را جداگانه و به صورت دستی ایجاد کنید.

راه‌اندازی مخزن روی سرور

برای استقرار با git pull، ابتدا باید مخزن را روی سرور کلون کنید. دو حالت دارید: مخزن خصوصی (Private) یا عمومی (Public). اگر مخزن خصوصی است، باید SSH key را روی سرور تنظیم کنید.

ایجاد SSH key روی سرور

وارد سرور شوید و دستور زیر را اجرا کنید:

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

کلید عمومی را با دستور زیر نمایش دهید و آن را در تنظیمات مخزن (مثل GitHub یا GitLab) در بخش Deploy Keys اضافه کنید:

cat ~/.ssh/id_ed25519.pub

حالا مخزن را در مسیر دلخواه کلون کنید. مثلاً برای یک سایت که در /var/www/mysite قرار می‌گیرد:

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

اگر مخزن عمومی است، می‌توانید از HTTPS استفاده کنید، اما SSH امن‌تر و برای استقرار خودکار مناسب‌تر است.

گردش کار استقرار با برنچ‌ها

یکی از رایج‌ترین اشتباهات، استقرار مستقیم از برنچ main یا master است. این کار خطرناک است؛ چون هر کامیت ناقصی بلافاصله روی سایت اصلی اعمال می‌شود. بهتر است از یک برنچ مخصوص استقرار استفاده کنید.

برنچ پیشنهادی: production

یک برنچ جداگانه به نام production بسازید که فقط نسخه‌های پایدار را دریافت می‌کند. گردش کار به این شکل است:

1. توسعه‌دهنده روی برنچ develop کار می‌کند و تغییرات را commit می‌کند.
2. پس از تست، برنچ develop به production merge می‌شود.
3. روی سرور، فقط از برنچ production pull می‌گیرید.

روی سرور، برنچ فعال را تغییر دهید:

cd /var/www/mysite
git checkout production

حالا هر بار که می‌خواهید نسخه جدیدی مستقر کنید، کافی است:

git pull origin production

این دستور، آخرین تغییرات برنچ production را روی سرور اعمال می‌کند. اگر فایلی به صورت دستی روی سرور تغییر کرده باشد که با مخزن تداخل داشته باشد، گیت خطا می‌دهد و از شما می‌خواهد مشکل را حل کنید.

مدیریت خطاهای رایج در git pull

هنگام استقرار، ممکن است با خطاهایی مواجه شوید. در اینجا دو مورد رایج را بررسی می‌کنیم.

خطای «local changes would be overwritten»

این خطا وقتی رخ می‌دهد که فایلی روی سرور به صورت دستی تغییر کرده و با تغییرات جدید مخزن تداخل دارد. راه‌حل امن این است که تغییرات محلی را ذخیره کنید:

git stash
git pull origin production
git stash pop

اگر تغییرات دستی دیگر لازم نیست، می‌توانید آن‌ها را دور بریزید:

git checkout -- .
git pull origin production

توجه: دستور دوم همه تغییرات محلی را حذف می‌کند. فقط وقتی استفاده کنید که مطمئن هستید چیزی مهم از دست نمی‌رود.

خطای «Permission denied» هنگام clone

اگر از SSH استفاده می‌کنید و این خطا را می‌بینید، احتمالاً کلید عمومی را درست اضافه نکرده‌اید. مطمئن شوید که کلید را در بخش Deploy Keys مخزن اضافه کرده‌اید و به آن اجازه خواندن (Read) داده‌اید. همچنین می‌توانید اتصال را تست کنید:

ssh -T git@github.com

اگر پیام موفقیت آمیز دریافت کردید، مشکل از تنظیمات مخزن است.

اتوماتیک‌سازی استقرار با Webhook

اگر نمی‌خواهید هر بار به صورت دستی روی سرور لاگین کنید و git pull اجرا کنید، می‌توانید از Webhook استفاده کنید. Webhook یک آدرس HTTP است که سرویس میزبانی مخزن (مثل GitHub) وقتی push انجام می‌شود، به آن درخواست می‌فرستد.

اسکریپت ساده برای استقرار خودکار

یک فایل PHP ساده روی سرور ایجاد کنید که دستور pull را اجرا کند. مثلاً در /var/www/mysite/deploy.php:

<?php
// فقط از آدرس‌های مشخص اجازه دهید
$allowed_ips = ['192.30.252.0/22'];
$ip = $_SERVER['REMOTE_ADDR'];

// اجرای دستور pull
$output = shell_exec('cd /var/www/mysite && git pull origin production 2>&1');
echo "<pre>{$output}</pre>";
?>

سپس در تنظیمات مخزن، یک Webhook به آدرس https://yoursite.com/deploy.php اضافه کنید. حالا هر بار که روی برنچ production push کنید، سرور به صورت خودکار آخرین نسخه را pull می‌کند.

هشدار امنیتی: این اسکریپت را بدون محدودیت IP رها نکنید. هر کسی که آدرس را بداند می‌تواند pull را اجرا کند. حداقل یک توکن مخفی اضافه کنید:

<?php
if ($_GET['token'] !== 'YOUR_SECRET_TOKEN') {
    http_response_code(403);
    exit('Forbidden');
}
// ادامه اسکریپت
?>

و در تنظیمات Webhook، توکن را به عنوان پارامتر اضافه کنید.

بازگشت به نسخه قبلی (Rollback)

مهم‌ترین مزیت گیت در استقرار، امکان بازگشت سریع است. اگر نسخه جدید مشکل داشت، می‌توانید به کامیت قبلی برگردید. دو روش دارید:

روش اول: git revert

این روش یک کامیت جدید ایجاد می‌کند که تغییرات کامیت مشکل‌دار را خنثی می‌کند. تاریخچه مخزن دست‌نخورده می‌ماند:

git log --oneline -5
git revert HEAD

سپس تغییرات را push کنید و روی سرور pull بگیرید.

روش دوم: git reset

این روش تاریخچه را بازنویسی می‌کند و برای مواقعی مناسب است که هنوز push نکرده‌اید. اگر قبلاً push کرده‌اید، از این روش استفاده نکنید چون تاریخچه مخزن را برای دیگران خراب می‌کند:

git reset --hard HEAD~1

روی سرور، اگر می‌خواهید به یک کامیت خاص برگردید:

git checkout <commit-hash> -- .

این دستور فایل‌ها را به حالت آن کامیت برمی‌گرداند، اما برنچ را تغییر نمی‌دهد.

نکات نهایی برای استقرار حرفه‌ای

برای اینکه فرایند استقرار با گیت واقعاً حرفه‌ای شود، این نکات را رعایت کنید:

• همیشه قبل از pull، از دیتابیس بکاپ بگیرید. گیت فقط کد را مدیریت می‌کند، نه داده‌ها را.
• بعد از pull، اگر سایت از Composer یا npm استفاده می‌کند، وابستگی‌ها را به‌روزرسانی کنید: composer install --no-dev یا npm ci --production.
• فایل‌های آپلودی کاربران (مثل تصاویر) را در مخزن نگه ندارید. آن‌ها را در مسیر جداگانه‌ای مثل /var/www/mysite/uploads قرار دهید و در .gitignore نادیده بگیرید.
• برای سایت‌های بزرگ، استقرار را روی یک سرور تست انجام دهید و بعد روی سرور اصلی. گیت این کار را ساده می‌کند: فقط کافی است برنچ یکسان را روی هر دو سرور pull کنید.

اگر به دنبال زیرساختی هستید که این فرایند را بدون دردسر اجرا کند، سرویس‌های میزبانی وب و سرور ابری سرورنت می‌توانند گزینه مناسبی باشند؛ اما تصمیم نهایی با شماست و این آموزش مستقل از هر سرویسی قابل اجراست.

با این روش، استقرار سایت دیگر یک عملیات پرخطر نیست؛ بلکه یک فرایند قابل پیش‌بینی، قابل تست و قابل بازگشت است. کافی است یک بار این گردش کار را راه بیندازید و از آرامش خاطر آن لذت ببرید.