تفاوت Git و GitHub برای کاربران VPS

GitHub چیست؟

GitHub یک سرویس میزبانی است که مخازن Git را ذخیره کرده و وب‌سایتی پیرامون آن‌ها ایجاد می‌کند. Git یک برنامه کنترل نسخه است که روی رایانه شخصی یا سرور شما اجرا می‌شود. GitHub محصولی از یک شرکت است که بر پایه Git بنا شده و از سال 2018 تحت مالکیت Microsoft قرار دارد. شما می‌توانید هر روز از Git استفاده کنید و هرگز GitHub را باز نکنید. اما نمی‌توانید بدون Git از GitHub استفاده کنید.

این تمایز در لحظه‌ای که صاحب یک VPS (سرور مجازی خصوصی) می‌شوید، اهمیت پیدا می‌کند. Git ابزاری است که تاریخچه فایل‌های پیکربندی و اسکریپت‌های استقرار (deploy) شما را ثبت می‌کند. GitHub مکانی است که نسخه‌ای از این تاریخچه در زمانی که سرور در دسترس نیست در آن نگهداری می‌شود؛ علاوه بر این، فضایی برای اجرای بیلدها و بازبینی کدها فراهم می‌کند. این راهنما یک نمونه عملی را از یک پوشه خالی تا استقرار روی سرور دنبال می‌کند و هر اصطلاح جدید را در اولین برخورد تعریف می‌کند.

آنچه Git به‌صورت مستقل انجام می‌دهد

Git یک سیستم کنترل نسخه است: وضعیت یک دایرکتوری را در طول زمان ثبت می‌کند تا بتوانید تغییرات، زمان و دلیل آن‌ها را مشاهده کنید. این ابزار در سال 2005 برای توسعه هسته Linux نوشته شد. Git یک سیستم توزیع‌شده است، به این معنی که هر کپی از یک مخزن (repository)، کل تاریخچه را در خود نگه می‌دارد. در طراحی آن هیچ سرور مرکزی وجود ندارد. لپ‌تاپ یک همکار، به اندازه هر سروری یک کپی کامل محسوب می‌شود.

آن را نصب کرده و هویت خود را تنظیم کنید. Git بدون نام و آدرس ایمیل از ثبت commit خودداری می‌کند، زیرا هر دو مورد مستقیماً درون خودِ commit نوشته می‌شوند.

sudo apt update && sudo apt install -y git
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

در Ubuntu 24.04، دستور git --version خروجی git version 2.43.0 را چاپ می‌کند. هر نسخه‌ای که در چند سال اخیر منتشر شده، برای تمام موارد زیر به همین شکل عمل می‌کند.

مثال: یک مخزن برای فایل‌های استقرار VPS شما

یک repository که معمولاً به اختصار "repo" نامیده می‌شود، دایرکتوری است که توسط Git نظارت می‌شود. زمانی که دستور git init را اجرا می‌کنید، این دایرکتوری به یک مخزن تبدیل می‌شود؛ این دستور یک پوشه مخفی به نام .git در داخل آن ایجاد می‌کند. آن پوشه در واقع همان مخزن است. اگر .git را حذف کنید، تنها یک دایرکتوری معمولی باقی می‌ماند که هیچ تاریخچه‌ای ندارد.

mkdir vps-deploy && cd vps-deploy
git init -b main
printf '.env\n*.key\n' > .gitignore

دستور -b main نام اولین شاخه (branch) را به main تغییر می‌دهد. اگر این دستور را اجرا نکنید، Git یک راهنمای طولانی درباره نام پیش‌فرض شاخه نمایش می‌دهد. فایل .gitignore مسیرهایی را مشخص می‌کند که Git هرگز نباید آن‌ها را ردیابی کند. فایل حاوی اطلاعات محرمانه (secrets) خود را از همان روز اول در این فایل قرار دهید؛ زیرا فایلی که یک بار commit شده باشد، حتی پس از حذف، در تاریخچه باقی می‌ماند و حذف صحیح آن مستلزم بازنویسی تمام commitهای بعدی است.

کامیت‌ها: واحد تاریخچه

حالا یک اسکریپت اضافه کنید و آن را ثبت نمایید.

printf '#!/bin/sh\nsudo systemctl restart caddy\n' > restart.sh
git add restart.sh .gitignore
git commit -m "Add restart script and gitignore"
git log --oneline

git add تغییرات را به staging area منتقل می‌کند؛ این همان لیستی است که مشخص می‌کند چه مواردی در کامیت بعدی قرار می‌گیرند. git commit آن لیست را به عنوان یک ورودی در تاریخچه ثبت می‌کند. هر کامیت شامل یک snapshot از تمام فایل‌های تحت نظارت، یک پیام، نام نویسنده، برچسب زمانی و اشاره‌گری به کامیت قبلی است. git log --oneline برای هر کامیت یک خط چاپ می‌کند که با یک هش کوتاه مانند a1b2c3d شروع می‌شود. آن هش، نام کامیت است و تقریباً تمام دستورات Git آن را می‌پذیرند.

از مرحله git add صرف‌نظر کنید و git commit به no changes added to commit (use "git add" and/or "git commit -a") پاسخ می‌دهد. هیچ چیزی خراب نشده است. Git به شما می‌گوید که staging area خالی است، بنابراین چیزی برای گرفتن snapshot وجود ندارد. git status دستوری است که هر زمان سردرگم شدید باید اجرا کنید: این دستور نام شاخه فعلی، تغییرات آماده‌شده (staged) و فایل‌هایی که Git می‌بیند اما تحت نظارت ندارد را نمایش می‌دهد.

شاخه‌ها: خط دوم تاریخچه

یک branch یک اشاره‌گر متحرک به یک commit است. main یک شاخه است و از نظر Git هیچ ویژگی خاصی ندارد. ایجاد آن هیچ هزینه‌ای ندارد، زیرا Git به‌جای کپی کردن فایل‌های شما، یک اشاره‌گر جدید می‌نویسد.

git switch -c add-backup
printf '#!/bin/sh\nrestic backup /srv\n' > backup.sh
git add backup.sh
git commit -m "Add nightly backup"
git switch main
ls

پس از git switch main، فایل backup.sh در لیست دیده نمی‌شود. هیچ چیزی حذف نشده است. این فایل در شاخه add-backup وجود دارد و main هرگز آن را نداشته است، بنابراین وقتی جابه‌جا شدید، Git آن را از دایرکتوری کاری شما حذف کرد. این موضوع برای همه در اولین بار تعجب‌آور است. دستور git switch add-backup آن را بازمی‌گرداند.

ریموت‌ها: جایی که GitHub بالاخره ظاهر می‌شود

تا اینجای کار، همه چیز روی یک ماشین و بدون هیچ شبکه‌ای اجرا می‌شد. یک ریموت (remote)، یک URL نام‌گذاری‌شده برای نسخه‌ای دیگر از همان مخزن (repository) است. GitHub یکی از این نسخه‌ها را برای شما میزبانی می‌کند. نام قراردادی برای ریموت اصلی origin است.

یک مخزن خالی از طریق وب‌سایت GitHub ایجاد کنید و سپس به آن متصل شوید. در اینجا SSH را به HTTPS ترجیح دهید: یک کلید SSH فایلی است که شما کنترل آن را در دست دارید و برخلاف توکن دسترسی شخصی (personal access token)، منقضی نمی‌شود.

ssh-keygen -t ed25519 -C "vps-deploy"
cat ~/.ssh/id_ed25519.pub
ssh -T git@github.com

کلید عمومی چاپ‌شده را در صفحه کلیدهای SSH در حساب کاربری GitHub خود کپی کنید و سپس تست را دوباره اجرا کنید. یک کلید فعال، پاسخ Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. را برمی‌گرداند. GitHub به شما دسترسی shell نمی‌دهد، بنابراین این امتناع، نشانه موفقیت است. git@github.com: Permission denied (publickey). به این معنی است که کلید شما هرگز ارائه نشده یا پذیرفته نشده است، پس بررسی کنید که فایل .pub را کپی کرده باشید و نه کلید خصوصی که در کنار آن قرار دارد.

git remote add origin git@github.com:yourname/vps-deploy.git
git push -u origin main

git push کامیت‌های شما را به ریموت می‌فرستد. -u ثبت می‌کند که شاخه محلی main، شاخه ریموت main را دنبال می‌کند، بنابراین بعداً یک دستور ساده git push کافی خواهد بود. git clone <url> عملیات معکوس روی یک ماشین جدید است: کل مخزن را به همراه تاریخچه آن کپی می‌کند و origin را برای شما تنظیم می‌کند. یک ریموت HTTPS نیز کار می‌کند و از همان پروتکلی استفاده می‌کند که هر صفحه وب از آن بهره می‌برد؛ این موضوع در شبکه‌هایی که پورت خروجی 22 را مسدود می‌کنند، مفید است. اگر این جمله نیاز به توضیح بیشتری دارد، ساختار واقعی یک درخواست HTTP جزئیات فنی آن را پوشش می‌دهد.

Pull requestها، issueها و forkها: بخش‌هایی که متعلق به GitHub هستند، نه Git

تمام موارد ذکر شده در بالا مربوط به Git هستند و با هر سروری کار می‌کنند. سه واژه زیر از قابلیت‌های اختصاصی GitHub محسوب می‌شوند. سایر میزبان‌ها از این قابلیت‌ها کپی‌برداری کرده‌اند و خود Git هیچ شناختی از آن‌ها ندارد.

یک pull request (یا به اختصار PR) درخواستی برای ادغام یک branch در branch دیگر است که در صفحه‌ای مخصوص برای بحث و گفتگو ارائه می‌شود. شما add-backup را push می‌کنید، یک PR علیه main باز می‌کنید و سایت، تفاوت‌ها را commit به commit نمایش می‌دهد. افراد می‌توانند روی تک‌تک خطوط نظر بدهند. بررسی‌های خودکار، وضعیت موفقیت یا شکست را نسبت به آن branch گزارش می‌کنند. با کلیک روی دکمه merge، خودِ GitHub عملیات ادغام را روی نسخه خود انجام داده و سپس main را به‌روزرسانی می‌کند. نام این قابلیت از گردش‌کار اصلی گرفته شده است، جایی که شما از یک نگهدارنده (maintainer) می‌خواستید branch شما را به درون branch خود pull (بکشد) کند.

یک issue یک رشته گفتگو (thread) شماره‌گذاری شده برای یک باگ یا یک وظیفه است. این مورد در پایگاه داده GitHub ذخیره می‌شود، نه در مخزن (repository) شما؛ نکته‌ای که پیش از انتخاب میزبان باید بدانید: اگر مخزن را clone کنید، تمام commitها را در اختیار خواهید داشت، اما حتی یک issue هم منتقل نمی‌شود. برای استخراج issueها باید از API استفاده کنید.

یک fork کپی سمت سرور شما از مخزن شخص دیگری است. شما دسترسی نوشتن (write access) به این کپی دارید، یک branch را به آن push می‌کنید و یک pull request از کپی خود به مخزن اصلی می‌فرستید. این همان روشی است که می‌توانید در پروژه‌ای مشارکت کنید که نگهدارندگانش شما را نمی‌شناسند. یک fork در واقع یک clone است که روی GitHub زندگی می‌کند و منشأ خود را به یاد دارد.

نرم‌افزارها هر سه مورد را از طریق همان API می‌خوانند که یک انسان از آن استفاده می‌کند. یک عامل بررسی pull request که روی سرور خود اجرا می‌کنید، منتظر PRهای جدید می‌ماند، تفاوت‌ها (diff) را می‌خواند و روی خطوط کد نظر می‌گذارد. قراردادهایی مانند فایل AGENTS.md در ریشه یک مخزن به این دلیل وجود دارند که امروزه یک مخزن علاوه بر انسان‌ها، توسط ابزارها نیز خوانده می‌شود.

آنچه GitHub در واقع برای مالک یک VPS انجام می‌دهد

با ذخیره‌سازی خارج از سرور شروع کنید. اسکریپت‌های استقرار و playbookهای شما باید جایی غیر از سروری که پیکربندی می‌کنند، قرار داشته باشند. VPS را از یک image تازه بازسازی کنید، clone بگیرید و اجرا کنید. آن مخزن را خصوصی نگه دارید و به سرور یک deploy key بدهید: یک کلید SSH که به‌جای کل حساب کاربری شما، فقط برای یک مخزن ثبت شده و روی حالت فقط‌خواندنی تنظیم شده است. نشت یک deploy key فقط‌خواندنی، تنها یک مخزن را در معرض خطر قرار می‌دهد. اما نشت کلید حساب کاربری، هر چیزی که امکان push کردن به آن را دارید، در معرض خطر قرار می‌دهد.

sudo git clone git@github.com:yourname/vps-deploy.git /srv/vps-deploy
cd /srv/vps-deploy
git pull --ff-only

--ff-only از ایجاد merge commit خودداری می‌کند. روی سروری که فقط تغییرات را دریافت می‌کند، merge همیشه یک اشتباه است؛ بنابراین این فلگ، تاریخچهٔ گیج‌کننده را به خطای صریح fatal: Not possible to fast-forward, aborting. تبدیل می‌کند. چیزی روی سرور تغییر کرده که نباید تغییر می‌کرد. پیش از آنکه دوباره pull کنید، آن را پیدا کنید.

اگر مخزن را با کاربر root کلون کنید و سپس Git را با کاربر دیگری اجرا کنید، با fatal: detected dubious ownership in repository at '/srv/vps-deploy' مواجه می‌شوید. Git از خواندن مخزنی که متعلق به کاربر دیگری است خودداری می‌کند، زیرا یک .git/config مخرب می‌تواند باعث شود Git دستوراتی را اجرا کند. مالکیت را با chown اصلاح کنید و از افزودن استثنای safe.directory خودداری کنید، زیرا این استثنا فقط بررسی را غیرفعال می‌کند بدون آنکه علت اصلی را برطرف کند.

پایپ‌لاین‌های ساخت و استقرار در GitHub Actions

Actions سیستم CI/CD (یکپارچه‌سازی مداوم و تحویل مداوم) در GitHub است. یک فایل YAML را در مسیر .github/workflows/ کامیت کنید تا GitHub آن را هنگام وقوع رویداد مشخص‌شده توسط شما اجرا کند.

name: check
on:
  push:
    branches: [main]
jobs:
  shellcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: sudo apt-get update && sudo apt-get install -y shellcheck
      - run: shellcheck *.sh

این فایل یک workflow است. هر job روی یک ماشین اجرا می‌شود. هر step شامل یک دستور یا یک action منتشرشده است. uses: یک action را از مخزنی دیگر فراخوانی می‌کند و @v7 نسخه اصلی آن را ثابت (pin) می‌کند (نسخه v7 برای actions/checkout تا اوت 2026 نسخه جاری است). همیشه نسخه‌ها را ثابت کنید، زیرا actionهای ثابت‌نشده به این معناست که کدی که آن را بازبینی نکرده‌اید، با دسترسی به secrets شما اجرا می‌شود.

runs-on: ubuntu-latest از GitHub یک ماشین مجازی تازه درخواست می‌کند که پس از پایان job حذف می‌شود. runnerهای استاندارد در مخازن عمومی رایگان هستند و طرح رایگان شامل 2,000 دقیقه در ماه برای مخازن خصوصی تا اوت 2026 است. پیش از تنظیم بودجه بر اساس این عدد، صفحه قیمت‌گذاری جاری را بررسی کنید.

مقادیر Secrets در تنظیمات مخزن ذخیره شده و به عنوان ${{ secrets.DEPLOY_KEY }} خوانده می‌شوند. workflowای که توسط یک pull request از یک fork فعال شود، یک توکن فقط‌خواندنی دریافت می‌کند و به آن secrets دسترسی ندارد؛ زیرا در غیر این صورت، یک فرد غریبه می‌توانست PRای باز کند که تنها وظیفه‌اش چاپ کردن آن‌ها باشد.

اجرای Actions runner روی VPS شخصی

runs-on: self-hosted کار را به جای سرورهای GitHub، به ماشینی که مالک آن هستید ارسال می‌کند. صفحه تنظیمات runner در مخزن، یک دستور دانلود، آدرس وب مخزن و یک توکن ثبت‌نام با اعتبار 1 ساعته در اختیار شما قرار می‌دهد. دو مورد آخر را در REPO_URL و RUNNER_TOKEN وارد کنید؛ پس از آن، راه‌اندازی تنها شامل 3 دستور است.

./config.sh --url "$REPO_URL" --token "$RUNNER_TOKEN"
sudo ./svc.sh install
sudo ./svc.sh start
./svc.sh status

svc.sh status باید وضعیت سرویس را فعال نشان دهد و خطوط اخیر لاگ را نمایش دهد. این runner یک اتصال خروجی HTTPS به GitHub برقرار کرده و درخواست کار می‌کند، بنابراین نیازی نیست هیچ پورت ورودی را برای آن باز کنید. svc.sh install فایل unit مربوط به systemd را می‌نویسد و این همان مرحله‌ای است که کاربران اغلب فراموش می‌کنند: بدون آن، با بستن نشست SSH، برنامه runner نیز متوقف می‌شود و تمام کارهای بعدی بدون هیچ توضیحی در صف باقی می‌مانند. راهنمای کامل راه‌اندازی self-hosted runner روی VPS مراحل ایمن‌سازی و پاک‌سازی مورد نیاز برای یک runner دائمی را توضیح می‌دهد.

مزیت این روش این است که برای استقرار (deploy) دیگر نیازی به کلید SSH ورودی که از اینترنت در دسترس باشد ندارید، زیرا کار از قبل روی همان ماشین در حال اجراست. همچنین کشِ بیلد (build cache) بین دفعات اجرا گرم باقی می‌ماند و هیچ محدودیت دقیقه‌ای برای آن محاسبه نمی‌شود.

یک هشدار ضروری وجود دارد. مستندات خود GitHub توصیه می‌کند که از self-hosted runnerها فقط برای مخازن خصوصی استفاده کنید، زیرا فورک‌های یک مخزن عمومی می‌توانند با باز کردن یک pull request، کدهای مخرب را روی runner شما اجرا کنند. این runner هر دستوری که در فایل workflow آن شاخه نوشته شده باشد را اجرا می‌کند. در یک مخزن خصوصی که کنترل دسترسی‌ها در اختیار شماست، این ریسک ناچیز است. اما در مخازن عمومی، فرض را بر این بگیرید که هر self-hosted runner ماشینی است که افراد غریبه می‌توانند روی آن کد اجرا کنند.

آیا اصلاً به GitHub نیاز دارید؟

خیر. Git یک استاندارد است و GitHub تنها یک ابزار تسهیل‌کننده محسوب می‌شود. Forgejo و Gitea پلتفرم‌های میزبانی Git خود-میزبان (self-hosted) هستند؛ یک پلتفرم میزبانی، در واقع سرویسی است که علاوه بر Git، قابلیت‌هایی مانند مدیریت Issues و Pull Requests را نیز ارائه می‌دهد. هر دوی این ابزارها به صورت یک فایل باینری واحد Go عرضه می‌شوند و روی یک VPS کوچک اجرا می‌گردند. Forgejo یک انشعاب (fork) از Gitea است که در سال 2022 ایجاد شد و اکنون زیرساخت Codeberg را تأمین می‌کند. انتقال یک مخزن (repository) تنها با یک دستور انجام می‌شود، زیرا پروتکل ارتباطی آن‌ها یکسان است.

git remote -v
git remote set-url origin git@git.example.com:you/vps-deploy.git
git push origin main

هر Commit منتقل می‌شود، زیرا هر Clone از مخزن، تمام تاریخچه را در خود دارد. آنچه منتقل نمی‌شود، لایه‌ای است که GitHub بر پایه آن ساخته است: رشته‌های مربوط به Issues و Pull Requests. سیستم CI نیز منتقل نمی‌شود. Forgejo پیاده‌سازی اختصاصی خود را برای Actions دارد که فایل‌های YAML مشابه را از .forgejo/workflows/ می‌خواند. مستندات آن به‌صراحت به محدودیت‌ها اشاره کرده و می‌گوید که GitHub Actions و Forgejo Actions یکسان نیستند و ممکن است همه چیز بلافاصله به‌درستی کار نکند. این سیستم همچنین به Runner اختصاصی خود نیاز دارد. این مرحله را به عنوان یک فرآیند «پورت کردن» در نظر بگیرید، نه یک کپی ساده.

دلیل صادقانه‌ای که اکثر پروژه‌ها در GitHub باقی می‌مانند، مشارکت‌کنندگان (contributors) هستند. کدهای عمومی باید جایی باشند که افراد از قبل در آن حساب کاربری دارند. اسکریپت‌های استقرار (deploy scripts) خصوصی شما نیازی به این کار ندارند. این‌ها دو تصمیم مجزا هستند و شما مجازید برای هر کدام پاسخ متفاوتی داشته باشید.

چه چیزی ابتدا دچار اختلال می‌شود و خطا چه می‌گوید

یک push رد می‌شود. شما این پیام را می‌بینید:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:yourname/vps-deploy.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

از آخرین pull شما، تغییری push شده است؛ اغلب این تغییر ویرایشی است که در web editor انجام داده‌اید. دستور git pull --rebase را اجرا کنید تا commitهای خود را روی commitهای آن‌ها بازنشانی (replay) کنید، سپس دوباره push کنید. از git push --force روی شاخه‌ای که به اشتراک گذاشته شده است پرهیز کنید، زیرا این کار commitهای دیگران را از آن شاخه روی سرور حذف می‌کند.

fatal: refusing to merge unrelated histories. شما دستور git init را به‌صورت محلی اجرا کرده‌اید و اجازه داده‌اید GitHub مخزن را با یک README ایجاد کند. این دو تاریخچه هیچ commit مشترکی ندارند، بنابراین Git نمی‌تواند حدس بزند. راه حل تمیز این است که نسخه GitHub را در یک پوشه جدید clone کنید و فایل‌های خود را به آن منتقل کنید.

error: src refspec main does not match any. شاخه‌ای که نام برده‌اید در اینجا وجود ندارد. معمولاً مخزن تا این لحظه هیچ commitای ندارد، یا نام شاخه شما master است. دستور git branch --show-current مشکل را حل می‌کند.

یک secret به یک commit راه پیدا کرده است. همین حالا credential را تغییر دهید (rotate کنید). از لحظه‌ای که آن secret push شده است، آن را عمومی فرض کنید؛ زیرا forkها، mirrorها و نسخه‌های کش‌شده، کپی‌هایی دارند که راهی برای حذف آن‌ها ندارید.

FAQ

آیا GitHub همان Git است؟

خیر. Git یک برنامه کنترل نسخه است که روی سیستم خود نصب می‌کنید و بدون نیاز به شبکه یا حساب کاربری کار می‌کند. GitHub یک سرویس میزبانی تجاری است که مخازن Git را ذخیره کرده و رابط کاربری وب، سیستم مدیریت مشکلات (issues)، pull requestها و قابلیت‌های CI را به آن اضافه می‌کند. Git در سال 2005 منتشر شد و GitHub در سال 2008 بر پایه آن راه‌اندازی شد. شما می‌توانید بدون GitHub تا ابد از Git استفاده کنید. تمام قابلیت‌های GitHub در لایه زیرین به Git وابسته هستند.

آیا برای استفاده از Git روی VPS خود به حساب GitHub نیاز دارم؟

خیر. git init، git commit و git log روی سروری که هیچ remoteای برای آن تنظیم نشده است کار می‌کنند؛ این برای ردیابی تغییرات در فایل‌های /etc یا اجرای اسکریپت‌های استقرار کافی است. داشتن حساب کاربری زمانی مفید است که بخواهید نسخه‌ای از تاریخچه تغییرات داشته باشید که در صورت خرابی سرور باقی بماند، یا بخواهید ماشین دومی داشته باشید که بتواند مخزن را clone کند. پلتفرم‌های خودمیزبان (Self-hosted) مانند Forgejo و Gitea همین نیاز را روی سخت‌افزار تحت مالکیت شما برطرف می‌کنند؛ همچنین یک remote ساده از نوع SSH که به یک bare repository در سرور دیگری اشاره می‌کند، بدون نیاز به هیچ نرم‌افزار مدیریت مخزنی کار می‌کند.

pull request چیست؟

pull request درخواستی برای ادغام یک branch در branch دیگر است که یک صفحه گفتگو نیز به آن پیوست شده است. شما یک branch را push می‌کنید، یک PR به سمت main باز می‌کنید و سرویس میزبان، تغییرات را commit به commit نمایش می‌دهد تا بازبین‌ها بتوانند روی خطوط خاص نظر بدهند و بررسی‌های خودکار، وضعیت موفقیت یا شکست را گزارش کنند. این یک قابلیت در GitHub است و نه در Git؛ بنابراین خود Git دستوری برای آن ندارد. سایر سرویس‌های میزبان نیز همین ایده را پیاده‌سازی کرده‌اند و گاهی آن را merge request می‌نامند.

آیا باید GitHub Actions runner را روی VPS شخصی خود اجرا کنم؟

برای مخازن خصوصی، اغلب بله. کارها روی سخت‌افزاری اجرا می‌شوند که از قبل هزینه آن را پرداخت کرده‌اید، دقایق مصرفی محاسبه نمی‌شود، کش build گرم می‌ماند و استقرار دیگر نیازی به باز گذاشتن کلید SSH برای اینترنت ندارد، زیرا runner به صورت خروجی (outbound) به GitHub متصل شده و درخواست کار می‌کند. برای مخازن عمومی، GitHub توصیه می‌کند این کار را انجام ندهید: هر کسی می‌تواند از مخزن شما fork بگیرد و یک pull request باز کند که workflow آن، کد را روی ماشین شما اجرا کند.

آیا می‌توانم بعداً مخازن خود را از GitHub منتقل کنم؟

کدها را بله، به راحتی. هر clone شامل کل تاریخچه است، بنابراین git remote set-url origin <new url> و به دنبال آن یک push، تمام محتویات commitها را منتقل می‌کند. آنچه باقی می‌ماند لایه‌ای است که متعلق به GitHub است: مشکلات (issues)، گفتگوهای pull request و تاریخچه Actions در دیتابیس آن‌ها ذخیره می‌شود، نه در پوشه .git شما. ابزارهای مهاجرت می‌توانند مشکلات را از طریق API کپی کنند و فایل‌های workflow معمولاً برای CI میزبان جدید نیاز به ویرایش دارند. با در نظر داشتن این موضوع، بهتر است مستندات اصلی را به جای رشته‌های گفتگو در بخش issues، داخل خود مخزن نگهداری کنید.