Git اور GitHub میں فرق: VPS مالکان کے لیے رہنما

GitHub کیا ہے؟

GitHub ایک hosted service ہے جو Git repositories محفوظ کرتی ہے اور ان کے گرد ایک website فراہم کرتی ہے۔ Git وہ version control program ہے جو آپ کے اپنے computer یا اپنے server پر چلتا ہے۔ GitHub، Git کے اوپر Microsoft کی ملکیت میں موجود ایک کمپنی کی product ہے، جو 2018 سے Microsoft کی ملکیت ہے۔ آپ روزانہ Git استعمال کر سکتے ہیں اور کبھی GitHub نہ کھولیں۔ آپ Git کے بغیر GitHub استعمال نہیں کر سکتے۔

یہ بات اسی وقت اہم ہو جاتی ہے جب آپ کے پاس VPS (virtual private server) ہو۔ Git آپ کی config files اور deploy scripts کی history محفوظ کرتا ہے۔ GitHub اس history کی وہ copy رکھتا ہے جو server پر موجود نہیں ہوتی، اور builds اور reviews چلانے کی جگہ بھی فراہم کرتا ہے۔ یہ guide ایک خالی folder سے server پر deploy تک کی ایک مثال پیش کرتی ہے، اور ہر نئی اصطلاح کی پہلی بار آمد پر اس کی وضاحت کرتی ہے۔

Git خود کیا کرتا ہے

Git ایک version control system ہے۔ یہ وقت کے ساتھ directory کی حالت record کرتا ہے، تاکہ آپ دیکھ سکیں کہ کیا تبدیل ہوا، کب تبدیل ہوا، اور کیوں تبدیل ہوا۔ اسے 2005 میں Linux kernel کے کام کے لیے لکھا گیا تھا۔ یہ distributed ہے، یعنی repository کی ہر copy میں مکمل history موجود ہوتی ہے۔ اس design میں کوئی central server نہیں ہوتا۔ colleague کے laptop پر موجود copy بھی اتنی ہی مکمل ہوتی ہے جتنی کسی server پر موجود copy۔

اسے install کریں اور اپنی شناخت set کریں۔ Git name اور email address کے بغیر commit record نہیں کرتا، کیونکہ دونوں 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 print کرتا ہے۔ گزشتہ چند سال کی کوئی بھی release نیچے دی گئی تمام چیزوں کے لیے اسی طرح کام کرتی ہے۔

مثال: آپ کے VPS deploy files کے لیے repository

repository، جسے عموماً "repo" کہا جاتا ہے، ایک directory ہے جس کی Git نگرانی کر رہی ہوتی ہے۔ جب آپ git init چلاتے ہیں تو یہ repository بن جاتی ہے، اور اس کے اندر ایک مخفی .git folder بن جاتا ہے۔ وہ folder ہی repository ہے۔ .git حذف کرنے کے بعد آپ کے پاس صرف ایک عام directory رہ جاتی ہے جس میں کوئی history نہیں ہوتی۔

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

-b main پہلی branch کا نام main رکھتا ہے۔ اسے چھوڑنے پر Git اس کے بجائے default branch name کے بارے میں ایک طویل ہدایت دکھاتا ہے۔ .gitignore ان paths کی فہرست رکھتا ہے جنہیں Git کو کبھی track نہیں کرنا چاہیے۔ پہلے ہی دن اپنی secrets file اس میں شامل کریں، کیونکہ جو file ایک بار commit ہو جائے وہ اسے حذف کرنے کے بعد بھی history میں موجود رہتی ہے، اور اسے درست طور پر ہٹانے کے لیے اس کے بعد آنے والی ہر commit کو rewrite کرنا پڑتا ہے۔

تاریخی ریکارڈ کی اکائی: commits

اب ایک script شامل کریں اور اسے ریکارڈ کریں۔

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 میں منتقل کرتا ہے۔ یہ ان چیزوں کی فہرست ہوتی ہے جو اگلے commit میں شامل ہوں گی۔ git commit اس فہرست کو تاریخ میں ایک اندراج کے طور پر محفوظ کرتا ہے۔ commit میں ہر tracked file کا snapshot، ایک پیغام، مصنف، timestamp، اور اس سے پہلے والے commit کا pointer شامل ہوتا ہے۔ git log --oneline ہر commit کے لیے ایک سطر دکھاتا ہے۔ ہر سطر مختصر hash سے شروع ہوتی ہے، جیسے a1b2c3d۔ یہ hash commit کا نام ہوتا ہے، اور تقریباً ہر Git command اسے قبول کرتی ہے۔

git add مرحلہ چھوڑ دیں اور git commit کا جواب no changes added to commit (use "git add" and/or "git commit -a") آئے گا۔ اس میں کوئی خرابی نہیں ہے۔ Git بتا رہا ہے کہ staging area خالی ہے، اس لیے snapshot بنانے کے لیے کچھ موجود نہیں۔ جب بھی آپ الجھن میں ہوں، git status command چلائیں۔ یہ موجودہ branch، staged changes، اور وہ files بتاتی ہے جنہیں Git دیکھ سکتا ہے لیکن track نہیں کر رہا۔

Branches: تاریخ کی ایک دوسری شاخ

branch کسی commit کی طرف اشارہ کرنے والا متحرک pointer ہے۔ main ایک branch ہے، اور Git میں یہ کسی بھی طرح خاص نہیں ہے۔ اسے بنانا مفت ہے، کیونکہ Git آپ کی files کو copy کرنے کے بجائے ایک نیا pointer لکھتا ہے۔

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 کے بعد listing میں backup.sh موجود نہیں ہے۔ کچھ بھی delete نہیں ہوا۔ یہ file add-backup branch پر موجود ہے، جبکہ main پر یہ کبھی تھی ہی نہیں؛ اسی لیے منتقل ہونے پر Git نے اسے آپ کی working directory سے ہٹا دیا۔ یہ صورتِ حال ہر شخص کو ایک بار ضرور حیران کرتی ہے۔ git switch add-backup اسے واپس لے آتا ہے۔

ریموٹس: جہاں GitHub آخرکار ظاہر ہوتا ہے

اب تک تمام کام ایک ہی مشین پر، مکمل طور پر نیٹ ورک کے بغیر، ہوا۔ remote اسی repository کی ایک دوسری copy کے لیے نامزد URL ہوتا ہے۔ GitHub آپ کے لیے ایسی ایک copy host کرتا ہے۔ مرکزی remote کا روایتی نام origin ہے۔

GitHub کی ویب سائٹ کے ذریعے ایک خالی repository بنائیں، پھر اسے connect کریں۔ یہاں HTTPS کے بجائے SSH کو ترجیح دیں: SSH key ایک ایسی فائل ہے جسے آپ خود manage کرتے ہیں، اور یہ personal access token کی طرح expire نہیں ہوتی۔

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

پرنٹ ہونے والی public key کو اپنے GitHub account کے SSH keys صفحے میں paste کریں، پھر test دوبارہ چلائیں۔ کام کرنے والی key کا جواب Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. ہوتا ہے۔ GitHub آپ کو shell access نہیں دیتا، اس لیے یہ refusal کامیابی کی علامت ہے۔ git@github.com: Permission denied (publickey). کا مطلب ہے کہ آپ کی key پیش ہی نہیں کی گئی یا قبول نہیں ہوئی؛ چیک کریں کہ آپ نے .pub فائل paste کی ہے، نہ کہ اس کے ساتھ موجود private key۔

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

git push آپ کے commits کو remote پر بھیجتا ہے۔ -u یہ ریکارڈ کرتا ہے کہ مقامی main، remote main کو track کرتا ہے، اس لیے بعد میں صرف ایک bare git push کافی ہوتا ہے۔ نئی مشین پر git clone <url> اس کا الٹ ہے: یہ مکمل repository کو اس کی history سمیت copy کرتا ہے اور آپ کے لیے origin set کر دیتا ہے۔ HTTPS remote بھی کام کرتا ہے، اور یہ اسی protocol کے ذریعے منتقل ہوتا ہے جو ہر web page کے لیے استعمال ہوتا ہے۔ اس سے ان networks پر مدد ملتی ہے جو outbound port 22 block کرتے ہیں۔ اگر اس جملے کی مزید وضاحت درکار ہو تو HTTP request اصل میں کن چیزوں پر مشتمل ہوتی ہے میں طریقۂ کار بیان کیا گیا ہے۔

Pull requests، issues اور forks: وہ حصے جو GitHub سے متعلق ہیں، Git سے نہیں

اوپر بیان کردہ تمام چیزیں Git کا حصہ ہیں اور کسی بھی server کے ساتھ کام کرتی ہیں۔ ذیل کے تین الفاظ GitHub کی features ہیں۔ دوسرے hosts ان کی نقل کرتے ہیں، لیکن Git خود ان کے بارے میں کچھ نہیں جانتا۔

pull request (PR) ایک branch کو دوسری branch میں merge کرنے کی درخواست ہوتی ہے، جسے discussion کے لیے ایک page میں پیش کیا جاتا ہے۔ آپ add-backup کو push کرتے ہیں، main کے خلاف PR کھولتے ہیں، اور site فرق کو commit بہ commit دکھاتی ہے۔ لوگ ایک ایک line پر comment کر سکتے ہیں۔ Automated checks branch کے لیے pass یا fail کی status رپورٹ کرتی ہیں۔ merge پر click کرنے سے GitHub اپنی copy میں merge کرتا ہے، پھر main کو update کر دیتا ہے۔ یہ نام اس ابتدائی workflow سے آیا ہے جس میں آپ maintainer سے کہتے تھے کہ اپنی branch میں آپ کی branch کو pull کر لے۔

issue کسی bug یا task کے لیے numbered thread ہوتا ہے۔ یہ آپ کے repository میں نہیں بلکہ GitHub کے database میں رہتا ہے۔ host منتخب کرنے سے پہلے یہ بات جاننا ضروری ہے: repo clone کرنے سے آپ کے پاس ہر commit آ جاتا ہے، لیکن کوئی issue نہیں آتا۔ issues حاصل کرنے کے لیے API کو call کرنا پڑتا ہے۔

fork کسی دوسرے شخص کے repository کی server-side copy ہوتی ہے جو آپ کے اختیار میں ہوتی ہے۔ آپ کو اس copy پر write access حاصل ہوتا ہے، آپ اس میں branch push کرتے ہیں، اور اپنی copy سے اصل repository کے لیے pull request کھولتے ہیں۔ ایسے project میں contribution کا یہی طریقہ ہے جس کے maintainers آپ کو پہلے سے نہیں جانتے۔ fork ایسا clone ہے جو GitHub پر رہتا ہے اور اپنے ماخذ کو یاد رکھتا ہے۔

Software ان تینوں کو اسی API کے ذریعے پڑھتا ہے جسے انسان استعمال کرتا ہے۔ ایک pull request review agent جو آپ اپنے server پر چلاتے ہیں نئے PRs کی نگرانی کرتا ہے، diff پڑھتا ہے، اور lines پر comments پوسٹ کرتا ہے۔ repository کی root پر موجود AGENTS.md file جیسی conventions اس لیے موجود ہیں کہ repo کو اب لوگوں کے ساتھ ساتھ tools بھی پڑھتے ہیں۔

VPS کے مالک کے لیے GitHub کا اصل کام

سب سے پہلے سرور سے باہر storage استعمال کریں۔ آپ کے deploy scripts اور playbooks ایسی جگہ ہونے چاہییں جو اس سرور سے الگ ہو جسے وہ configure کرتے ہیں۔ VPS کو fresh image سے دوبارہ بنائیں، repository clone کریں، اور run کریں۔ اس repository کو private رکھیں اور سرور کو ایک deploy key دیں: یہ SSH key پورے account کے بجائے صرف ایک repository کے ساتھ registered ہوتی ہے اور read only پر set کی جاتی ہے۔ اگر read-only deploy key leak ہو جائے تو صرف ایک repository افشا ہوتی ہے۔ اگر account key leak ہو جائے تو ہر وہ چیز افشا ہو سکتی ہے جسے آپ 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 بنانے سے انکار کرتا ہے۔ ایسے سرور پر جو صرف changes consume کرتا ہے، merge ہمیشہ ایک حادثاتی تبدیلی ہوتی ہے۔ اس لیے یہ flag مبہم history کو واضح error fatal: Not possible to fast-forward, aborting. میں تبدیل کر دیتا ہے۔ سرور پر ایسی تبدیلی ہوئی ہے جو نہیں ہونی چاہیے تھی۔ دوبارہ pull کرنے سے پہلے اسے تلاش کریں۔

root کے طور پر clone کرنے کے بعد Git کو کسی دوسرے user کے طور پر چلائیں تو fatal: detected dubious ownership in repository at '/srv/vps-deploy' حاصل ہوتا ہے۔ Git ایسی repository پڑھنے سے انکار کرتا ہے جس کی ملکیت کسی دوسرے user کے پاس ہو، کیونکہ ایک hostile .git/config Git سے commands run کروا سکتا ہے۔ ownership کو chown سے درست کریں، safe.directory exception شامل نہ کریں، کیونکہ exception وجہ ختم کیے بغیر صرف check کو خاموش کرتی ہے۔

GitHub Actions: build اور deploy پائپ لائنز

Actions، GitHub کا CI/CD نظام ہے، یعنی continuous integration اور continuous delivery۔ .github/workflows/ کے تحت YAML فائل commit کریں، اور GitHub اسے آپ کے نامزد کردہ event کے وقت چلاتا ہے۔

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 ایک machine پر چلتا ہے۔ step ایک command یا ایک published action ہوتا ہے۔ uses: کسی دوسرے repository سے action شامل کرتا ہے، جبکہ @v7 اس کا major version مقرر کرتا ہے۔ August 2026 تک actions/checkout کے لیے v7 موجودہ version ہے۔ ہمیشہ کسی version کو pin کریں، کیونکہ unpinned action کا مطلب ہے کہ ایسا code آپ کے secrets تک رسائی کے ساتھ چل سکتا ہے جسے آپ نے پڑھا نہیں۔

runs-on: ubuntu-latest GitHub سے ایک نئی virtual machine طلب کرتا ہے، جو job ختم ہونے پر ختم کر دی جاتی ہے۔ Public repositories پر standard runners مفت ہوتے ہیں، جبکہ August 2026 تک free plan میں private repositories کے لیے ہر ماہ 2,000 minutes شامل ہیں۔ اس مقدار کی بنیاد پر budget بنانے سے پہلے موجودہ pricing page دیکھیں۔

Secrets repository settings میں محفوظ ہوتے ہیں اور ${{ secrets.DEPLOY_KEY }} کے طور پر پڑھے جاتے ہیں۔ Fork سے آنے والی pull request کے ذریعے شروع ہونے والے workflow کو read-only token ملتا ہے اور ان secrets تک رسائی نہیں ملتی، کیونکہ بصورتِ دیگر کوئی اجنبی ایسی PR کھول سکتا تھا جس کا واحد مقصد انہیں ظاہر کرنا ہو۔

اپنے VPS پر Actions runner چلانا

runs-on: self-hosted کام اس کے بجائے آپ کی اپنی ملکیت والی مشین کو بھیجتا ہے۔ repository کے runner settings page پر آپ کو download line، repository web address اور ایک registration token ملتا ہے جو ایک گھنٹے کے لیے valid ہوتا ہے۔ آخری دو values کو REPO_URL اور RUNNER_TOKEN میں رکھیں، پھر setup کے لیے تین commands کافی ہیں۔

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

svc.sh status کو service کی حالت active دکھانی چاہیے اور حالیہ log lines بھی دکھانی چاہییں۔ runner GitHub سے outbound HTTPS connection کھول کر کام طلب کرتا ہے، اس لیے اس کے لیے کوئی inbound port کھولنے کی ضرورت نہیں۔ svc.sh install systemd unit لکھتا ہے، اور لوگ اکثر یہی مرحلہ چھوڑ دیتے ہیں: اس کے بغیر runner آپ کے SSH session کے ختم ہوتے ہی بند ہو جاتا ہے، اور بعد کے تمام jobs بغیر کسی وضاحت کے queued رہتے ہیں۔ VPS پر self-hosted runner کا مکمل setup اس طویل مدت تک چلنے والے runner کے لیے hardening اور cleanup کے مراحل بیان کرتا ہے۔

اس کا فائدہ یہ ہے کہ deploy کے لیے اب internet سے قابل رسائی inbound SSH key کی ضرورت نہیں رہتی، کیونکہ job پہلے ہی اسی machine پر چل رہا ہوتا ہے۔ build cache بھی runs کے درمیان برقرار رہتا ہے، اور کوئی minute meter بھی شمار نہیں کر رہا ہوتا۔

ایک اہم انتباہ نظرانداز نہیں کیا جا سکتا۔ GitHub کی اپنی documentation صرف private repositories کے لیے self-hosted runners کی سفارش کرتی ہے، کیونکہ public repository کے forks pull request کھول کر آپ کے runner پر خطرناک code چلا سکتے ہیں۔ runner وہی کچھ execute کرتا ہے جو اس branch کی workflow file میں لکھا ہو۔ private repo میں، جہاں آپ کو معلوم ہوتا ہے کہ کون push کر سکتا ہے، risk کم ہوتا ہے۔ public repo میں ہر self-hosted runner کو ایسی machine سمجھیں جس پر اجنبی لوگ code execute کر سکتے ہیں۔

کیا GitHub واقعی ضروری ہے؟

نہیں۔ Git معیاری سافٹ ویئر ہے، جبکہ GitHub سہولت فراہم کرتا ہے۔ Forgejo اور Gitea self-hosted forge ہیں؛ forge سے مراد ایسا Git host ہے جس کے ساتھ issues اور pull requests منسلک ہوں۔ دونوں ایک واحد Go binary کے طور پر جاری ہوتے ہیں، دونوں چھوٹے VPS پر چل سکتے ہیں، اور Forgejo، Gitea کا 2022 کا fork ہے جو اب Codeberg کو چلاتا ہے۔ Repository منتقل کرنے کے لیے ایک ہی command کافی ہے، کیونکہ wire protocol یکساں ہے۔

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

ہر commit منتقل ہو جاتا ہے، کیونکہ ہر clone میں پہلے ہی مکمل history موجود ہوتی ہے۔ جو چیز منتقل نہیں ہوتی وہ وہ layer ہے جو GitHub نے اس کے اوپر بنائی ہے: issues اور pull request threads۔ CI بھی منتقل نہیں ہوتی۔ Forgejo کا اپنا Actions implementation ہے جو .forgejo/workflows/ سے ملتی جلتی YAML پڑھتا ہے، اور اس کی documentation حدود کے بارے میں واضح ہے: GitHub Actions اور Forgejo Actions یکساں نہیں ہیں، اور ضروری نہیں کہ چیزیں فوراً کام کریں۔ اسے اپنا runner بھی درکار ہوتا ہے۔ اس مرحلے کو copy نہیں بلکہ port سمجھ کر منصوبہ بنائیں۔

دیانت دارانہ جواب یہ ہے کہ زیادہ تر projects contributors کی وجہ سے GitHub پر رہتے ہیں۔ Public code کو ایسی جگہ موجود ہونا چاہیے جہاں لوگوں کا پہلے سے account ہو۔ آپ کے private deploy scripts کے لیے یہ ضروری نہیں۔ یہ دو الگ فیصلے ہیں، اور آپ ان کے مختلف جواب دے سکتے ہیں۔

پہلے کیا خراب ہوتا ہے، اور error کیا بتاتا ہے

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 کیا گیا ہے، اکثر یہ وہ edit ہوتا ہے جو آپ نے web editor میں کیا ہو۔ git pull --rebase چلائیں تاکہ اپنے commits کو ان کے commits کے اوپر دوبارہ apply کر سکیں، پھر دوبارہ push کریں۔ shared branch پر git push --force استعمال نہ کریں، کیونکہ اس سے server پر اس branch کے دوسرے commits حذف ہو جاتے ہیں۔

fatal: refusing to merge unrelated histories۔ آپ نے مقامی طور پر git init چلایا، اور GitHub کو README کے ساتھ repository بنانے بھی دیا۔ دونوں histories میں کوئی مشترک commit نہیں، اس لیے Git خود فیصلہ نہیں کر سکتا۔ صاف حل یہ ہے کہ GitHub کی copy کو نئے folder میں clone کریں اور اپنی files اس میں منتقل کریں۔

error: src refspec main does not match any۔ آپ نے جس branch کا نام دیا ہے، وہ یہاں موجود نہیں۔ عموماً repository میں ابھی تک کوئی commit نہیں ہوتا، یا آپ کی branch کا نام master ہوتا ہے۔ git branch --show-current سے مسئلہ حل ہو جاتا ہے۔

ایک secret commit میں شامل ہو گیا ہے۔ credential فوراً rotate کریں۔ اسے push ہونے کے لمحے سے public سمجھیں، کیونکہ forks، mirrors اور cached views میں ایسی copies موجود رہتی ہیں جنہیں آپ حذف نہیں کر سکتے۔

FAQ

کیا GitHub، Git ہی کی چیز ہے؟

نہیں۔ Git ایک version control پروگرام ہے جسے آپ کسی machine پر install کرتے ہیں، اور یہ network اور account کے بغیر بھی کام کرتا ہے۔ GitHub ایک commercial hosted service ہے جو Git repositories محفوظ کرتی ہے اور ان کے ساتھ web interface، issues، pull requests اور CI فراہم کرتی ہے۔ Git 2005 میں release ہوا تھا، جبکہ GitHub نے 2008 میں اسی کی بنیاد پر کام شروع کیا۔ آپ GitHub کے بغیر Git کو ہمیشہ چلا سکتے ہیں۔ GitHub کی ہر feature اندرونی طور پر Git پر depend کرتی ہے۔

کیا اپنے VPS پر Git استعمال کرنے کے لیے GitHub account ضروری ہے؟

نہیں۔ git init، git commit اور git log ایسے server پر بھی کام کرتے ہیں جس میں کوئی remote configured نہ ہو۔ یہ پہلے ہی /etc files میں تبدیلیاں track کرنے یا deploy scripts چلانے کے لیے کافی ہے۔ Account اس وقت مفید ہوتا ہے جب آپ history کی ایسی copy رکھنا چاہیں جو server کے ختم ہونے کے بعد بھی محفوظ رہے، یا جب دوسری machine سے اسے clone کرنا ہو۔ Forgejo اور Gitea جیسے self-hosted forges آپ کے اپنے hardware پر یہی ضرورت پوری کرتے ہیں۔ دوسرے box پر موجود bare repository کی طرف اشارہ کرنے والا سادہ SSH remote بھی کسی forge software کے بغیر کام کرتا ہے۔

pull request کیا ہے؟

pull request ایک branch کو دوسری branch میں merge کرنے کی درخواست ہے، جس کے ساتھ discussion page بھی شامل ہوتا ہے۔ آپ ایک branch push کرتے ہیں، main کے خلاف PR کھولتے ہیں، اور host تبدیلی کو commit بہ commit دکھاتا ہے۔ اس طرح reviewers انفرادی lines پر comment کر سکتے ہیں، جبکہ automated checks pass یا fail کی اطلاع دے سکتے ہیں۔ یہ Git کی نہیں بلکہ GitHub کی feature ہے، اس لیے خود Git میں اس کے لیے کوئی command نہیں ہے۔ دوسرے hosts بھی یہی تصور نافذ کرتے ہیں اور بعض اوقات اسے merge request کہتے ہیں۔

کیا مجھے اپنے VPS پر GitHub Actions runner چلانا چاہیے؟

Private repository کے لیے اکثر ہاں۔ Job اس hardware پر چلتا ہے جس کی ادائیگی آپ پہلے ہی کر رہے ہیں، minutes کا الگ حساب نہیں ہوتا، build cache گرم رہتا ہے، اور deploy کے لیے internet پر inbound SSH key ظاہر کرنے کی ضرورت نہیں رہتی، کیونکہ runner outbound طور پر GitHub سے connect ہوتا ہے اور کام طلب کرتا ہے۔ Public repository کے لیے GitHub اس کی سفارش نہیں کرتا۔ کوئی بھی شخص آپ کی repo fork کر کے ایسا pull request کھول سکتا ہے جس کا workflow آپ کی machine پر code چلا دے۔

کیا میں بعد میں اپنی repositories کو GitHub سے منتقل کر سکتا ہوں؟

Code کو ہاں، آسانی سے۔ ہر clone مکمل history رکھتا ہے، اس لیے git remote set-url origin <new url> کے بعد push کرنے سے commit میں موجود ہر چیز منتقل ہو جاتی ہے۔ جو چیز پیچھے رہ جاتی ہے وہ GitHub کی ملکیت والی layer ہے۔ Issues، pull request discussions اور Actions history اس کے database میں رہتی ہیں، آپ کے .git folder میں نہیں۔ Migration tools API کے ذریعے issues copy کر سکتے ہیں، اور نئے host کے CI کے لیے workflow files میں عموماً تبدیلی کرنا پڑتی ہے۔ اس بات کو مدنظر رکھنا اس لیے اہم ہے کہ اصل documentation issue threads کے بجائے repository میں رکھی جائے۔