Self-hosted Git server: Forgejo, Gitea या cgit चुनें

आपको कौन सा self-hosted Git server चलाना चाहिए

एक self-hosted Git server कोई एक उत्पाद नहीं है, और आपके VPS की RAM (random access memory) यह तय करती है कि आप इसका कौन सा संस्करण चला सकते हैं। Git को अपने स्वयं के किसी daemon की आवश्यकता नहीं होती है: एक bare repository और एक SSH (secure shell) account सबसे छोटे सर्वर पर भी काम करने के लिए पर्याप्त हैं। इसके ऊपर की हर चीज़ एक web application है जिसे आप उसके साथ चलाना चुनते हैं, और हर स्तर पर ऐसी memory की आवश्यकता होती है जो एक छोटे VPS में शायद न हो।

इसके चार चरण हैं। SSH के माध्यम से एक bare repository, जिसमें कोई अतिरिक्त सेवा listening मोड में नहीं होती। cgit, एक तेज़ read-only web view जिसमें कोई database नहीं होता। Forgejo या Gitea, एक पूर्ण forge जिसमें कुछ सौ megabytes में accounts, issues और pull requests की सुविधा होती है। GitLab, जिसके लिए अन्य विकल्पों की तुलना में कई गुना बड़े सर्वर की आवश्यकता होती है।

अपने काम की जरूरतों के आधार पर निर्णय लें, और फिर अपने द्वारा लिए गए प्लान की memory क्षमता की जांच करें।

प्रत्येक विकल्प के लिए वास्तविक RAM की आवश्यकता

इनमें से केवल दो प्रोजेक्ट हार्डवेयर संबंधी आंकड़े प्रकाशित करते हैं। प्रकाशित आंकड़ों को एक न्यूनतम सीमा मानें, न कि कोई गारंटी। एक बार जब आपका instance चलने लगे, तो systemd-cgtop या ps -o rss= -C forgejo का उपयोग करके स्वयं मापें।

[
  {
    "label": "Gitea, small team",
    "ram_gb": 1
  },
  {
    "label": "GitLab, memory constrained",
    "ram_gb": 8
  },
  {
    "label": "GitLab, single node baseline",
    "ram_gb": 16
  }
]

Gitea छोटी टीमों और प्रोजेक्ट्स के लिए सामान्यतः 2 CPU cores के साथ 1 GB RAM को पर्याप्त बताता है, और छोटे workloads के लिए Raspberry Pi 3 का उल्लेख करता है। GitLab सिंगल नोड इंस्टॉलेशन के लिए 16 GB को आधार मानता है, और जिसे वह स्वयं memory constrained environment कहता है, उसके लिए 8 GB को न्यूनतम सीमा बताता है। Forgejo कोई हार्डवेयर आवश्यकता प्रकाशित नहीं करता है। यह Gitea का एक fork है और उसी की तरह व्यवहार करता है, इसलिए Gitea के आंकड़े ही आपके पास उपलब्ध सबसे सटीक मार्गदर्शिका हैं।

1 GB VPS पर इसका अर्थ यह है कि bare repositories और cgit पर्याप्त जगह के साथ चल सकते हैं, क्योंकि इनमें से कोई भी resident service नहीं चलाता है। Forgejo या Gitea शुरू हो जाएंगे और SQLite पर एक छोटी टीम को सेवा दे पाएंगे, लेकिन चूंकि आप दस्तावेज़ में बताई गई न्यूनतम सीमा पर हैं, इसलिए उस बॉक्स पर PostgreSQL और CI (continuous integration) runner को न चलाएं। यदि वेब इंटरफेस बिना किसी त्रुटि के गायब हो जाता है, तो sudo dmesg -T | grep -i oom चलाएं और Out of memory: Killed process 1181 (forgejo) जैसी लाइन खोजें, जिसका अर्थ है कि kernel out of memory killer ने इसे बंद कर दिया है। 1 GB बॉक्स पर GitLab चलाना tuning की समस्या नहीं है। यह वहां नहीं चलेगा।

Tier 0: SSH के माध्यम से एक bare repository

Git के लिए आपको किसी network daemon को start करने की आवश्यकता नहीं होती है। SSH पर git push चलाने से दूरस्थ छोर पर git-receive-pack एक सामान्य Unix process के रूप में चलता है, इसलिए जिस भी account तक आप key के साथ पहुँच सकते हैं, वह पहले से ही एक Git remote है। repositories के लिए एक account बनाएँ और repositories को उसके home directory के बाहर रखें, क्योंकि Ubuntu 24.04 पर एक नई home directory का mode 0750 होता है और बाद में जोड़ा गया web view उसमें read नहीं कर पाएगा।

sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git
sudo install -d -m 0755 -o git -g git /srv/git
sudo -u git git init --bare /srv/git/project.git

--bare एक ऐसी repository बनाता है जिसमें कोई working copy नहीं होती, जो कि एक सर्वर पर होनी चाहिए। ऐसी repository में push करना जिसमें working copy मौजूद हो, refusing to update checked out branch: refs/heads/main के साथ अस्वीकार कर दिया जाता है, और इस स्तर पर यह सबसे आम गलती है।

अब account को एक key दें और उसे clone करें।

sudo -u git install -d -m 700 /home/git/.ssh
sudo -u git tee -a /home/git/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop
EOF
sudo -u git chmod 600 /home/git/.ssh/authorized_keys

git remote add origin git@vps.example.com:/srv/git/project.git
git push -u origin main

पहला सफल push * [new branch] main -> main के साथ समाप्त होता है। जो push git@vps.example.com: Permission denied (publickey) के साथ समाप्त होता है, वह कभी authenticate नहीं हुआ था, इसलिए sudo journalctl -u ssh -n 20 के साथ सर्वर log पढ़ें। Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys पढ़ने वाली एक पंक्ति का अर्थ है कि file mode गलत है, क्योंकि sshd उस key file को ignore कर देता है जिसे अन्य users लिख सकते हैं।

इसके बाद account से shell access हटा दें।

command -v git-shell | sudo tee -a /etc/shells
sudo chsh -s "$(command -v git-shell)" git

git-shell केवल उन कुछ commands को स्वीकार करता है जिन्हें Git, SSH के माध्यम से भेजता है, इसलिए एक interactive login अब prompt के बजाय एक संदेश के साथ रुक जाता है:

fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.

यह पूरा सर्वर है। इसमें कोई database नहीं है और न ही upgrade करने के लिए कोई web process है। आप वह सब खो देते हैं जो एक forge प्रदान करता है: कोई browsing नहीं, कोई issue tracker नहीं, कोई pull requests नहीं, और प्रति-user कोई permission नहीं। उस file में मौजूद हर key, git user के स्वामित्व वाली हर repository को read और write कर सकती है।

Tier 1: cgit आपको बिना डेटाबेस के वेब व्यू प्रदान करता है

cgit, C भाषा में लिखा गया एक CGI (common gateway interface) प्रोग्राम है। वेब सर्वर इसे प्रत्येक अनुरोध पर एक बार चलाता है, यह सीधे डिस्क से रिपॉजिटरी को पढ़ता है और अपनी कोई स्थिति (state) स्टोर नहीं करता है। Ubuntu 24.04 इसे अपने universe कंपोनेंट में प्रदान करता है।

sudo apt update
sudo apt install -y cgit fcgiwrap nginx
sudo install -d -o www-data -g www-data /var/cache/cgit

इसे /etc/cgitrc में रिपॉजिटरी डायरेक्टरी की ओर निर्देशित करें:

root-title=Git on example.com
css=/cgit.css
logo=/cgit.png
cache-size=1000
cache-root=/var/cache/cgit
snapshots=tar.gz zip
scan-path=/srv/git

scan-path उस डायरेक्टरी को स्कैन करता है और मिलने वाली प्रत्येक रिपॉजिटरी को सूचीबद्ध करता है, इसलिए एक नई bare रिपॉजिटरी बिना किसी अतिरिक्त कॉन्फ़िगरेशन के दिखाई देती है। cache-size कैश किए गए पेजों की संख्या है, और जब तक यह शून्य है, कैशिंग बंद रहती है। लाइनें जोड़ने से पहले यह पढ़ें कि आपके पैकेज ने पहले से ही /etc/cgitrc में क्या रखा है, क्योंकि Debian और Ubuntu पैकेज अपने कुछ डिफॉल्ट्स के साथ आते हैं।

प्रत्येक प्रविष्टि रिपॉजिटरी की description फाइल की पहली लाइन दिखाती है, इसलिए एक नई bare रिपॉजिटरी खुद को Unnamed repository; edit this file 'description' to name the repository. के रूप में सूचीबद्ध करती है। इसे प्रति रिपॉजिटरी एक बार ठीक करें:

echo 'Project X, internal tooling' | sudo -u git tee /srv/git/project.git/description

server {
    listen 80;
    server_name git.example.com;
    root /usr/share/cgit;

    try_files $uri @cgit;

    location @cgit {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
        fastcgi_param PATH_INFO $uri;
        fastcgi_param QUERY_STRING $args;
        fastcgi_param HTTP_HOST $server_name;
        fastcgi_pass unix:/run/fcgiwrap.socket;
    }
}

sudo systemctl enable --now fcgiwrap.socket
sudo nginx -t && sudo systemctl reload nginx
systemctl show fcgiwrap.socket -p Listen

इस पर निर्माण करने से पहले दो सीमाओं को जानना आवश्यक है। cgit केवल रीड-ओनली है और इसमें कोई लॉगिन नहीं है, इसलिए scan-path के अंतर्गत सब कुछ सार्वजनिक है: किसी प्राइवेट रिपॉजिटरी को उस डायरेक्टरी से बाहर रखें, या पूरी साइट के सामने HTTP बेसिक ऑथेंटिकेशन लगाएँ। और CGI वेब सर्वर यूजर के रूप में चलता है, इसलिए उस यूजर को /srv/git को पार करने और प्रत्येक रिपॉजिटरी को पढ़ने की अनुमति होनी चाहिए। जिस डायरेक्टरी में वह प्रवेश नहीं कर सकता, वह एरर के बजाय खाली इंडेक्स के रूप में दिखाई देती है।

Tier 2: Issues और pull requests के लिए Forgejo या Gitea

Forgejo और Gitea एक ही विचार पर आधारित हैं: एक Go binary जो users, organisations, issues, pull requests, releases, एक package registry और एक built-in CI system के साथ web forge प्रदान करती है। Binary और SQLite मिलकर पूरा installation बनाते हैं, यही कारण है कि ये ऐसे hardware पर भी चल जाते हैं जिसे GitLab support नहीं करता। नीचे दिया गया Compose file, Forgejo documentation में दिया गया file है, जिसमें August 2026 के अनुसार image tag का उपयोग किया गया है।

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:3000 | head -1

curl line को एक HTTP status line print करनी चाहिए। first-run setup पूरा करने से पहले यह /install पर एक redirect हो सकता है, जिसका अर्थ है कि service चालू है। यदि container इसके बजाय exit हो जाता है, तो इसका सामान्य कारण ownership है: ./forgejo directory का स्वामित्व USER_UID में दिए गए UID (user id) के पास होना चाहिए, अन्यथा process अपनी data directory में लिख नहीं पाएगा। VPS पर Docker Compose उस file layout और volume ownership नियम को विस्तार से समझाता है।

setup page पर दो उत्तर यह तय करते हैं कि clone URLs काम करेंगे या नहीं। SSH port 222 होना चाहिए, क्योंकि Compose file host port 222 को container के port 22 पर map करता है, और domain वही नाम होना चाहिए जिसे लोग वास्तव में type करेंगे। यदि इनमें से कोई भी गलत हुआ, तो हर repository page एक ऐसा clone command दिखाएगा जो उसे copy करने वाले हर व्यक्ति के लिए fail हो जाएगा। बाद में ये दोनों app.ini के [server] section में SSH_PORT, SSH_DOMAIN और ROOT_URL के रूप में मौजूद रहते हैं।

public instance के लिए, web port को केवल loopback address ('127.0.0.1:3000:3000') पर publish करें और TLS (transport layer security) के लिए इसके सामने nginx लगाएँ। Gitea भी gitea/gitea image से इसी तरह install होता है, या एक single binary के रूप में एक systemd unit और एक app.ini के साथ, और August 2026 तक इसका current stable release 1.27.1 है।

जब तक संभव हो SQLite पर ही रहें। यह instance को एक process और एक file तक सीमित रखता है, और बिना किसी अतिरिक्त service की निगरानी के reboot के बाद भी सुरक्षित रहता है। PostgreSQL का उपयोग तब सार्थक होता है जब कई लोग एक साथ write कर रहे हों, क्योंकि SQLite writes को serialize करता है और लंबे CI runs लगातार write करते रहते हैं। दोनों projects बाद में एक existing instance को PostgreSQL पर migrate करने की सुविधा देते हैं, इसलिए यह ऐसा निर्णय नहीं है जिससे आप बंधे रहेंगे।

Forgejo या Gitea: वास्तविक अंतर क्या है

इनका इतिहास साझा है। Gitea को 2016 में Gogs से fork किया गया था। 2022 के अंत में Gitea डोमेन और ट्रेडमार्क का नियंत्रण Gitea Ltd नामक कंपनी के पास चला गया, और कई maintainers ने Codeberg के साथ मिलकर Forgejo की शुरुआत की। Forgejo को जर्मनी में पंजीकृत एक गैर-लाभकारी संस्था, Codeberg e.V. द्वारा प्रकाशित किया जाता है, और 2024 में यह MIT लाइसेंस से हटकर GPLv3 (GNU general public license version 3) पर आ गया। Gitea MIT लाइसेंस के तहत ही है और इसे व्यावसायिक समर्थन के साथ विकसित किया जाता है।

दैनिक उपयोग में इनके feature sets काफी समान हैं। लेकिन इनके बीच का रास्ता आसान नहीं है। जनवरी 2025 का Forgejo v10.0, अंतिम ऐसा release था जो सीधे Gitea डेटाबेस को स्वीकार कर सकता था, और वह भी केवल Gitea v1.22 या उससे पुराने संस्करणों से। अगस्त 2026 तक Gitea 1.27.1 पर है, इसलिए वर्तमान Gitea instance से Forgejo पर जाने का कोई समर्थित इन-प्लेस तरीका नहीं है। डेटा भरने से पहले ही किसी एक को चुनें, और बाद में किसी भी बदलाव को export और re-import के रूप में ही देखें।

चयन करने के लिए एक संक्षिप्त नियम। यदि शासन (governance) आपके लिए मायने रखता है, या आप चाहते हैं कि प्रोजेक्ट एक गैर-लाभकारी संस्था के पास रहे, तो Forgejo चलाएं। यदि आप बड़ा install base और व्यावसायिक समर्थन विकल्प चाहते हैं, तो Gitea चलाएं। दोनों का रखरखाव ओपन सोर्स के रूप में होता है और इनके release अक्सर आते हैं: Forgejo हर तीन महीने में एक stable release और हर साल एक LTS (long term support) release जारी करता है, जिसमें अगस्त 2026 तक v16.0.2 वर्तमान है और v15.0.6 LTS है।

Tier 3: GitLab के लिए आवश्यक संसाधन

GitLab CE एक अलग श्रेणी का सॉफ्टवेयर है। एक instance कई सहयोगी सेवाओं का समूह है: वेब एप्लिकेशन के लिए Puma, बैकग्राउंड जॉब्स के लिए Sidekiq, PostgreSQL, Redis, रिपॉजिटरी एक्सेस के लिए Gitaly और सामने की तरफ nginx। Omnibus पैकेज इन्हें एक साथ इंस्टॉल करता है, जिससे इंस्टॉलेशन तो सरल हो जाता है लेकिन मेमोरी की न्यूनतम आवश्यकता काफी अधिक हो जाती है।

GitLab का requirements पेज सिंगल नोड इंस्टॉलेशन के लिए 16 GB RAM और 8 vCPU को आधार मानता है, जबकि मेमोरी की कमी वाले वातावरण में 8 GB को न्यूनतम बताया गया है। वही पेज आपको swap डिसेबल करने की सलाह देता है, क्योंकि लोड के दौरान swap का उपयोग instance के प्रदर्शन को बुरी तरह प्रभावित करता है। अगस्त 2026 तक के ये प्रकाशित आंकड़े हैं, और वर्षों के दौरान इनमें वृद्धि हुई है, इसलिए सर्वर का आकार तय करने से पहले पेज को दोबारा पढ़ें।

इस बजट के बदले आपको वास्तविक सुविधाएं मिलती हैं: एक कंटेनर रजिस्ट्री, एक पैकेज रजिस्ट्री, सूक्ष्म अनुमतियां (fine-grained permissions), अनुपालन और ऑडिट फीचर्स, और CI जिसे बड़े पैमाने पर टेस्ट किया गया है। यदि आपकी टीम में कोई भी व्यक्ति इस सूची से ऐसी किसी चीज का नाम नहीं ले सकता जिसकी उन्हें इस तिमाही में आवश्यकता है, तो आप बिना किसी लाभ के एक बड़े VPS के लिए भुगतान कर रहे हैं।

SSH एक्सेस मॉडल: एक git यूजर और कई कीज़ (keys)

यहाँ हर टियर (tier) एक ही तरीके से ऑथेंटिकेट करता है। इसमें git नाम का एक Unix अकाउंट होता है, और हर पब्लिक की (public key) उस अकाउंट की ~/.ssh/authorized_keys फाइल में जाती है। ऑथेंटिकेशन की (key) के जरिए होता है। ऑथोराइजेशन वह विकल्प है जिसे आप उसी लाइन में की (key) के आगे लिखते हैं।

एक साधारण की (key) लाइन होल्डर को वह सब कुछ करने की अनुमति देती है जो वह अकाउंट कर सकता है। एक forced command इसे Git तक सीमित कर देती है:

restrict,command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop

restrict, जो OpenSSH 7.2 के बाद से उपलब्ध है, एक ही शब्द में पोर्ट फॉरवर्डिंग, एजेंट फॉरवर्डिंग, X11 और PTY (स्यूडो टर्मिनल) एलोकेशन को बंद कर देता है। command= क्लाइंट द्वारा मांगी गई किसी भी चीज़ को आपके द्वारा बताए गए कमांड से बदल देता है, और Git फिर भी काम करता है क्योंकि Git अपना अनुरोध $SSH_ORIGINAL_COMMAND में भेजता है।

एक फोर्ज (forge) आपके लिए वह फाइल लिखता है, और टियर 0 और टियर 2 के बीच यही वास्तविक अंतर है। Forgejo और Gitea हर रजिस्टर्ड की (key) के लिए एक लाइन के साथ authorized_keys को फिर से लिखते हैं, जिसमें प्रत्येक में एक forced command होती है जो की (key) को उसकी डेटाबेस आईडी से पहचानती है:

command="/usr/local/bin/forgejo --config=/etc/forgejo/app.ini serv key-3",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice

वह forced command ही है जिससे एक साझा Unix अकाउंट प्रति-यूजर अनुमति (per-user permission) में बदल जाता है: key-3 फोर्ज को बताता है कि कौन सा यूजर कनेक्ट कर रहा है, और यह किसी भी ऑब्जेक्ट के मूव होने से पहले उस यूजर को रिपॉजिटरी के खिलाफ चेक करता है। फोर्ज द्वारा मैनेज किए जाने वाले बॉक्स पर उस फाइल को मैन्युअल रूप से एडिट न करें, क्योंकि इसे डेटाबेस से फिर से लिखा जाता है और आपकी जोड़ी गई लाइन गायब हो जाएगी। डिप्लॉय कीज़ (deploy keys) भी इसी मैकेनिज्म से आती हैं: एक डिप्लॉय की (deploy key) एक सामान्य SSH की (key) होती है जो एक सिंगल रिपॉजिटरी के लिए रजिस्टर्ड होती है, आमतौर पर रीड-ओनली, और इसका चेक sshd के बजाय फोर्ज में किया जाता है।

ऊपर दी गई किसी भी कॉन्फ़िगरेशन से अधिक दो आदतें मायने रखती हैं। प्रति व्यक्ति या प्रति मशीन एक की (key) जारी करें, कभी भी साझा की (shared key) का उपयोग न करें, क्योंकि साझा की (shared key) को रद्द करने का मतलब है कि सभी के लिए इसे एक साथ बदलना। और जिस दिन कोई व्यक्ति छोड़ कर जाए, उसकी की (key) को हटा दें, क्योंकि उस फाइल में मौजूद एक पुरानी की (key) एक ऐसा स्थायी लॉगिन है जिस पर कोई नज़र नहीं रख रहा है। सर्वर पर बेहतर SSH की (key) मैनेजमेंट की (key) के प्रकारों और पासफ्रेज को कवर करता है, और यह सब यहाँ बिना किसी बदलाव के लागू होता है। यदि बॉक्स नया है, तो रिपॉजिटरी डालने से पहले नए VPS पर शुरुआती दस मिनट का पालन करना सही रहता है।

क्या मैं अपने Git सर्वर पर GitHub Actions चला सकता हूँ?

आप GitHub Actions सिंटैक्स में लिखे गए वर्कफ़्लो चला सकते हैं। आप GitHub नहीं चला सकते। Forgejo v1.21 के बाद से Forgejo Actions डिफ़ॉल्ट रूप से सक्षम है और यह प्रत्येक रिपॉजिटरी में .forgejo/workflows से वर्कफ़्लो फ़ाइलें पढ़ता है। Gitea Actions भी इसी तरह काम करता है और .gitea/workflows को पढ़ता है। दोनों को एक दूसरे प्रोग्राम, रनर (runner), की आवश्यकता होती है, जिसे एडमिन सेटिंग्स से प्राप्त टोकन के साथ आपके इंस्टेंस पर इंस्टॉल और रजिस्टर किया जाना चाहिए। कई प्रकाशित (published) एक्शन्स बिना किसी बदलाव के चलते हैं; जो कुछ भी GitHub API को कॉल करता है या GitHub-होस्टेड इंफ्रास्ट्रक्चर की अपेक्षा करता है, वह काम नहीं करेगा।

दो परिणामों के लिए योजना बनाएँ। रनर प्रत्येक जॉब के लिए एक कंटेनर शुरू करता है, इसलिए इसे एक कंटेनर इंजन और अपनी मेमोरी बजट की आवश्यकता होती है, यही कारण है कि इसे फोर्ज (forge) वाले 1 GB बॉक्स पर नहीं रखना चाहिए। और रनर वही निष्पादित (execute) करता है जो वर्कफ़्लो फ़ाइल में लिखा होता है, जिसे Forgejo का दस्तावेज़ीकरण स्पष्ट शब्दों में बताता है: रनर रिमोट कोड निष्पादन (remote code execution) करता है। जहाँ संभव हो इसे अपना अलग होस्ट दें, या कम से कम इसे एक अनप्रिविलेज्ड (unprivileged) यूजर और केवल एक रिपॉजिटरी तक सीमित रजिस्ट्रेशन टोकन दें।

यदि आपकी रिपॉजिटरी GitHub पर ही रह रही हैं और आप केवल अपने नियंत्रण वाले हार्डवेयर पर कंप्यूटिंग करना चाहते हैं, तो यह एक अलग सेटअप है जिसके चरण अलग हैं: a self-hosted GitHub Actions runner एक GitHub रिपॉजिटरी से जुड़ता है और इसमें इनमें से किसी की आवश्यकता नहीं होती है। यदि आप अभी भी यह तौल रहे हैं कि GitHub छोड़ने की क्या लागत है, तो what GitHub actually gives you Git होस्टिंग को उसके आसपास के नेटवर्क से अलग करके समझाता है।

बैकअप: रिपॉजिटरी केवल आधी स्थिति है

एक bare रिपॉजिटरी एक डायरेक्टरी होती है, इसलिए इसे कॉपी करने से इसमें मौजूद सब कुछ कॉपी हो जाता है। किसी अन्य मशीन से किया गया mirror clone एक वास्तविक बैकअप है, और यह इन-प्लेस रिफ्रेश होता है:

git clone --mirror git@vps.example.com:/srv/git/project.git
cd project.git && git remote update

यह हर ref और हर object को पुल करता है। यह सर्वर-साइड hooks या description फ़ाइल को पुल नहीं करता है, इसलिए यदि आप hooks का उपयोग करते हैं तो डायरेक्टरी की फ़ाइल-लेवल कॉपी भी रखें।

एक फोर्ज (forge) अपने डेटाबेस में issues, pull requests, users, keys और permissions को सुरक्षित रखता है, और केवल रिपॉजिटरी की कॉपी रखने से यह सब छूट जाता है। दोनों प्रोजेक्ट्स एक dump कमांड प्रदान करते हैं जो डेटाबेस, रिपॉजिटरी, कॉन्फ़िगरेशन और अटैचमेंट्स को एक आर्काइव में लिखता है:

sudo -u git forgejo dump -c /etc/forgejo/app.ini -f /var/backups/forgejo-dump.zip

Docker के अंतर्गत वही कमांड कंटेनर के अंदर चलती है, और कॉन्फ़िगरेशन पाथ इमेज पर निर्भर करता है, इसलिए टाइप करने से पहले जाँच लें:

docker compose exec server ls /data/gitea/conf
docker compose exec -u git server forgejo dump -c /data/gitea/conf/app.ini

इसे उस यूज़र के रूप में चलाएं जिसके पास डेटा का स्वामित्व है, और आर्काइव को ऐसी डायरेक्टरी में लिखें जहाँ वह यूज़र लिख सके। फिर आर्काइव को सर्वर से बाहर कॉपी करें, क्योंकि जो बैकअप केवल उसी मशीन पर मौजूद है जिसका बैकअप लिया जा रहा है, वह बैकअप नहीं है। रिस्टोर करना वह चरण है जिसे लोग छोड़ देते हैं: अभी एक अतिरिक्त मशीन पर एक डंप को अनपैक करें, ताकि आप आउटेज के दौरान हड़बड़ाने के बजाय शांत समय में प्रक्रिया सीख सकें।

परिदृश्य के अनुसार चयन

एक व्यक्ति, एक लैपटॉप और एक VPS, ब्राउज़िंग की आवश्यकता नहीं: SSH पर bare repositories का उपयोग करें। इसमें कोई अतिरिक्त सर्विस नहीं चलती और न ही किसी चीज़ को अपग्रेड करने की आवश्यकता होती है।

वही स्थिति, लेकिन आप ब्राउज़र में कोड पढ़ना चाहते हैं और लिंक साझा करना चाहते हैं: cgit जोड़ें। इसमें भी किसी डेटाबेस की आवश्यकता नहीं है और कोई सर्विस बैकग्राउंड में नहीं चलती।

एक टीम जो एक-दूसरे के कोड की समीक्षा करती है और issues ट्रैक करती है: 2 GB RAM या उससे अधिक पर Forgejo या Gitea का उपयोग करें। जब CI jobs का लोड बढ़ जाए, तो CI runner को दूसरे सर्वर पर स्थानांतरित कर दें।

एक संगठन जिसे container registry और audit trails की आवश्यकता है, और सर्वर के लिए 16 GB RAM उपलब्ध है: GitLab का उपयोग करें। यदि बजट इससे कम है, तो इसे शुरू न करें।

पहले तीन स्तरों के बीच अपग्रेड करना सस्ता है, क्योंकि इन सभी में repositories डिस्क पर सामान्य Git directories होती हैं। उस निचले स्तर से शुरुआत करें जो आपका काम पूरा कर दे। यदि आप यह तय कर रहे हैं कि उसी सर्वर पर और क्या जगह पाने का हकदार है, तो self-hosting के लिए उपयोगी सेवाओं की सूची में Git सर्वर को उन अन्य सेवाओं के साथ रखा गया है जो RAM के लिए प्रतिस्पर्धा करती हैं।

FAQ

क्या 1 GB RAM वाले VPS पर Forgejo या Gitea चल सकता है?

हाँ, एक छोटी टीम के लिए, SQLite का उपयोग करते हुए, यदि सर्वर पर कोई अन्य भारी प्रक्रिया न चल रही हो। Gitea का दस्तावेज़ीकरण बताता है कि 1 GB RAM और 2 CPU कोर छोटी टीमों और प्रोजेक्ट्स के लिए पर्याप्त हैं, और Forgejo, Gitea का ही एक fork है जिसकी आवश्यकताएं समान हैं। उस मशीन पर PostgreSQL या CI runner न जोड़ें। यदि सेवा बिना किसी त्रुटि के बंद हो जाती है, तो sudo dmesg -T | grep -i oom चलाएं: यदि आउटपुट में कोई प्रक्रिया का नाम दिखता है, तो इसका मतलब है कि kernel के out of memory killer ने उसे बंद कर दिया है। ऐसी स्थिति में, किसी ट्यूनिंग फ्लैग के बजाय अधिक RAM वाला प्लान लेना ही एकमात्र समाधान है।

Forgejo और Gitea में क्या अंतर है?

इन दोनों का कोडबेस इतिहास और अधिकांश फीचर्स समान हैं। Gitea, 2016 में Gogs से अलग हुआ था, और Forgejo, 2022 के अंत में Gitea से अलग हुआ, जब Gitea ट्रेडमार्क का नियंत्रण एक कंपनी के पास चला गया। Forgejo को जर्मनी की एक गैर-लाभकारी संस्था Codeberg e.V. द्वारा GPLv3 लाइसेंस के तहत प्रकाशित किया जाता है; Gitea का लाइसेंस MIT है और इसे व्यावसायिक समर्थन प्राप्त है। व्यावहारिक अंतर माइग्रेशन प्रक्रिया में है। जनवरी 2025 का Forgejo v10.0, अंतिम ऐसा रिलीज़ था जो सीधे Gitea डेटाबेस को स्वीकार कर सकता था, और वह भी केवल Gitea v1.22 या उससे पुराने वर्शन से। इसलिए, वर्तमान Gitea इंस्टेंस से स्विच करने का कोई समर्थित इन-प्लेस तरीका नहीं है।

क्या मैं self-hosted Git सर्वर पर GitHub Actions workflows चला सकता हूँ?

Forgejo Actions और Gitea Actions दोनों ही GitHub Actions YAML सिंटैक्स में लिखे गए workflows को चलाते हैं, जिन्हें .forgejo/workflows और .gitea/workflows से पढ़ा जाता है। आपको एक अलग runner प्रोग्राम इंस्टॉल करना होगा और उसे अपने इंस्टेंस के साथ रजिस्टर करना होगा। कई प्रकाशित actions बिना किसी बदलाव के काम करते हैं, लेकिन जो GitHub API को कॉल करते हैं, वे काम नहीं करेंगे। runner आपके रिपॉजिटरी से मनमाना कोड निष्पादित करता है और प्रत्येक जॉब के लिए एक कंटेनर शुरू करता है, इसलिए इसे एक अलग होस्ट पर रखें, या कम से कम एक unprivileged user के साथ चलाएं। इसे 1 GB वाले उस सर्वर पर न रखें जो पहले से ही Git सर्वर चला रहा है।

मैं self-hosted Git सर्वर का बैकअप कैसे लूँ?

Bare repositories के लिए, किसी अन्य मशीन से git clone --mirror का उपयोग करके सभी refs और objects को कॉपी किया जा सकता है, और उस मिरर के अंदर git remote update चलाने से वह रिफ्रेश हो जाता है। Forgejo या Gitea के लिए, रिपॉजिटरी केवल स्थिति का एक हिस्सा हैं, क्योंकि issues, pull requests, users और keys डेटाबेस में रहते हैं। इसके लिए इन-बिल्ट डंप टूल sudo -u git forgejo dump -c /etc/forgejo/app.ini का उपयोग करें, या Docker इंस्टॉलेशन के लिए कंटेनर के अंदर यही कमांड चलाएं। इस आर्काइव को सर्वर से बाहर कॉपी करें, और एक बार किसी अतिरिक्त मशीन पर रिस्टोर करके देखें ताकि आप सुनिश्चित हो सकें कि प्रक्रिया सही ढंग से काम कर रही है।