راهنمای کامل استفاده از GitHub برای توسعهٔ وردپرس

اگر تا به حال برای هماهنگی کدهای قالب یا افزونه تان در تیم تان با تداخل هات و از دست رفتن نسخه ها دست و پنجه نرم کرده اید، تنها نیستید. GitHub، همانند یک دفتر کار دیجیتالی، امکان ردیابی دقیق تغییرات، مدیریت شاخه ها و همکاری بی وقفه را برای توسعه دهندگان وردپرس فراهم می کند.

در این مقاله، با یک رویکرد گام به گام، نحوهٔ تنظیم مخزن، افزودن کلیدهای SSH و به کارگیری عملگرهای اصلی گیت را برای پروژه های وردپرسی شما شرح می دهیم. همچنین نکات عملی برای ادغام خودکار با محیط های تست، استفاده از Pull Requestهای ساختارمند و نگهداری مستندات کد را بررسی می کنیم. با پیروی از این راهنمای تخصصی، می توانید به سرعت جریان کاری تان را بهبود ببخشید و از اشتباهات رایج در مدیریت نسخه گذاری جلوگیری کنید.

فهرست مطالب

• نصب گیت و تنظیمات اولیه
• ایجاد مخزن برای پروژه وردپرس
• پیاده سازی استراتژی شاخه ها و مرور
• همگام سازی تغییرات با GitHub Actions
• به کارگیری Pull Request برای بازبینی کد
• استقرار خودکار تم و افزونه ها
• سوالات متداول

نصب گیت و تنظیمات اولیه

قبل از هر کاری باید اطمینان حاصل کنید که Git روی سیستم عامل شما نصب شده است؛ این ابزار کنترل نسخه پایهٔ اکثر گردش کاری در توسعهٔ WordPress است. در ویندوز می توانید از Git for Windows استفاده کنید که یک نصب کنندهٔ گرافیکی دارد، در macOS می توانید از Homebrew (دستور brew install git) یا بستهٔ پیش فرض Xcode استفاده کنید، و در لینوکس معمولاً با مدیر بستهٔ توزیع (مانند apt یا dnf) نصب می شود.

در ادامه یک سری دستور ساده برای نصب Git در هر پلتفرم آورده شده است:

1. Windows: دانلود Git‑64-bit.exe از git-scm.com و اجرای فایل نصب؛ گزینه های پیش فرض مناسب اکثر کاربران هستند.
2. macOS:brew install git یا نصب Xcode Command Line Tools با xcode-select --install.
3. Linux (Debian/Ubuntu):sudo apt update && sudo apt install git.

پس از نصب، قدم بعدی پیکربندی اولیه است. این تنظیمات یک بار برای تمام مخازن شما کافی است و شامل نام کاربری و ایمیلی می شود که به هر تعهد (commit) افزوده می شود. برای تنظیم این موارد می توانید از دستورات زیر استفاده کنید:

برای اتصال امن به مخازن GitHub، بهتر است یک کلید SSH تولید کنید. با اجرای ssh-keygen -t ed25519 -C "email@example.com" یک جفت کلید عمومی/خصوصی ساخته می شود؛ کلید عمومی (فایل ~/.ssh/id_ed25519.pub) را به بخش SSH and GPG keys در تنظیمات حساب GitHub اضافه کنید. پس از افزودن کلید، با دستور ssh -T git@github.com می توانید اتصال را تست کنید؛ پیام «Hi username! You’ve successfully authenticated…» نشان می دهد که همه چیز آماده است.

در نهایت، یک نکتهٔ عملی: قبل از اولین push به مخزن، یک مخزن محلی آزمایشی ایجاد کنید (git init demo‑plugin && cd demo‑plugin && touch readme.txt && git add . && git commit -m "Initial commit") و سپس آن را به یک مخزن خالی در GitHub متصل کنید (git remote add origin git@github.com:yourname/demo‑plugin.git). این کار به شما اجازه می دهد که همهٔ تنظیمات را در یک محیط کم خطر آزمایش کنید و از بروز خطاهای ناخواسته در پروژهٔ اصلی جلوگیری کنید.

ایجاد مخزن برای پروژه وردپرس

برای شروع کار با گیت در یک پروژهٔ وردپرس، اولین قدم ایجاد یک مخزن محلی است. ابتدا پوشهٔ ریشهٔ سایت را که شامل wp‑content، wp‑admin و wp‑includes می شود، به صورت یک پروژهٔ گیت در نظر بگیرید. این کار با اجرای git init در خط فرمان داخل پوشهٔ پروژه انجام می شود؛ گیت یک پوشهٔ مخفی .git می سازد که تمام اطلاعات تاریخچهٔ تغییرات را ذخیره می کند.

در ادامه باید یک فایل .gitignore مناسب برای وردپرس اضافه کنید تا فایل های تولیدی یا حساسی که نیازی به نگهداری در مخزن ندارند، نادیده گرفته شوند. به عنوان مثال می توانید موارد زیر را در .gitignore بنویسید:

• wp-config.php – حاوی اطلاعات پایگاه داده و کلیدهای امنیتی
• /wp-content/uploads/ – پوشهٔ بارگذاری های رسانه ای
• /node_modules/ – اگر از ابزارهای ساخت جاوااسکریپت استفاده می کنید
• .env – فایل های محیطی برای متغیرهای پیکربندی

پس از افزودن این فایل، اولین کامیت را با پیام واضحی مثل «Initial commit – setup WordPress skeleton» ثبت کنید تا نقطهٔ شروع پروژه مشخص شود.

حالا نوبت به ایجاد مخزن روی GitHub می رسد. وارد حساب کاربری خود شوید، روی «New repository» کلیک کنید و نامی توصیفی (مثلاً my‑wordpress‑theme یا custom‑plugin‑suite) انتخاب کنید. اگر می خواهید مخزن عمومی باشد، گزینهٔ Public را بگذارید؛ برای پروژه های خصوصی Private را انتخاب کنید. پس از ساخت مخزن، URL آن (به صورت https://github.com/username/repo.git) را کپی کنید.

در خط فرمان، مخزن محلی را به مخزن ریموت متصل کنید و تغییرات را بارگذاری کنید:

git remote add origin https://github.com/username/repo.git
git branch -M main
git push -u origin main

حالا هر بار که کدهای خود را به روزرسانی می کنید، می توانید با git add .، git commit -m "…" و git push آن ها را همگام سازی کنید. برای کار بر روی ویژگی های جدید، یک شاخهٔ (branch) جداگانه مثل feature/custom‑login ایجاد کنید؛ این کار باعث می شود تغییرات اصلی (main) ثابت بماند و پس از تکمیل، بتوانید یک Pull Request باز کنید.

پیاده سازی استراتژی شاخه ها و مرور

در پروژه های وردپرس، داشتن یک استراتژی واضح برای شاخه ها باعث می شود که تیم توسعه بدون سردرگمی تغییرات را پیگیری کند و خطر ادغام ناخواسته کاهش یابد. معمولاً دو شاخهٔ اصلی main (یا master) و develop استفاده می شوند؛ main حاوی کدهای آمادهٔ انتشار است و develop جایی است که همهٔ ویژگی های جدید ابتدا ادغام می شوند. هر بار که می خواهید یک قابلیت جدید یا اصلاحی اضافه کنید، یک شاخهٔ فرعی (مثلاً feature/…) از develop می سازید.

یک گردش کار ساده می تواند به این شکل باشد:

1. از develop یک شاخهٔ feature/your-feature ایجاد کنید.
2. تغییرات را به صورت منظم commit کنید و پیام های واضح بنویسید.
3. وقتی کار تمام شد، یک pull request (در گیت هاب «درخواست ادغام») به develop بفرستید.
4. پس از مرور و تأیید، شاخهٔ ویژگی را به develop ادغام کنید.
5. هنگامی که می خواهید نسخهٔ جدیدی را منتشر کنید، یک شاخهٔ release/x.x از develop بسازید، تست های نهایی را انجام دهید و سپس به main ادغام کنید.

به عنوان مثال، فرض کنید می خواهید یک custom post type به نام «پروژه» اضافه کنید. ابتدا یک شاخهٔ feature/add-project-cpt می سازید، کدهای لازم را می نویسید و در هر مرحله یک commit واضح می گذارید. پس از تکمیل، درخواست ادغام به develop می فرستید؛ همکارانتان می توانند کد را مرور کرده و نظراتشان را اضافه کنند. وقتی همهٔ بازخوردها اعمال شد، شاخه ادغام می شود و در نهایت با ایجاد یک شاخهٔ release/1.2 می توانید تست نهایی را انجام دهید و سپس به main بفرستید تا در سایت زنده منتشر شود.

یک نکتهٔ عملی این است که برای هر pull request یک قالب ثابت (template) داشته باشید که در آن بخش های «توضیح تغییرات»، «آزمایش های انجام شده» و «پیشنهادات برای بررسی» به وضوح پر شوند. این کار نه تنها مرور کد را سرعت می بخشد، بلکه به اعضای تیم کمک می کند تا به سرعت متوجه شوند که این تغییرات چه تاثیری بر عملکرد سایت وردپرسی خواهند داشت.

همگام سازی تغییرات با GitHub Actions

GitHub Actions یک سرویس یکپارچه CI/CD است که به شما اجازه می دهد پس از هر بار ارسال (push) به مخزن، به صورت خودکار تغییرات را روی سرور تست یا تولید (production) اعمال کنید. این کار باعث می شود که تیم توسعه نیازی به اجرای دستی اسکریپت های استقرار نداشته باشد و خطر فراموشی یا اجرای نادرست کاهش یابد. برای پروژه های وردپرس، معمولاً می خواهیم کد پوسته یا افزونه را بعد از هر کامیت به روزرسانی کنیم و سپس با استفاده از WP‑CLI یا rsync به سرور منتقل کنیم.

اولین گام ایجاد یک فایل ورک فلو در مسیر .github/workflows/ است. یک فایل YAML ساده به نام deploy.yml می تواند به شکل زیر باشد:

name: Deploy WordPress Theme
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.1'
      - name: Install WP‑CLI
        run: curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && php wp-cli.phar --info

در ادامه باید اطلاعات سرور مقصد را به صورت امن ذخیره کنید. GitHub Secrets مکانیزمی برای نگهداری مقادیر حساس (مانند نام کاربری SSH، کلید خصوصی یا توکن API) است. در بخش Settings → Secrets → Actions، متغیرهای SSH_HOST، SSH_USER و SSH_KEY را اضافه کنید. سپس در ورک فلو می توانید این مقادیر را به صورت زیر فراخوانی کنید:

- name: Deploy via SSH
  env:
    SSH_HOST: ${{ secrets.SSH_HOST }}
    SSH_USER: ${{ secrets.SSH_USER }}
    SSH_KEY: ${{ secrets.SSH_KEY }}
  run: |
    echo "$SSH_KEY" | tr -d 'r' > private_key && chmod 600 private_key
    rsync -avz -e "ssh -i private_key -o StrictHostKeyChecking=no" ./ $SSH_USER@$SSH_HOST:/var/www/html/wp-content/themes/mytheme/

یک نکته کاربردی: برای جلوگیری از بروز خطاهای ناخواسته در محیط تولید، می توانید یک مرحله «تست سریع» اضافه کنید که پس از نصب WP‑CLI، یک فرمان ساده مانند wp core is-installed را اجرا کند. اگر این تست شکست خورد، ورک فلو با وضعیت خطا متوقف می شود و استقرار انجام نمی گیرد، بنابراین شما قبل از هر بار بارگذاری کد، یک لایهٔ حفاظتی اضافی دارید.

به کارگیری Pull Request برای بازبینی کد

در پروژه های وردپرس، به ویژه هنگام توسعهٔ افزونه یا قالب، هر تغییر کد باید توسط حداقل یک همکار بررسی شود تا خطر بروز باگ یا ناسازگاری کاهش یابد. Pull Request (درخواستی برای ادغام) ابزار اصلی گیت هاب برای این کار است؛ شما یک شاخهٔ جدید می سازید، تغییرات را در آن اعمال می کنید و سپس یک PR باز می کنید تا دیگران بتوانند کد را مرور، تست و در نهایت ادغام کنند.

برای شروع، ابتدا یک feature یا bugfix branch از مخزن اصلی ایجاد کنید (مثلاً feature/add-custom-meta). در این شاخه، تغییرات لازم را اعمال کنید و با git commit پیام واضحی بنویسید که هدف تغییر را توصیف کند. سپس با git push شاخه را به گیت هاب بفرستید و از دکمه «New pull request» استفاده کنید. در فرم PR، عنوانی کوتاه ولی توصیفی و توضیحی مفصل که شامل موارد زیر باشد، وارد کنید:

• هدف تغییر (مثلاً افزودن فیلد متا به پست ها)
• فایل های تحت تأثیر
• آزمون های انجام شده (مثلاً تست واحد با PHPUnit)
• اگر تغییرات به روزرسانی های قبلی را تحت الشعاع می گیرد، لینک به PRهای مرتبط.

پس از ایجاد PR، می توانید همکاران یا تیم QA را به عنوان reviewer اختصاص دهید. گیت هاب به صورت خودکار وضعیت CI (Continuous Integration) را نشان می دهد؛ اگر تست های خودکار شکست بخورند، reviewer می تواند با افزودن نظر، مشکل را نشان دهد. پس از دریافت نظرات، تغییرات را با git commit --amend یا افزودن commit جدید اصلاح کنید و دوباره push کنید؛ این اصلاحات به صورت خودکار به همان PR اضافه می شوند. وقتی تمام نظرات حل شد و CI سبز شد، می توانید با گزینهٔ «Merge pull request» ادغام را نهایی کنید.

مثال عملی: فرض کنید می خواهید یک فیلد جدید برای متا داده های سفارشی پست ها اضافه کنید. ابتدا در شاخهٔ feature/custom-field فایل functions.php را به روزرسانی می کنید، سپس یک PR می سازید و دو توسعه دهنده دیگر را به عنوان reviewer انتخاب می کنید. اگر یکی از آن ها می گوید که برای امنیت بهتر باید مقدار ورودی با sanitize_text_field() پاک سازی شود، یک commit اصلاحی اضافه می کنید و دوباره push می کنید. پس از تأیید نهایی و عبور تست های CI، PR ادغام می شود و فیلد جدید در سایت وردپرس به صورت ایمن فعال می شود.

استقرار خودکار تم و افزونه ها

برای به کارگیری GitHub به عنوان مخزن منبع تم و افزونه های وردپرس، ابتدا مخزن را به صورت خصوصی یا عمومی در GitHub ایجاد کنید و ساختار دایرکتوری را مطابق استاندارد وردپرس تنظیم کنید؛ به عبارت دیگر، wp-content/themes/your-theme و wp-content/plugins/your-plugin باید در ریشه مخزن باشند. سپس یک کلید SSH برای سرور میزبانی (مانند سرور لینوکسی یا سرویس های Managed WordPress) تولید کنید و کلید عمومی را به تنظیمات Deploy keys مخزن اضافه کنید تا سرور بتواند بدون رمز عبور به مخزن دسترسی پیدا کند.

بعد از تنظیم کلیدها، زمان نصب ابزارهای CI/CD می رسد. ساده ترین راه استفاده از GitHub Actions است؛ این سرویس به صورت پیش فرض در مخزن فعال است و می توانید یک فایل .github/workflows/deploy.yml اضافه کنید. در این فایل، مراحل زیر را تعریف می کنید:

• بررسی کد (checkout) با استفاده از actions/checkout@v3.
• اجرای اسکریپت های ساخت (اگر تم یا افزونه نیاز به کامپایل Sass یا TypeScript دارد).
• کپی کردن فایل های نهایی به مسیر استقرار سرور با استفاده از rsync یا scp، به طوری که فقط تغییرات جدید انتقال یابد.
• ارسال اعلان (مثلاً به Slack یا ایمیل) برای اطلاع از موفقیت یا شکست عملیات.

به عنوان مثال، اگر یک افزونهٔ فرم تماس با قابلیت ارسال ایمیل دارد، پس از هر بار commit در شاخه main، GitHub Action به صورت خودکار کد را به سرور منتقل می کند؛ به این ترتیب، نیازی به ورود دستی به پنل میزبانی برای آپلود فایل ها ندارید و هر تغییر بلافاصله بر روی سایت فعال می شود. همچنین می توانید با افزودن یک مرحله تست واحد (unit test) قبل از Deploy، از بروز خطاهای ناخواسته جلوگیری کنید.

در نهایت، برای حفظ امنیت بهتر است دسترسی های SSH را به صورت read‑only تنظیم کنید و فقط مسیرهای wp-content/themes و wp-content/plugins را در کلیدهای Deploy اجازه بدهید. این کار مانع دسترسی به سایر بخش های سرور می شود و ریسک حمله را به حداقل می رساند. پس از تکمیل تنظیمات، هر بار که کد در مخزن به روزرسانی می شود، فرآیند استقرار به صورت کامل و بدون وقفه انجام می گیرد.

سوالات متداول

چگونه مخزن خصوصی برای پروژه وردپرس ایجاد کنیم؟

در گیت هاب روی دکمه New repository کلیک کنید. گزینه Private را فعال کنید و نام مناسب انتخاب کنید. سپس تنظیمات .gitignore را برای وردپرس اضافه کنید تا فایل های حساس نادیده گرفته شوند.

چرا تغییرات به صورت خودکار در سرور staging اعمال نمی شوند؟

اگر از GitHub Actions استفاده می کنید، باید یک workflow برای استقرار بنویسید. اطمینان حاصل کنید که توکن دسترسی به سرور در Secrets ذخیره شده است. همچنین مسیر پوشه wp‑content باید در اسکریپت به درستی مشخص شود.

آیا می توان افزونه های سفارشی را به صورت submodule اضافه کرد؟

بله، با دستور git submodule add URL مسیر/به/افزونه می توانید افزونه را لینک کنید. پس از commit، سایر توسعه دهندگان می توانند با git submodule update –init آن را دریافت کنند. دقت کنید که .gitmodules را در .gitignore نگذارید.

چگونه از تداخل نسخه PHP بین محیط محلی و سرور جلوگیری کنیم؟

در فایل .github/workflows یک job برای تست با نسخه های مختلف PHP تعریف کنید. در محیط محلی از Docker یا phpenv استفاده کنید تا نسخه دقیق مشابه سرور باشد. این کار باعث می شود خطاهای سازگاری زودتر کشف شوند.

چک لیست کارآمد

• Git را نصب و تنظیمات اولیه مانند نام کاربری و ایمیل را پیکربندی کنید.
• یک مخزن خالی برای پروژه وردپرس در GitHub بسازید و آن را به پوشه محلی متصل کنید.
• یک استراتژی شاخه واضح (مانند main, develop, feature) تعریف کنید و به صورت منظم از آن استفاده کنید.
• GitHub Actions را برای اجرای تست ها و ساخت بسته های تم/افزونه تنظیم کنید.
• از Pull Request برای مرور کد و ادغام تغییرات به شاخه اصلی بهره بگیرید.
• پس از مرور، استقرار خودکار تم یا افزونه را با اکشن های CI/CD فعال کنید.

با این روند، مدیریت کد و استقرار در پروژه های وردپرس به صورت یکپارچه و ایمن انجام می شود. هر گام از نصب گیت تا استقرار خودکار، شما را به کنترل کامل بر تغییرات نزدیک تر می کند. اگر سؤال یا تجربه ای در این زمینه دارید، خوشحال می شویم که در بخش نظرات به اشتراک بگذارید.