GitHub म्हणजे काय? VPS साठी Git आणि GitHub मधील फरक

GitHub म्हणजे काय?

GitHub ही hosted सेवा आहे. ती Git repositories साठवते आणि त्यांच्याभोवती एक website तयार करते. Git हा तुमच्या स्वतःच्या computer किंवा server वर चालणारा version control program आहे. GitHub हे Git वर आधारित एका कंपनीचे product आहे. 2018 पासून त्याची मालकी Microsoft कडे आहे. तुम्ही दररोज Git वापरू शकता आणि GitHub कधीही उघडण्याची गरज पडू शकत नाही. मात्र Git शिवाय GitHub वापरता येत नाही.

तुमच्याकडे VPS (virtual private server) असल्यास हा फरक लगेच महत्त्वाचा ठरतो. तुमच्या config files आणि deploy scripts मधील history नोंदवण्याचे काम Git करते. Server वर ही history उपलब्ध नसल्यास तिची एक copy GitHub वर ठेवता येते. तसेच GitHub वर builds आणि reviews चालवता येतात. हा guide एका रिकाम्या folder पासून server वरील deploy पर्यंतचे एक उदाहरण दाखवतो. त्यात प्रत्येक नवीन शब्द प्रथम आल्यावर त्याची व्याख्या दिली आहे.

Git स्वतः काय करते

Git ही version control system आहे. ती directory ची स्थिती कालांतराने नोंदवते, त्यामुळे काय, केव्हा आणि का बदलले हे पाहता येते. Linux kernel च्या कामासाठी ती 2005 मध्ये लिहिली गेली. Git distributed आहे. याचा अर्थ repository च्या प्रत्येक copy मध्ये संपूर्ण history असते. या रचनेत central server नसतो. सहकाऱ्याच्या laptop वरील copy कोणत्याही server वरील copyइतकीच पूर्ण असते.

Git install करा आणि तुमची identity सेट करा. name आणि email address शिवाय 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 print करते. मागील काही वर्षांतील कोणतेही release खालील सर्व बाबतीत याच प्रकारे काम करते.

उदाहरण: तुमच्या VPS deploy files साठी repository

repository, ज्याला सामान्यतः "repo" असे संक्षिप्त रूप दिले जाते, ही Git ज्या directory वर लक्ष ठेवते ती directory आहे. git init चालवल्यावर ती repository बनते. या command मुळे तिच्या आत लपलेली .git folder तयार होते. ती folder म्हणजेच repository आहे. .git delete केल्यावर history नसलेली सामान्य directory उरते.

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

-b main पहिल्या branch चे नाव main ठेवते. हा पर्याय वगळल्यास default branch name बद्दल Git मोठी सूचना दाखवते. Git ने कधीही track करू नयेत अशा paths ची यादी .gitignore मध्ये लिहिली जाते. तुमची secrets file पहिल्याच दिवशी त्यात लिहा. एखादी file एकदा commit झाल्यानंतर ती delete केली तरी history मध्ये राहते. ती योग्य प्रकारे काढण्यासाठी त्यानंतर झालेले प्रत्येक commit पुन्हा लिहावे लागते.

इतिहासातील एकक: 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 ही यादी इतिहासात एक entry म्हणून लिहिते. commit मध्ये प्रत्येक tracked file चा snapshot, एक message, author, timestamp आणि त्यापूर्वीच्या commit कडे निर्देश करणारा pointer असतो. git log --oneline प्रत्येक commit साठी एक ओळ छापते. प्रत्येक ओळ a1b2c3d सारख्या short hash ने सुरू होते. हा hash त्या commit चे नाव असतो आणि जवळपास प्रत्येक Git command तो स्वीकारते.

git add टप्पा वगळा आणि git commit चे उत्तर no changes added to commit (use "git add" and/or "git commit -a") असे येते. काहीही बिघडलेले नाही. staging area रिकामी असल्यामुळे snapshot करण्यासाठी काहीही नाही, असे Git सांगत आहे. तुम्ही गोंधळल्यास git status ही चालवायची command आहे. ती current branch, staged changes आणि Git ला दिसणाऱ्या पण तो tracking करत नसलेल्या files ची नावे दाखवते.

Branches: इतिहासाची दुसरी शाखा

branch म्हणजे एखाद्या commit कडे निर्देश करणारा बदलता pointer. main हा एक branch आहे आणि Git मध्ये तो कोणत्याही प्रकारे विशेष नाही. Branch तयार करण्यासाठी कोणताही खर्च येत नाही, कारण Git तुमच्या फाइल्सची प्रत बनवण्याऐवजी नवीन 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 दिसत नाही. काहीही हटवलेले नाही. ही फाइल add-backup branch वर अस्तित्वात आहे, पण main वर ती कधीच नव्हती. त्यामुळे तुम्ही branch बदलल्यावर Git ने ती तुमच्या working directory मधून काढली. हे एकदा तरी प्रत्येकाला आश्चर्यचकित करते. git switch add-backup ती फाइल परत आणतो.

Remotes: GitHub अखेर येथे दिसते

आत्तापर्यंतची सर्व कामे कोणतेही network वापरता एका मशीनवर झाली. remote म्हणजे त्याच repository च्या दुसऱ्या copy साठीचा नावासह URL. GitHub तुमच्यासाठी अशा copy पैकी एक host करते. मुख्य remote साठी प्रचलित नाव origin आहे.

GitHub website वरून रिकामी repository तयार करा आणि नंतर तिला connect करा. येथे HTTPS पेक्षा SSH ला प्राधान्य द्या: SSH key ही तुमच्या नियंत्रणात असलेली file असते. 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 page मध्ये paste करा आणि test पुन्हा चालवा. कार्यरत key Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. असे उत्तर देते. GitHub तुम्हाला shell access देत नाही, त्यामुळे हा नकार यशस्वी स्थिती दर्शवतो. git@github.com: Permission denied (publickey). याचा अर्थ तुमची key कधीही offer झाली नाही किंवा स्वीकारली गेली नाही. त्यामुळे तुम्ही तिच्या बाजूची private key नव्हे, तर .pub file paste केली आहे का ते तपासा.

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

git push तुमचे commits remote कडे पाठवते. -u local main चा मागोवा remote main घेत असल्याची नोंद करते. त्यामुळे पुढे bare git push पुरेसे ठरते. नवीन मशीनवर git clone <url> याच्या उलट कार्य करते: ते history सहित संपूर्ण repository copy करते आणि तुमच्यासाठी origin सेट करते. HTTPS remote देखील चालतो. तो कोणत्याही web page प्रमाणे त्याच protocol वरून network traffic पाठवतो. त्यामुळे outbound port 22 block करणाऱ्या networks वर तो उपयुक्त ठरतो. त्या वाक्याचा अर्थ स्पष्ट हवा असल्यास, प्रत्यक्षात HTTP request मध्ये काय असते येथे त्याची कार्यपद्धती दिली आहे.

Pull requests, issues आणि forks: GitHub चे भाग, Git चे नाही

वरील सर्व Git आहे आणि ते कोणत्याही सर्व्हरविरुद्ध कार्य करते. खालील तीन संज्ञा GitHub ची वैशिष्ट्ये आहेत. इतर hosts त्यांची नक्कल करतात, पण Git ला त्यांच्याबद्दल काहीही माहिती नसते.

Pull request (PR) म्हणजे एका branch चे दुसऱ्या branch मध्ये merge करण्याची विनंती. त्यासोबत चर्चेसाठी एक page असते. तुम्ही add-backup push करता आणि main विरुद्ध PR उघडता. त्यानंतर site प्रत्येक commit नुसार फरक दाखवते. लोक स्वतंत्र lines वर comments करू शकतात. Automated checks त्या branch साठी pass किंवा fail स्थिती कळवतात. Merge वर click केल्यावर GitHub स्वतःच्या copy मध्ये merge करते आणि नंतर main update करते. या नावाचा उगम मूळ workflow मधून झाला. त्यात maintainer ला तुमचा branch त्यांच्या branch मध्ये pull करण्याची विनंती केली जात असे.

Issue म्हणजे bug किंवा task साठी असलेला क्रमांकित thread. तो तुमच्या repository मध्ये नसून GitHub च्या database मध्ये असतो. Host निवडण्यापूर्वी हे लक्षात ठेवणे महत्त्वाचे आहे. Repo clone केल्यावर तुमच्याकडे प्रत्येक commit येतो, पण एकही issue येत नाही. Issues बाहेर काढण्यासाठी API call करावा लागतो.

Fork म्हणजे दुसऱ्या व्यक्तीच्या repository ची तुमच्या server वरील स्वतंत्र copy. या copy वर तुम्हाला write access असतो. तुम्ही त्यावर branch push करता आणि तुमच्या copy मधून त्यांच्या copy कडे pull request उघडता. Maintainers तुम्हाला ओळखत नसलेल्या project मध्ये योगदान देण्याचा हा मार्ग आहे. Fork म्हणजे GitHub वर असलेला clone, जो तो कुठून आला हे लक्षात ठेवतो.

Software ही तिन्ही वैशिष्ट्ये एखादी व्यक्ती वापरते त्याच API द्वारे वाचते. तुमच्या स्वतःच्या server वर चालणारा pull request review agent नवीन PR साठी लक्ष ठेवतो, diff वाचतो आणि line comments पोस्ट करतो. repository च्या root मध्ये असलेली AGENTS.md file यांसारख्या पद्धती अस्तित्वात आहेत, कारण repo आता लोकांसोबत tools देखील वाचतात.

VPS मालकासाठी GitHub प्रत्यक्षात काय करते

सुरुवात सर्व्हरबाहेरील संचयनापासून करा. तुमचे deploy scripts आणि playbooks ते ज्या सर्व्हरचे configuration करतात त्याच सर्व्हरवर ठेवू नका. VPS नवीन image वरून पुन्हा तयार करा, clone करा आणि चालवा. तो repository private ठेवा आणि सर्व्हरला deploy key द्या: संपूर्ण account ऐवजी एका repository शी नोंदणीकृत केलेली, read only स्वरूपाची SSH key. read-only deploy key लीक झाल्यास केवळ एक repository उघड होते. account key लीक झाल्यास तुम्ही ज्या सर्व repository मध्ये 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 नेहमीच अपघाती असते. त्यामुळे हा 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' मिळते. वेगळ्या user च्या मालकीचे repository वाचण्यास Git नकार देते, कारण hostile .git/config मुळे Git कडून commands चालवल्या जाऊ शकतात. safe.directory exception जोडण्याऐवजी chown वापरून ownership दुरुस्त करा. Exception check बंद करते, पण मूळ कारण दूर करत नाही.

GitHub Actions: build आणि deploy pipelines

Actions ही GitHub ची CI/CD प्रणाली आहे (continuous integration आणि continuous delivery). .github/workflows/ अंतर्गत YAML फाइल commit करा. तुम्ही निर्दिष्ट केलेली event घडल्यावर 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 म्हणजे एक command किंवा प्रकाशित केलेली action. uses: दुसऱ्या repository मधून action आणते आणि @v7 तिची major version निश्चित करते (August 2026 पर्यंत actions/checkout साठी v7 ही सध्याची आवृत्ती आहे). नेहमी version निश्चित करा. कारण version निश्चित न केलेली action तुम्ही न वाचलेला code तुमच्या secrets च्या access सह चालवते.

runs-on: ubuntu-latest GitHub कडे नवीन virtual machine मागते. job संपल्यावर ती नष्ट केली जाते. सार्वजनिक 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 चा access मिळत नाही. अन्यथा अनोळखी व्यक्ती असा PR उघडू शकते ज्याचे एकमेव काम ते secrets print करणे असेल.

तुमच्या स्वतःच्या VPS वर Actions runner चालवणे

runs-on: self-hosted जॉब तुमच्या मालकीच्या मशीनकडे पाठवते. Repository च्या runner settings पेजवर download line, repository web address आणि एका तासासाठी वैध registration token दिला जातो. शेवटच्या दोन गोष्टी 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 लिहिते. ही पायरी अनेक जण वगळतात. तिच्याशिवाय तुमचे SSH session बंद होताच runner बंद होतो आणि त्यानंतरचे प्रत्येक job कोणतेही कारण न दाखवता queued स्थितीत राहते. VPS वर self-hosted runner setup ची संपूर्ण माहिती दीर्घकाळ चालणाऱ्या runner साठी आवश्यक hardening आणि cleanup समजावते.

याचा फायदा असा की deploy साठी इंटरनेटवरून पोहोचता येणारी inbound SSH key आवश्यक राहत नाही, कारण job आधीच त्या मशीनवर चालू असतो. Build cache देखील runs दरम्यान उपलब्ध राहतो आणि कोणतेही minute meter मोजले जात नाही.

एक महत्त्वाची सूचना दुर्लक्षित करू नका. GitHub च्या अधिकृत documentation नुसार self-hosted runners फक्त private repositories साठी वापरण्याची शिफारस केली जाते. कारण public repository चे forks pull request उघडून तुमच्या runner वर धोकादायक code चालवू शकतात. त्या branch वरील workflow file मध्ये जे सांगितले असेल ते runner execute करतो. कोणाला push करण्याचा अधिकार आहे हे तुम्ही नियंत्रित करत असलेल्या private repo मध्ये जोखीम कमी असते. Public repo मध्ये कोणताही self-hosted runner म्हणजे अनोळखी व्यक्तींना code execute करता येणारी मशीन समजा.

GitHub ची मुळीच गरज आहे का?

नाही. Git हे मानक आहे आणि GitHub ही सुविधा आहे. Forgejo आणि Gitea हे self-hosted forge आहेत. Forge म्हणजे issues आणि pull requests जोडलेला Git host. दोन्ही एकाच Go binary स्वरूपात उपलब्ध होतात आणि दोन्ही लहान VPS वर चालतात. Forgejo हा Gitea चा 2022 मधील fork आहे आणि आता Codeberg ला सामर्थ्य देतो. वायर protocol समान असल्यामुळे repository हलवण्यासाठी एकच command पुरेसा आहे.

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

प्रत्येक commit हलतो, कारण प्रत्येक clone मध्ये संपूर्ण history आधीपासून असते. GitHub ने त्यावर तयार केलेला स्तर मात्र हलत नाही: issues आणि pull request threads. CI देखील transfer होत नाही. Forgejo मध्ये स्वतःची Actions implementation आहे. ती .forgejo/workflows/ मधून समान स्वरूपातील YAML वाचते. मात्र मर्यादांबाबत त्याचे documentation स्पष्ट आहे: GitHub Actions आणि Forgejo Actions समान नाहीत आणि सर्व गोष्टी लगेच कार्य करतीलच असे नाही. त्यासाठी स्वतंत्र runner देखील आवश्यक आहे. या टप्प्याचे नियोजन copy म्हणून नव्हे, तर port म्हणून करा.

बहुतेक projects GitHub वरच राहण्याचे खरे कारण contributors हे आहे. 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 झाले आहे. बहुतेकदा ते web editor मध्ये केलेले edit असते. तुमचे commits त्यांच्या commits च्या वर पुन्हा लागू करण्यासाठी git pull --rebase चालवा आणि त्यानंतर पुन्हा push करा. Shared branch वर git push --force टाळा, कारण त्यामुळे server वरील त्या branch मधील इतर commits काढले जातात.

fatal: refusing to merge unrelated histories. तुम्ही स्थानिक पातळीवर git init चालवले आणि GitHub कडून README सह repository तयार करून घेतली. या दोन इतिहासांमध्ये एकही समान commit नाही. त्यामुळे Git अंदाज लावू शकत नाही. योग्य उपाय म्हणजे GitHub ची copy नवीन folder मध्ये clone करणे आणि तुमच्या files त्या folder मध्ये हलवणे.

error: src refspec main does not match any. तुम्ही नमूद केलेली branch येथे अस्तित्वात नाही. सहसा repository मध्ये अद्याप एकही commit नसतो किंवा तुमच्या branch चे नाव master असते. git branch --show-current चालवल्याने ही समस्या सुटते.

एखादा secret commit मध्ये पोहोचला आहे. Credential त्वरित rotate करा. तो push केल्याच्या क्षणापासून सार्वजनिक मानला पाहिजे, कारण forks, mirrors आणि cached views मध्ये त्याच्या copies असतात आणि त्या तुम्ही delete करू शकत नाही.

FAQ

GitHub आणि Git एकच गोष्ट आहेत का?

नाही. Git हा तुम्ही मशीनवर install करणारा version control program आहे. तो network आणि account शिवायही कार्य करतो. GitHub ही Git repositories साठवणारी commercial hosted service आहे. त्यासोबत web interface, issues, pull requests आणि CI यांसारख्या सुविधा मिळतात. Git 2005 मध्ये released झाला आणि त्यावर आधारित GitHub 2008 मध्ये launched झाले. तुम्ही GitHub शिवाय Git कायम वापरू शकता. GitHub मधील प्रत्येक feature अंतर्गत Git वर अवलंबून असते.

माझ्या VPS वर Git वापरण्यासाठी मला GitHub account आवश्यक आहे का?

नाही. git init, git commit आणि git log कोणताही remote configured नसलेल्या server वर कार्य करतात. त्यामुळे /etc files मधील बदल track करण्यासाठी किंवा deploy scripts साठी ते पुरेसे आहे. Server टिकला नाही तरी history ची copy ठेवायची असेल किंवा दुसऱ्या machine वरून repository clone करायची असेल, तेव्हा account उपयुक्त ठरते. 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 नुसार दाखवतो. त्यामुळे reviewers स्वतंत्र lines वर comment करू शकतात आणि automated checks pass किंवा fail याची माहिती देऊ शकतात. हे GitHub चे feature आहे, Git चे नाही. त्यामुळे Git मध्ये यासाठी स्वतंत्र command नाही. इतर hosts हीच संकल्पना कधी कधी merge request या नावाने लागू करतात.

माझ्या स्वतःच्या VPS वर GitHub Actions runner चालवावा का?

Private repository साठी अनेकदा होय. Job तुम्ही आधीच पैसे देत असलेल्या hardware वर चालतो. Minutes साठी स्वतंत्र मोजणी होत नाही. Build cache उपलब्ध राहतो. तसेच deploy साठी internet वर inbound SSH key उघडी ठेवण्याची गरज राहत नाही, कारण runner GitHub शी outbound connection करून कामाची विनंती करतो. Public repository साठी GitHub असे करण्याचा सल्ला देत नाही. कोणतीही व्यक्ती तुमची repo fork करून असा pull request उघडू शकते, ज्याचा workflow तुमच्या machine वर code चालवेल.

मी नंतर माझ्या repositories GitHub वरून हलवू शकतो का?

Code सहजपणे हलवता येतो. प्रत्येक clone मध्ये complete 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 मध्ये ठेवण्याचे कारण स्पष्ट होते.