מה זה GitHub? ההבדל בין Git ל-GitHub לבעלי VPS

מה זה GitHub?

GitHub הוא שירות מאוחסן המאחסן מאגרי Git ובנה סביבם אתר אינטרנט. Git היא תוכנת בקרת גרסאות שרצה על המחשב האישי או על השרת שלכם. GitHub הוא מוצר של חברה אחת המבוסס על Git, ובבעלות Microsoft מאז 2018. ניתן להשתמש ב-Git מדי יום מבלי לפתוח את GitHub מעולם. לא ניתן להשתמש ב-GitHub ללא Git.

ההבחנה הזו הופכת לקריטית ברגע שאתם מחזיקים ב-VPS (שרת וירטואלי פרטי). Git הוא הכלי שמתעד את ההיסטוריה של קובצי התצורה ושל סקריפטי הפריסה שלכם. GitHub הוא המקום שבו נשמר עותק של היסטוריה זו כאשר השרת אינו זמין, וכן פלטפורמה להרצת תהליכי build וסקירות קוד. מדריך זה עוקב אחר דוגמה אחת, החל מתיקייה ריקה ועד לפריסה על שרת, ומגדיר כל מונח חדש במקום שבו הוא מופיע לראשונה.

מה Git עושה בעצמו

Git היא מערכת בקרת גרסאות: היא מתעדת את מצב הספרייה לאורך זמן, כך שניתן לראות מה השתנה, מתי ומדוע. היא נכתבה בשנת 2005 לצורך עבודה על הליבה של Linux. המערכת היא מבוזרת (distributed), מה שאומר שכל עותק של מאגר (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. כל גרסה מהשנים האחרונות מתנהגת באותו אופן עבור כל מה שמופיע להלן.

הדוגמה: מאגר (repository) עבור קובצי ה-deploy של ה-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 מגדיר את שם הענף הראשון כ-main. אם תשמיטו אותו, Git ידפיס רמז ארוך לגבי שם ענף ברירת המחדל. .gitignore מפרט נתיבים ש-Git לעולם לא צריך לעקוב אחריהם. רשמו את קובץ ה-secrets שלכם בתוכו כבר ביום הראשון, כיוון שקובץ שבוצע לו commit פעם אחת נשאר בהיסטוריה גם לאחר שתמחקו אותו, והסרה תקינה שלו משמעותה שכתוב של כל ה-commit שבאו אחריו.

Commits: יחידת ההיסטוריה

כעת נוסיף סקריפט ונתעד אותו.

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 מכיל תמונת מצב (snapshot) של כל קובץ במעקב, הודעה, מחבר, חותמת זמן, ומצביע ל-commit הקודם. הפקודה git log --oneline מדפיסה שורה אחת לכל commit, שמתחילה ב-hash קצר כגון a1b2c3d. ה-hash הזה הוא השם של ה-commit, וכמעט כל פקודת Git מקבלת אותו.

דלגו על שלב git add, והפקודה git commit תענה no changes added to commit (use "git add" and/or "git commit -a"). שום דבר לא נשבר. Git מודיעה לכם שה-staging area ריק, ולכן אין מה לצלם בתמונת מצב. git status היא הפקודה שיש להריץ בכל פעם שאתם הולכים לאיבוד: היא מציגה את ה-branch הנוכחי, את השינויים שנמצאים ב-staging, ואת הקבצים ש-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 תחזיר אותו.

Remotes: המקום שבו GitHub סוף סוף מופיע

עד כה הכל רץ על מכונה אחת ללא רשת כלל. Remote הוא כתובת URL בעלת שם המצביעה על עותק אחר של אותו מאגר (repository). GitHub מארחת עבורך אחד מהעותקים הללו. השם המקובל עבור ה-remote הראשי הוא 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 keys בחשבון ה-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 שולח את ה-commits שלך ל-remote. -u מתעד שה-main המקומי עוקב אחרי ה-main המרוחק, כך שבהמשך מספיק להריץ git push בלבד. git clone <url> הוא הפעולה ההפוכה במכונה חדשה: הוא מעתיק את כל המאגר יחד עם ההיסטוריה שלו ומגדיר עבורך את origin. גם remote מסוג HTTPS עובד, והוא עובר באותו פרוטוקול של כל דף אינטרנט, מה שעוזר ברשתות שחוסמות תעבורה יוצאת בפורט 22. אם משפט זה דורש הרחבה, ממה מורכבת בקשת HTTP בפועל מסביר את המכניקה.

Pull requests, issues ו-forks: המרכיבים של GitHub, לא של Git

כל מה שתואר לעיל הוא Git, והוא עובד מול כל שרת. שלושת המושגים להלן הם תכונות של GitHub. מארחים אחרים מעתיקים אותם, ו-Git עצמה אינה מכירה אותם כלל.

Pull request (או PR) הוא בקשה למזג ענף (branch) אחד לתוך אחר, עטופה בדף המיועד לדיון. אתם מבצעים push ל-add-backup, פותחים PR מול main, והאתר מציג את ההבדלים commit אחר commit. אנשים יכולים להוסיף הערות על שורות בודדות. בדיקות אוטומטיות מדווחות על הצלחה או כישלון מול הענף. לחיצה על merge גורמת ל-GitHub לבצע את המיזוג בעותק שלה, ולאחר מכן לעדכן את main. השם נגזר מתהליך העבודה המקורי, שבו הייתם מבקשים מהמתחזק לבצע pull לענף שלכם לתוך שלו.

Issue הוא שרשור ממוספר עבור באג או משימה. הוא קיים במסד הנתונים של GitHub, לא במאגר (repository) שלכם – נקודה שכדאי לדעת לפני שבוחרים מארח: אם תבצעו clone למאגר, תקבלו כל commit, אך לא אף issue. הוצאת ה-issues מהמערכת מחייבת קריאה ל-API.

Fork הוא עותק צד-שרת שלכם למאגר של מישהו אחר. יש לכם הרשאות כתיבה לעותק זה, אתם מבצעים push לענף אליו, ופותחים pull request מהעותק שלכם בחזרה לשלהם. כך תורמים לפרויקט שהמתחזקים שלו מעולם לא שמעו עליכם. Fork הוא clone שחי ב-GitHub וזוכר מהיכן הוא הגיע.

תוכנות קוראות את שלושת המרכיבים הללו דרך אותו API שבו משתמש אדם. סוכן בדיקת pull request שאתם מריצים על השרת שלכם עוקב אחר PRs חדשים, קורא את ה-diff, ומפרסם הערות על שורות. מוסכמות כגון קובץ AGENTS.md בשורש המאגר קיימות כיוון שמאגר כיום נקרא גם על ידי כלים ולא רק על ידי בני אדם.

מה GitHub עושה בפועל עבור בעל VPS

התחילו באחסון מחוץ לשרת. סקריפטי הפריסה (deploy scripts) וספרי ה-playbooks שלכם צריכים להימצא במקום שאינו השרת שהם מגדירים. בצעו בנייה מחדש של ה-VPS מ-image נקי, בצעו clone, והריצו. שמרו על המאגר (repository) הזה פרטי והעניקו לשרת 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 שוב.

בצעו clone כ-root ואז הריצו את Git כמשתמש אחר ותקבלו fatal: detected dubious ownership in repository at '/srv/vps-deploy'. Git מסרב לקרוא מאגר שבבעלות משתמש אחר, כיוון ש-.git/config עוין יכול לגרום ל-Git להריץ פקודות. תקנו את הבעלות עם chown במקום להוסיף חריגה מסוג safe.directory, כיוון שהחריגה משתיקה את הבדיקה מבלי להסיר את הגורם לבעיה.

GitHub Actions: צינורות (pipelines) לבנייה ופריסה

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 (שלב) הוא פקודה בודדת או פעולה מפורסמת. uses: מושך פעולה ממאגר אחר, ו-@v7 מקבע את הגרסה הראשית שלה (v7 היא הגרסה הנוכחית עבור actions/checkout נכון לאוגוסט 2026). תמיד קבעו גרסה, כיוון שפעולה ללא גרסה מקובעת משמעותה הרצת קוד שלא קראתם, בעל גישה ל-secrets שלכם.

runs-on: ubuntu-latest מבקש מ-GitHub מכונה וירטואלית חדשה, שנמחקת בסיום המשימה. הרצים (runners) הסטנדרטיים הם בחינם במאגרים ציבוריים, והתוכנית החינמית כוללת 2,000 דקות בחודש למאגרים פרטיים נכון לאוגוסט 2026. בדקו את דף התמחור העדכני לפני שאתם בונים תקציב על בסיס נתון זה.

ה-secrets נשמרים בהגדרות המאגר ונקראים כ-${{ secrets.DEPLOY_KEY }}. תהליך עבודה שמופעל על ידי pull request מ-fork מקבל אסימון (token) לקריאה בלבד ללא גישה ל-secrets אלו, כיוון שאחרת זר עלול לפתוח PR שהמשימה היחידה שלו היא להדפיס אותם.

הרצת ה-Actions runner על גבי VPS פרטי

runs-on: self-hosted שולח את המשימה למכונה שבבעלותך במקום זאת. דף הגדרות ה-runner במאגר מספק לך שורת הורדה, את כתובת ה-web של המאגר, ו-registration token שתקף לשעה אחת. הזן את שני האחרונים לתוך REPO_URL ו-RUNNER_TOKEN, ולאחר מכן ההגדרה מסתכמת בשלוש פקודות.

./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 כותב את ה-systemd unit, וזהו השלב שאנשים נוטים לדלג עליו: בלעדיו, ה-runner נסגר עם סיום ה-session של ה-SSH שלך, וכל משימה עתידית תישאר בתור ללא הסבר. הגדרה מלאה של self-hosted runner על גבי VPS מפרטת את תהליכי ה-hardening והניקוי ש-runner שפועל לאורך זמן זקוק להם.

התועלת היא שפריסה (deploy) כבר לא דורשת מפתח SSH נכנס שנגיש מהאינטרנט, כיוון שהמשימה כבר רצה על השרת עצמו. ה-build cache נשאר חם בין הרצות, ושום מונה דקות אינו רץ.

אזהרה אחת היא הכרחית. התיעוד הרשמי של GitHub ממליץ על שימוש ב-self-hosted runners עבור מאגרים פרטיים בלבד, כיוון ש-forks של מאגר ציבורי יכולים להריץ קוד מסוכן על ה-runner שלך באמצעות פתיחת pull request. ה-runner מבצע את כל מה שקובץ ה-workflow באותו branch מורה לו. במאגר פרטי שבו יש לך שליטה על מי מורשה לבצע push, הסיכון נמוך. במאגר ציבורי, התייחס לכל self-hosted runner כמכונה שזרים יכולים להריץ עליה קוד.

האם אתם זקוקים ל-GitHub בכלל?

לא. Git הוא התקן, ו-GitHub הוא שירות נוחות. Forgejo ו-Gitea הם פלטפורמות אירוח עצמי (forges), כאשר forge הוא שרת Git הכולל ניהול issues ו-pull requests. שניהם מופצים כקובץ binary יחיד של Go, שניהם רצים על VPS קטן, ו-Forgejo הוא fork משנת 2022 של Gitea שמפעיל כיום את 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 request. גם ה-CI לא עובר. ל-Forgejo יש מימוש Actions משלו שקורא קובצי YAML דומים מ-.forgejo/workflows/, והתיעוד שלו מבהיר את המגבלות, ומציין ש-GitHub Actions ו-Forgejo Actions אינם זהים וייתכן שדברים לא יעבדו מיד. הוא גם דורש runner משלו. תכננו את השלב הזה כהסבה (port), לא כהעתקה.

הסיבה הכנה לכך שרוב הפרויקטים נשארים היא התורמים. קוד ציבורי חייב לשבת במקום שבו לאנשים כבר יש חשבון. סקריפטי הפריסה הפרטיים שלכם לא חייבים. אלו שתי החלטות נפרדות, ומותר לכם לענות עליהן בצורה שונה.

מה נשבר ראשון, ומה אומרת השגיאה

דחיפה (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 האחרון שלכם, לעיתים קרובות עריכה שביצעתם בעורך האינטרנטי. הריצו את git pull --rebase כדי להחיל את ה-commits שלכם מחדש על גבי אלו הקיימים, ולאחר מכן בצעו push שוב. הימנעו מ-git push --force על ענף (branch) משותף, כיוון שהוא מסיר את ה-commits האחרים מאותו ענף בשרת.

fatal: refusing to merge unrelated histories. הרצתם git init מקומית וגם אפשרתם ל-GitHub ליצור את המאגר (repository) עם קובץ README. לשתי ההיסטוריות אין אף commit משותף, לכן Git לא ינסה לנחש. הפתרון הנקי הוא לשכפל (clone) את העותק מ-GitHub לתיקייה חדשה ולהעביר אליה את הקבצים שלכם.

error: src refspec main does not match any. הענף שציינתם לא קיים כאן. בדרך כלל למאגר אין עדיין אף commit, או שהענף שלכם נקרא master. הפקודה git branch --show-current תפתור זאת.

סוד (secret) הגיע ל-commit. בצעו החלפת פרטי גישה (rotate) באופן מיידי. התייחסו אליו כאל מידע ציבורי מרגע שנשלח, כיוון ש-forks, מראות (mirrors) ותצוגות במטמון מחזיקים עותקים שאין לכם דרך למחוק.

FAQ

האם GitHub זהה ל-Git?

לא. Git היא תוכנה לניהול גרסאות שמתקינים על המחשב, והיא פועלת ללא צורך ברשת או בחשבון. GitHub הוא שירות אירוח מסחרי המאחסן מאגרי Git ומוסיף סביבם ממשק אינטרנטי, ניהול משימות (issues), בקשות מיזוג (pull requests) וכלים ל-CI. התוכנה Git שוחררה ב-2005, ו-GitHub הושק ב-2008 על גביה. ניתן להשתמש ב-Git לנצח ללא GitHub. כל תכונה ב-GitHub נשענת על Git ברקע.

האם אני זקוק לחשבון GitHub כדי להשתמש ב-Git על ה-VPS שלי?

לא. git init, git commit ו-git log פועלים על שרת ללא הגדרת remote כלל, וזה מספיק כדי לעקוב אחר שינויים בקובצי /etc או כדי להריץ סקריפטים של פריסה. חשבון הופך לשימושי כאשר רוצים עותק של ההיסטוריה שישרוד גם אם השרת יקרוס, או כאשר יש מכונה נוספת שצריכה לבצע clone. פלטפורמות אירוח בניהול עצמי כמו Forgejo ו-Gitea מספקות מענה לאותו צורך על חומרה שבבעלותך, וגם חיבור SSH פשוט למאגר ריק (bare repository) בשרת אחר עובד ללא צורך בתוכנת ניהול מאגרים כלל.

מהי בקשת מיזוג (pull request)?

בקשת מיזוג היא בקשה למזג ענף (branch) אחד לתוך אחר, בצירוף דף לדיון. דוחפים (push) ענף, פותחים PR מול main, והמארח מציג את השינויים commit אחר commit כדי שבודקים יוכלו להגיב על שורות ספציפיות וכדי שבדיקות אוטומטיות יוכלו לדווח על הצלחה או כישלון. זו תכונה של GitHub ולא של Git, לכן ב-Git עצמו אין פקודה עבורה. מארחים אחרים מיישמים את אותו רעיון, לעיתים תחת השם merge request.

האם כדאי להריץ GitHub Actions runner על ה-VPS שלי?

עבור מאגר פרטי, לרוב כן. המשימה רצה על חומרה שאתה כבר משלם עליה, אין הגבלה על דקות שימוש, ה-cache של תהליך הבנייה נשאר זמין, ופריסה כבר לא דורשת חשיפת מפתח SSH לאינטרנט, כיוון שה-runner מתחבר ביוזמתו ל-GitHub ומבקש עבודה. עבור מאגר ציבורי, GitHub ממליצה להימנע מכך: כל אחד יכול לבצע fork למאגר שלך ולפתוח בקשת מיזוג שתוביל להרצת קוד על המכונה שלך.

האם אוכל להעביר את המאגרים שלי מ-GitHub בעתיד?

את הקוד, כן, בקלות. כל clone מחזיק את ההיסטוריה המלאה, לכן git remote set-url origin <new url> ולאחריו push יעבירו את כל מה שכל commit מכיל. מה שנשאר מאחור הוא השכבה ששייכת ל-GitHub: משימות (issues), דיוני pull request והיסטוריית Actions נמצאים במסד הנתונים שלהם, לא בתיקיית ה-.git שלך. כלי הגירה יכולים להעתיק משימות דרך ה-API, וקובצי ה-workflow בדרך כלל דורשים התאמה ל-CI של המארח החדש. מודעות לכך היא הטיעון המרכזי לכתיבת תיעוד מהותי בתוך המאגר עצמו ולא בשרשורי משימות.