Forgejo أم Gitea أم cgit: أي خادم Git تختار؟

ما خادم Git المستضاف ذاتياً الذي ينبغي تشغيله

خادم Git المستضاف ذاتياً ليس منتجاً واحداً، وتحدد ذاكرة الوصول العشوائي (RAM) في VPS الإصدار الذي يمكنك تشغيله. لا يحتاج Git إلى daemon خاص به؛ فالمستودع العاري مع حساب SSH (secure shell) يشكّلان خادماً عاملاً بالفعل على أصغر خادم يمكنك استئجاره. كل ما يتجاوز ذلك هو تطبيق ويب تختار تشغيله بجانبه، وكل مستوى إضافي يستهلك ذاكرة قد لا تتوفر في VPS صغير.

هناك أربعة مستويات. مستودع عارٍ عبر SSH، من دون أي خدمة تستمع إلى الاتصالات خلاف الخدمات التي كانت تستمع إليها مسبقاً. وcgit، وهو عرض ويب سريع للقراءة فقط ولا يحتاج إلى قاعدة بيانات. وForgejo أو Gitea، وهما forge متكامل يوفّر الحسابات والمشكلات وطلبات السحب ضمن بضع مئات من الميغابايتات. وGitLab، الذي يتطلب خادماً أكبر من الخوادم الأخرى بأضعاف كثيرة.

حدّد اختيارك وفق العمل الذي تحتاج إلى تنفيذه، ثم قارن مقدار الذاكرة بخطة VPS التي تدفع مقابلها.

مقدار RAM الذي يحتاجه كل خيار فعلياً

ينشر مشروعان فقط من هذه المشاريع رقماً متعلقاً بالعتاد. تعامل مع الرقم المنشور على أنه حد أدنى، وليس ضماناً، وقِس مثيلك بعد تشغيله باستخدام 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 أن 1 GB من RAM مع نواتي CPU تكون كافية عادةً للفرق والمشاريع الصغيرة، وتذكر أن Raspberry Pi 3 يكفي لأحمال العمل الصغيرة. وتذكر وثائق GitLab أن 16 GB هو الحد الأساسي لتثبيت على عقدة واحدة، وأن 8 GB هو الحد الأدنى للبيئة المقيّدة بالذاكرة وفقاً لتسمية صفحته. لا ينشر Forgejo أي متطلبات للعتاد. وهو fork من Gitea ويتصرف مثله، لذلك يُعد رقم Gitea أقرب إرشاد منشور متاح لك.

ما يعنيه ذلك على VPS بسعة 1 GB من RAM: تتوافق المستودعات العارية وcgit مع ترك مساحة متبقية، لأن أياً منهما لا يشغّل خدمة مقيمة. سيبدأ Forgejo أو Gitea، وسيخدم فريقاً صغيراً باستخدام SQLite، لكنك تعمل عند الحد الأدنى المذكور في الوثائق. لذلك اترك PostgreSQL وCI (التكامل المستمر) runner خارج ذلك الخادم. إذا اختفت واجهة الويب من دون ظهور خطأ، شغّل sudo dmesg -T | grep -i oom وابحث عن سطر مثل Out of memory: Killed process 1181 (forgejo)، فهذا يعني أن kernel out of memory killer أنهى العملية. تشغيل GitLab على خادم بسعة 1 GB ليس مشكلة ضبط إعدادات. لن يعمل.

المستوى 0: مستودع عارٍ عبر SSH

لا يوفّر Git خدمة شبكة تحتاج إلى بدء تشغيلها. يشغّل git push عبر SSH الأمر git-receive-pack في الطرف الآخر باعتباره عملية Unix عادية، لذلك فإن أي حساب يمكنك الوصول إليه باستخدام مفتاح هو بالفعل remote لـGit. أنشئ حساباً للمستودعات، واحتفظ بالمستودعات خارج دليله الرئيسي، لأن الدليل الرئيسي الجديد في Ubuntu 24.04 تكون صلاحياته 0750، ولا يمكن لواجهة ويب تُضاف لاحقاً القراءة داخله.

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 مستودعاً بلا نسخة عمل، وهذا هو النوع الذي يحتفظ به الخادم. يُرفض الدفع إلى مستودع يحتوي على نسخة عمل مع refusing to update checked out branch: refs/heads/main، وهذا هو الخطأ الأكثر شيوعاً في هذا المستوى.

امنح الحساب الآن مفتاحاً واستنسخ المستودع.

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

ينتهي أول دفع ناجح بالرسالة * [new branch] main -> main. أما الدفع الذي ينتهي بالرسالة git@vps.example.com: Permission denied (publickey) فلم تتم مصادقته مطلقاً، لذا اقرأ سجل الخادم باستخدام sudo journalctl -u ssh -n 20. وتعني السطر الذي يقرأ Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys أن نمط صلاحيات الملف غير صحيح، لأن sshd يتجاهل ملف مفتاح يمكن للمستخدمين الآخرين الكتابة فيه.

أزل الآن shell من الحساب.

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

لا يقبل git-shell إلا الأوامر القليلة التي يرسلها Git عبر SSH، لذلك يتوقف تسجيل الدخول التفاعلي الآن برسالة بدلاً من عرض مطالبة:

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

هذا هو الخادم بالكامل. لا توجد قاعدة بيانات ولا عملية ويب تحتاج إلى ترقية. وما تتخلى عنه هو كل ما يوفّره forge: لا تصفح، ولا متعقب للمشكلات، ولا pull requests، ولا صلاحيات لكل مستخدم. يمكن لكل مفتاح في ذلك الملف قراءة كل مستودع يملكه المستخدم git والكتابة فيه.

المستوى 1: يوفّر cgit عرضاً عبر الويب من دون قاعدة بيانات

cgit هو برنامج CGI (واجهة البوابة العامة) مكتوب بلغة C. يشغّله خادم الويب مرة واحدة لكل طلب، ويقرأ المستودعات مباشرة من القرص، ولا يخزّن أي حالة خاصة به. يتوفر في 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 وقراءة كل مستودع. يظهر المجلد الذي لا يستطيع دخوله كفهرس فارغ بدلاً من ظهور خطأ.

المستوى 2: Forgejo أو Gitea لإدارة المشكلات وطلبات الدمج

Forgejo وGitea مبنيان على الفكرة نفسها: ملف ثنائي واحد مكتوب بلغة Go يقدّم منصة استضافة برمجية عبر الويب، مع مستخدمين، ومؤسسات، ومشكلات، وطلبات دمج، وإصدارات، وسجل للحزم، ونظام CI مضمّن. يكفي الملف الثنائي مع SQLite لإكمال التثبيت، ولذلك يعملان على عتاد لا يستطيع GitLab استخدامه. ملف Compose أدناه هو الملف الوارد في وثائق Forgejo، مع وسم الصورة المذكور فيها حتى August 2026.

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 سطر حالة HTTP. قبل إكمال إعداد التشغيل الأول، قد يكون الناتج إعادة توجيه إلى /install، وهذا يعني أيضاً أن الخدمة تعمل. إذا خرجت الحاوية بدلاً من ذلك، فالسبب المعتاد هو الملكية: يجب أن يكون مجلد ./forgejo مملوكاً لمعرّف المستخدم UID في USER_UID، وإلا فلن تتمكن العملية من الكتابة إلى مجلد بياناتها. يشرح Docker Compose على VPS بنية الملفات هذه وقاعدة ملكية وحدات التخزين بالتفصيل.

تحدد إجابتان في صفحة الإعداد ما إذا كانت عناوين الاستنساخ ستعمل. يجب أن يكون منفذ SSH هو 222، لأن ملف Compose يربط منفذ المضيف 222 بالمنفذ 22 في الحاوية، ويجب أن يكون النطاق هو الاسم الذي سيكتبه المستخدمون فعلياً. إذا أخطأت في أي منهما، فستعرض كل صفحة مستودع أمراً للاستنساخ يفشل مع كل من ينسخه. يوجد كلا الإعدادين لاحقاً في قسم [server] من app.ini، بوصفهما SSH_PORT وSSH_DOMAIN وROOT_URL.

في النسخة العامة، انشر منفذ الويب على عنوان loopback فقط ('127.0.0.1:3000:3000')، وضع nginx أمامه لتوفير TLS (أمن طبقة النقل). يثبت Gitea بالطريقة نفسها من الصورة gitea/gitea، أو بوصفه ملفاً ثنائياً واحداً مع وحدة systemd واحدة وملف app.ini واحد، وإصداره المستقر الحالي هو 1.27.1 حتى August 2026.

استخدم SQLite ما دمت تستطيع. فهو يحصر النسخة في عملية واحدة وملف واحد، ويستمر في العمل بعد إعادة التشغيل من دون خدمة إضافية لمراقبتها. تصبح PostgreSQL مبررة عندما يكتب عدة أشخاص في الوقت نفسه، لأن SQLite تسلسل عمليات الكتابة، كما أن عمليات CI الطويلة تكتب باستمرار. يستطيع كلا المشروعين نقل نسخة موجودة إلى PostgreSQL لاحقاً، لذلك لن يكون هذا قراراً لا يمكنك التراجع عنه.

Forgejo أو Gitea: ما الفرق الفعلي بينهما

يشترك المشروعان في الأصل نفسه. تفرّع Gitea من Gogs في 2016. في أواخر 2022، انتقلت السيطرة على نطاق Gitea وعلامتها التجارية إلى شركة Gitea Ltd، وبدأ عدد من المطوّرين الأساسيين، بالتعاون مع Codeberg، مشروع Forgejo. تنشر Codeberg e.V. مشروع Forgejo، وهي جمعية غير ربحية مسجّلة في ألمانيا. وانتقل ترخيصه من MIT إلى GPLv3 (رخصة GNU العمومية الإصدار 3) في 2024. أما Gitea فما زال مرخّصاً بموجب MIT، ويُطوَّر بدعم تجاري.

في الاستخدام اليومي، مجموعتا الميزات متقاربتان. لكن مسار الانتقال بينهما ليس كذلك. كان Forgejo v10.0، الصادر في يناير 2025، آخر إصدار يمكنه استخدام قاعدة بيانات Gitea مباشرة، وكان ذلك يقتصر على Gitea v1.22 أو الإصدارات الأقدم. يعمل Gitea على الإصدار 1.27.1 اعتباراً من أغسطس 2026، لذلك لا توجد طريقة مدعومة لنقل نسخة Gitea الحالية إلى Forgejo في مكانها. اختر أحد المشروعين قبل إدخال البيانات إليه، واعتبر أي انتقال لاحق عملية تصدير ثم إعادة استيراد.

قاعدة مختصرة للاختيار: إذا كانت الحوكمة مهمة لك، أو أردت أن يبقى المشروع مع جهة غير ربحية، فاستخدم Forgejo. وإذا أردت قاعدة تثبيت أكبر وخيار دعم تجاري، فاستخدم Gitea. يُطوَّر كلا المشروعين بشفافية ويصدران تحديثات متكررة: يصدر Forgejo إصداراً مستقراً كل ثلاثة أشهر، وإصدار LTS (دعم طويل الأمد) كل عام. ويُعد v16.0.2 الإصدار الحالي، بينما يُعد v15.0.6 إصدار LTS اعتباراً من أغسطس 2026.

المستوى 3: تكلفة GitLab قبل أن ينفذ أي شيء

GitLab CE فئة مختلفة من البرمجيات. يتكوّن المثيل الواحد من مجموعة خدمات متعاونة: Puma لتطبيق الويب، وSidekiq للمهام في الخلفية، وPostgreSQL، وRedis، وGitaly للوصول إلى المستودعات، وnginx في الواجهة. تثبّت حزمة Omnibus هذه الخدمات معاً، ما يجعل التثبيت بسيطاً ويجعل الحد الأدنى لاستهلاك الذاكرة مرتفعاً.

تذكر صفحة متطلبات GitLab أن 16 GB من RAM و8 vCPU هما خط الأساس لتثبيت على عقدة واحدة، مع ذكر 8 GB كحد منخفض في البيئات المقيّدة بالذاكرة. وتطلب الصفحة نفسها تعطيل swap، لأن استخدام swap تحت الحمل يؤدي إلى تدهور أداء المثيل بشدة. هذه هي الأرقام المنشورة حتى August 2026، وقد ارتفعت على مر السنين، لذلك راجع الصفحة مجدداً قبل تحديد حجم الخادم.

تحصل مقابل هذه الموارد على مزايا فعلية: سجل للحاويات، وسجل للحزم، وصلاحيات دقيقة، وميزات للامتثال والتدقيق، وCI اختُبر على نطاق واسع. إذا لم يتمكن أي شخص في فريقك من تسمية ميزة من هذه القائمة يحتاج إليها هذا الربع، فأنت تدفع مقابل VPS أكبر من دون فائدة.

نموذج الوصول عبر SSH: مستخدم git واحد ومفاتيح متعددة

تعتمد كل الطبقات هنا طريقة المصادقة نفسها. يوجد حساب Unix واحد اسمه git، وتُضاف كل المفاتيح العامة إلى ملف ~/.ssh/authorized_keys الخاص بهذا الحساب. المفتاح هو وسيلة المصادقة. أما التفويض، فيتحدد بالخيارات التي تكتبها قبل المفتاح في السطر نفسه.

يمنح سطر المفتاح العادي حامله كل ما يستطيع هذا الحساب تنفيذه. ويضيّق الأمر الإجباري الصلاحيات لتقتصر على 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 هذا الملف نيابةً عنك، وهذا هو الفرق الفعلي بين tier 0 وtier 2. يعيد Forgejo وGitea كتابة authorized_keys بسطر لكل مفتاح مسجّل، ويحتوي كل سطر على أمر إجباري يحدد المفتاح بواسطة معرّف السجل في قاعدة البيانات:

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

يحوّل هذا الأمر الإجباري حساب Unix المشترك إلى صلاحيات منفصلة لكل مستخدم: يخبر key-3 الـForge بالمستخدم الذي يتصل، ثم يتحقق من هذا المستخدم مقابل المستودع قبل نقل أي كائنات. لا تعدّل هذا الملف يدوياً على خادم تديره منصة Forge، لأنه يُعاد إنشاؤه من قاعدة البيانات وسيختفي السطر الذي أضفته. وتستخدم مفاتيح النشر الآلية نفسها: مفتاح النشر هو مفتاح SSH عادي مسجّل لمستودع واحد، ويكون عادةً للقراءة فقط، مع إجراء التحقق في منصة Forge بدلاً من sshd.

هناك عادتان أهم من كل الإعدادات السابقة. أنشئ مفتاحاً واحداً لكل شخص أو جهاز، ولا تستخدم مفتاحاً مشتركاً، لأن إبطال مفتاح مشترك يعني تغييره للجميع في الوقت نفسه. واحذف المفاتيح في يوم مغادرة صاحبها، لأن وجود مفتاح قديم في هذا الملف يعني وجود تسجيل دخول دائم لا يراقبه أحد. يشرح إدارة مفاتيح SSH جيداً على خادم أنواع المفاتيح وعبارات المرور، وتنطبق كل هذه الإرشادات هنا دون تغيير. وإذا كان الخادم جديداً، فابدأ بـالدقائق العشر الأولى على VPS جديد قبل وضع المستودعات عليه.

هل يمكنني تشغيل GitHub Actions على خادم Git الخاص بي؟

يمكنك تشغيل سير العمل المكتوبة بصيغة GitHub Actions. لكن لا يمكنك تشغيل GitHub نفسه. تكون Forgejo Actions مفعّلةً افتراضياً منذ Forgejo v1.21، وتقرأ ملفات سير العمل من .forgejo/workflows في كل مستودع. تعمل Gitea Actions بالطريقة نفسها، وتقرأ .gitea/workflows. يحتاج كلاهما إلى برنامج ثانٍ، هو runner، يجب تثبيته وتسجيله في نسختك باستخدام رمز مميز من إعدادات المسؤول. تعمل كثير من الإجراءات المنشورة دون تعديل؛ لكن أي إجراء يستدعي GitHub API أو يتوقع بنية تحتية مستضافة لدى GitHub لن يعمل.

خطط لتبعات اثنتين. يبدأ runner حاوية لكل مهمة، لذلك يحتاج إلى محرك حاويات وميزانية ذاكرة خاصة به. ولهذا لا ينبغي وضعه على الخادم نفسه بسعة 1 GB الذي يستضيف forge. كما ينفّذ runner كل ما يحدده ملف سير العمل. وتذكر وثائق Forgejo ذلك بوضوح: ينفّذ runner التعليمات البرمجية عن بُعد. استخدم له خادماً مستقلاً حيثما أمكن، أو امنحه على الأقل مستخدماً غير مميّز خاصاً به ورمز تسجيل مميزاً محصوراً في مستودع واحد.

إذا بقيت مستودعاتك على GitHub، وكنت تريد فقط تشغيل المهام الحسابية على أجهزة تتحكم فيها، فهذا إعداد مختلف بخطوات مختلفة: يربط runner مستضاف ذاتياً لـ GitHub Actions بمستودع GitHub، ولا يحتاج إلى أي من ذلك. وإذا كنت لا تزال تقيّم تكلفة المغادرة، فإن ما الذي يقدمه GitHub فعلياً يفصل استضافة Git عن الشبكة المحيطة بها.

النسخ الاحتياطية: المستودعات لا تمثل سوى نصف الحالة

المستودع العاري عبارة عن دليل، لذا فإن نسخه ينسخ كل ما يحتوي عليه. وتُعد نسخة mirror من جهاز آخر نسخة احتياطية فعلية، كما أنها تحدّث النسخة في مكانها:

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 والمستخدمين والمفاتيح والأذونات في قاعدة بياناته، ونسخ المستودعات وحدها يؤدي إلى فقدان كل ذلك. يوفّر كلا المشروعين أمراً لإنشاء dump يكتب قاعدة البيانات والمستودعات والإعدادات والمرفقات في archive واحد:

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

في Docker، يُشغَّل الأمر نفسه داخل الحاوية، ويعتمد مسار الإعدادات على image، لذا تحقّق منه قبل أن تكتب الأمر:

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

شغّل الأمر باستخدام المستخدم الذي يملك البيانات، واكتب archive في دليل يمكن لذلك المستخدم الكتابة فيه. ثم انسخ archive خارج الخادم، لأن النسخة الاحتياطية الموجودة فقط على الجهاز الذي تجري حمايته ليست نسخة احتياطية. الاستعادة هي الخطوة التي يتجاوزها الناس: فكّ dump واحداً على جهاز احتياطي الآن، حتى تتعلم الإجراء في وقت هادئ بدلاً من تعلمه أثناء انقطاع الخدمة.

اختر وفق السيناريو

شخص واحد لديه حاسوب محمول وVPS، ولا يحتاج إلى التصفح: مستودعات bare عبر SSH. لا توجد خدمة إضافية قيد التشغيل، ولا شيء يحتاج إلى ترقية.

الوضع نفسه، مع الحاجة إلى قراءة الشفرة في متصفح وإرسال روابط إليها: أضف cgit. لا تزال بلا قاعدة بيانات، ولا توجد خدمة مقيمة قيد التشغيل.

فريق يراجع أعضاؤه شفرة بعضهم ويتابع المشكلات: Forgejo أو Gitea، مع 2 GB من ذاكرة RAM أو أكثر. انقل مشغّل CI إلى خادم ثانٍ عندما تصبح المهام فعلية.

مؤسسة تحتاج إلى سجل للحاويات ومسارات تدقيق، وتملك 16 GB لتخصيصها للخادم: GitLab. إذا كانت الميزانية أقل من ذلك، فلا تبدأ باستخدامه.

الانتقال إلى المستويات الثلاثة الأولى غير مكلف، لأن المستودعات في جميع هذه المستويات عبارة عن أدلة Git عادية على القرص. ابدأ بأدنى مستوى يحقق الغرض. إذا كنت تحدد الخدمات الأخرى التي تستحق مساحة على الخادم نفسه، فإن القائمة المختصرة بما يستحق الاستضافة الذاتية تضع خادم Git بجوار الخدمات الأخرى التي تتنافس على ذاكرة RAM نفسها.

FAQ

هل يمكن لخادم VPS بسعة 1 GB تشغيل Forgejo أو Gitea؟

نعم، لفريق صغير، باستخدام SQLite، بشرط ألا توجد خدمات أخرى ثقيلة على الخادم. تذكر وثائق Gitea أن 1 GB من الذاكرة و2 من أنوية CPU تكفي عادةً للفرق والمشاريع الصغيرة، وForgejo هو fork من Gitea وله المتطلبات العامة نفسها. لا تضف PostgreSQL أو مشغّل CI إلى ذلك الجهاز. إذا اختفت الخدمة من دون ظهور خطأ في سجلها، فنفّذ sudo dmesg -T | grep -i oom: يشير السطر الذي يذكر العملية التي أُنهِيت إلى أن kernel out of memory killer هو الذي أوقفها، والحل هو اختيار خطة أكبر وليس استخدام flag لضبط الإعدادات.

ما الفرق بين Forgejo وGitea؟

يشترك المشروعان في تاريخ قاعدة الشيفرة وفي معظم الميزات. تفرّع Gitea من Gogs في 2016، ثم تفرّع Forgejo من Gitea في أواخر 2022 بعد انتقال التحكم في العلامة التجارية Gitea إلى شركة. تنشر Codeberg e.V.، وهي مؤسسة غير ربحية في ألمانيا، Forgejo بموجب GPLv3؛ بينما يظل Gitea مرخّصاً بموجب MIT ومدعوماً تجارياً. الفرق العملي هو مسار الترحيل. كان Forgejo v10.0، الصادر في يناير 2025، آخر إصدار يمكنه استخدام قاعدة بيانات Gitea مباشرة، وكان ذلك يقتصر على Gitea v1.22 أو الأقدم، لذلك لا توجد طريقة مدعومة للتبديل داخل المكان نفسه من نسخة Gitea حالية.

هل يمكنني تشغيل مسارات عمل GitHub Actions على خادم Git مستضاف ذاتياً؟

يشغّل كل من Forgejo Actions وGitea Actions مسارات عمل مكتوبة بصيغة YAML الخاصة بـ GitHub Actions، وتُقرأ من .forgejo/workflows و.gitea/workflows. ثبّت برنامج runner منفصلاً وسجّله لدى نسختك. تعمل كثير من actions المنشورة من دون تعديل، لكن أي action تستدعي GitHub API لن تعمل. ينفّذ runner شيفرة عشوائية من مستودعاتك ويبدأ container لكل مهمة، لذلك خصّص له خادماً مستقلاً، أو مستخدماً غير مميّز خاصاً به على الأقل، وأبعده عن خادم بسعة 1 GB يشغّل forge بالفعل.

كيف أنشئ نسخة احتياطية لخادم Git مستضاف ذاتياً؟

بالنسبة إلى المستودعات العارية، ينسخ git clone --mirror من جهاز آخر كل ref وobject، ويحدّث git remote update داخل تلك النسخة المتطابقة. أما في Forgejo أو Gitea، فالمستودعات ليست سوى جزء من الحالة، لأن issues وpull requests والمستخدمين والمفاتيح موجودة في قاعدة البيانات. استخدم أداة التفريغ المضمّنة، sudo -u git forgejo dump -c /etc/forgejo/app.ini، أو نفّذ الأمر نفسه داخل container عند استخدام Docker. انسخ الأرشيف إلى خارج الخادم، واستعد نسخة منه على جهاز احتياطي مرة واحدة لتتأكد من أن الإجراء يعمل.