מפת התמחור ותוכנית פעולה — Pricing Map & Action Plan

11.1 ארבע התוכניות — סקירה מלאה

GitHub מציעה ארבע תוכניות עיקריות. לפני שנצלול לפרטים, חשוב להבין את הלוגיקה: התוכנית קובעת אילו פיצ'רים זמינים, ו-צריכה מדודה (metered) מחויבת בנפרד מעבר ל-free tier שכלול בתוכנית. כלומר, גם בתוכנית Free אפשר לשלם על Actions minutes נוספים, וגם בתוכנית Enterprise יש free tier כלול.

Free — חינמי, ומפתיע בכמות

תוכנית Free היא הרבה יותר עשירה ממה שרוב האנשים חושבים. GitHub משקיעה בזה כדי למשוך מפתחים ולבנות אקוסיסטם. הנה מה שמקבלים:

• ריפוזיטורים ללא הגבלה — ציבוריים ופרטיים
• Actions: 2,000 דקות/חודש (Linux, ריפוזיטורים פרטיים). ציבוריים — ללא הגבלה
• Packages: 500MB אחסון, 1GB bandwidth/חודש
• Codespaces: 120 core-hours/חודש + 15GB אחסון
• GitHub Pages — אתר סטטי חינמי
• Projects (v2) — ניהול פרויקטים מלא
• Dependabot — התראות ועדכונים אוטומטיים
• Secret scanning — ב-public repos
• 3 collaborators ב-private repos

למה זה חשוב: הרבה מפתחים לא מודעים לעושר של Free. הם משדרגים ל-Pro או Team כי "שמעו שצריך" — ולמעשה משלמים על פיצ'רים שכבר יש להם. לפני שמשדרגים, חשוב למפות מה באמת משתמשים בו. זה בדיוק מה שנעשה ב-CAPSTONE.

עוד נקודה חשובה: ריפוזיטורים ציבוריים מקבלים יותר. Actions minutes ללא הגבלה, Packages storage ללא הגבלה, GHAS (CodeQL, secret scanning) בחינם — כל אלה ניתנים רק ל-public repos. אם הפרויקט שלכם יכול להיות ציבורי, זה משנה את חישוב העלות לחלוטין.

Pro — $4/חודש (אישי)

תוכנית Pro היא שדרוג לחשבון אישי בלבד (לא לארגון). מה מתווסף:

• Actions: 3,000 דקות/חודש (במקום 2,000)
• Packages: 2GB אחסון (במקום 500MB)
• Codespaces: 180 core-hours/חודש (במקום 120)
• Required reviewers — על protected branches
• Wiki ו-Pages גם ב-private repos
• Insights מתקדמים — graphs מפורטים על traffic ו-clones
• אין הגבלת collaborators ב-private repos

השורה התחתונה: $4/חודש בשביל collaborators ללא הגבלה ועוד אלף דקות Actions. אם אתם עובדים עם יותר מ-3 אנשים על private repos — זה שווה.

מי צריך Pro? פרילנסרים שעובדים עם לקוחות על private repos, מפתחים עצמאיים עם צוות קטן, ואנשים שצריכים required reviewers ב-protected branches. אם אתם עובדים לבד על public repos — Pro לא מוסיף כלום משמעותי.

Team — $4/user/חודש (ארגון)

תוכנית Team היא לארגונים. כל הפיצ'רים של Pro, ועוד:

• Actions: 3,000 דקות/חודש (לארגון)
• Packages: 2GB אחסון
• Draft Pull Requests
• CODEOWNERS enforcement — חובת review לפי בעלי קוד
• Required status checks — CI חייב לעבור לפני merge
• Branch protection rules מתקדמות
• Repository rulesets
• צוותות (Teams) עם הרשאות מפורטות

מתי Team ולא Pro? הקו המפריד ברור: אם אתם צריכים ארגון (Organization) עם צוותות, הרשאות מפורטות, ו-CODEOWNERS enforcement — Team. אם אתם חשבון אישי — Pro. שימו לב שלא ניתן לשדרג חשבון אישי ל-Team — צריך ליצור Organization ולשלם לפי מספר users.

חישוב מהיר: צוות של 10 אנשים ב-Team = $40/חודש ($480/שנה). זה פחות מעלות שעה של DevOps consultant. הערך ב-CODEOWNERS enforcement, rulesets, ו-Teams עם הרשאות — שווה הרבה יותר מזה.

Enterprise — $21/user/חודש

תוכנית Enterprise מוסיפה את שכבת הארגון הגדול:

• Actions: 50,000 דקות/חודש
• Packages: 50GB אחסון
• GHAS כלול — CodeQL, secret scanning מתקדם, dependency review ב-private repos
• SAML SSO — אימות ארגוני
• Audit log API — לוג ביקורת עם גישה תכנותית
• Custom roles — תפקידים מותאמים
• Enterprise Managed Users (EMU)
• IP allow lists
• Premium support
• Internal repositories — גלויים רק בתוך הארגון

GitHub One — החבילה שכוללת הכל

GitHub One הוא bundle שמאגד: Enterprise + GHAS + Copilot Enterprise + Premium Support. המחיר הוא לפי משא ומתן (לרוב סביב $40-50/user/חודש — תלוי בגודל הארגון ובתקופת ההתקשרות). GitHub One לא מופיע בדף pricing הרגיל — צריך לפנות למכירות.

מתי שווה? אם הארגון שלכם כבר משלם על Enterprise + GHAS + Copilot Business בנפרד, חשבו את הסכום ובדקו אם GitHub One יוצא זול יותר. לרוב, מעל 100 users, ה-bundle חוסך. להשוואה: Enterprise ($21) + GHAS ($49) + Copilot Business ($19) = $89/user/חודש. GitHub One בסביבות $45-50/user/חודש — חיסכון של כמעט 50%.

חשוב: GHAS (GitHub Advanced Security) הוא המוצר הכי יקר ב-GitHub — $49/user/חודש בנפרד. זו הסיבה שהרבה ארגונים מדלגים עליו. אבל ב-Enterprise הוא כלול, וב-GitHub One הוא חלק מה-bundle. אם GHAS הוא הסיבה שאתם שוקלים Enterprise — ודאו שהחישוב נכון: Enterprise ($21) כבר כולל GHAS, אין צורך לשלם $49 נוסף.

השוואה מספרית — עלות שנתית

בואו נשים מספרים על השולחן. צוות של 20 מפתחים:

ההפרש בין Free ל-Team הוא $960/שנה — שווה ערך ל-2 שעות של DevOps consultant. ההפרש בין Team ל-Enterprise הוא $4,080/שנה — וזה צריך להיות מוצדק בצורך ספציפי.

11.2 Free Tier — הזהב הנסתר

הנקודה הכי חשובה בכל מפת התמחור של GitHub: ה-Free Tier עשיר במיוחד. GitHub בכוונה נותנת הרבה בחינם כדי שתתרגלו לפלטפורמה. בואו נמפה בדיוק מה מקבלים:

פיצ'רים שחינמיים לחלוטין (ללא הגבלה)

פיצ'רים חינמיים עם מגבלת כמות

הפיצ'רים החינמיים שהכי מתעלמים מהם

מניסיון, רוב המפתחים ב-Free Tier לא מנצלים את הפיצ'רים הבאים — למרות שהם חינמיים לחלוטין:

1. Dependabot version updates — רוב האנשים מכירים את ה-security alerts, אבל לא יודעים ש-Dependabot גם מעדכן dependencies באופן שוטף. קובץ dependabot.yml אחד — ו-PRs אוטומטיים עם עדכונים שבועיים. ראינו את זה בפרק 7.
2. GitHub Projects (v2) — ניהול פרויקטים ברמת Jira-lite, עם board, table, roadmap, custom fields, ואוטומציות. לגמרי חינמי. רוב אנשים עדיין משתמשים ב-Trello או Notion בנפרד.
3. GitHub Pages — אתר סטטי חינמי עם HTTPS ודומיין מותאם. מושלם ל-portfolio, דוקומנטציה, blog. רוב המפתחים משלמים על Vercel או Netlify כשהם לא צריכים server-side rendering.
4. GitHub Actions על public repos — דקות ללא הגבלה. אם הפרויקט יכול להיות ציבורי — CI/CD חינמי לגמרי, ללא הגבלה, עם כל ה-marketplace.
5. Discussions — פורום מובנה בתוך הריפו. מחליף Slack channel או Discord server עבור שאלות קהילה. חינמי.

חישוב ערך: אם הייתם משלמים על Trello ($10/user), Vercel ($20/חודש), Dependabot-like service ($20/חודש), ו-CI/CD service ($30/חודש) — זה $80+/חודש שפשוט חינמי ב-GitHub. הערך הנסתר ב-Free Tier הוא מאות דולרים בשנה לכל מפתח.

11.3 מוצרים מדודים — Actions, Codespaces, Packages, LFS

ארבעת המוצרים המדודים הם המקום שבו החשבון עלול להפתיע. בכולם יש free tier, אבל אם חורגים — החיוב מתחיל. בואו נפרק כל אחד:

Actions Minutes — החיוב המפורט

כשאתם מריצים workflow על ריפוזיטורי פרטי, כל דקת ריצה נספרת. אבל לא כל דקה שווה — יש מכפיל (multiplier) לפי מערכת הפעלה:

דוגמה מספרית: יש לכם workflow שרץ 5 דקות על כל push. אם יש 20 pushes בשבוע:

• Linux: 5 x 20 x 4 = 400 דקות/חודש. מתוך 2,000 free — בסדר גמור.
• macOS: 5 x 10 (מכפיל) x 20 x 4 = 4,000 דקות/חודש. כבר חרגתם מ-free tier ב-2,000 דקות. עלות נוספת: 2,000 x $0.008 = $16/חודש.

מה נחשב "דקה"? GitHub מעגלת כל job למעלה לדקה השלמה הקרובה. כלומר, job שרץ 12 שניות נחשב כ-1 דקה. job שרץ 61 שניות — 2 דקות. זה אומר שלפעמים שווה לאחד steps לתוך job אחד במקום לפצל — כל job נפרד "מפסיד" עיגול.

מה לא נספר? זמן שהמכונה מחכה בתור (queue time) לא נספר — רק זמן ריצה בפועל. גם setup של ה-runner (pull של image, התקנת environment) נספר, אבל בדרך כלל זה 10-15 שניות.

Free Tier לפי תוכנית — Actions

Codespaces — Core-Hours וחיוב

Codespaces (שלמדנו בפרק 4) הוא אחד מהמוצרים המדודים שהכי קל "לשכוח" — כי ה-billing עובד גם כשאתם לא עובדים. להבדיל מ-Actions (ששורף דקות רק בזמן ריצת workflow), Codespace פתוח צורך core-hours ואחסון כל רגע שהוא דלוק — גם אם אתם בארוחת צהריים.

Codespaces מחויב בשני ממדים: זמן חישוב (core-hours) ו-אחסון.

דוגמה מספרית: Free tier = 120 core-hours/חודש. אם אתם עובדים על מכונה עם 4 cores:

• 120 / 4 = 30 שעות עבודה בחודש
• זה כשעה ביום ב-30 ימי עבודה — צפוף, אבל אפשרי
• אם תרדו ל-2-core: 120 / 2 = 60 שעות — הרבה יותר נוח

אחסון: 15GB כלול ב-free tier. כל GB נוסף = $0.07 ליום. Codespace שנשאר idle עדיין צורך אחסון!

Prebuilds — עלות נסתרת: אם הגדרתם prebuilds (פרק 4), הם צורכים storage גם הם. Prebuild image יכול להיות 5-15GB. אם יש לכם 3 prebuilds = 15-45GB storage. מעבר ל-free tier, זה $1-3/יום. כדאי לוודא שיש prebuilds רק לריפוזיטורים שבאמת צריכים.

טריק חשוב: שימו לב שאחסון Codespaces נמדד ליום (לא לחודש). אם יש לכם Codespace שתפס 10GB ל-20 ימים = 200 GB-days. אם זה מעבר ל-free tier, החיוב הוא 200 x $0.07 = $14. מחיקה של Codespace שלא צריכים — חוסכת כסף מיידי.

Packages — Storage ו-Bandwidth

חשוב לזכור: packages ב-public repos הם חינמיים לחלוטין — storage ו-bandwidth. החיוב הוא רק על private packages.

דוגמה מספרית: צוות שמפרסם Docker images פרטיים. ממוצע של 500MB per image, גרסה חדשה כל יום = 15GB/חודש storage. ב-Free (500MB כלול) — חריגה של 14.5GB x $0.25 = $3.63/חודש. ב-Team (2GB כלול) — חריגה של 13GB x $0.25 = $3.25/חודש. ההפרש זניח — מה שחשוב הוא לנקות versions ישנים. אם תשאירו retention policy שמחזיק רק 10 versions = ~5GB, החיוב יורד משמעותית.

Container Registry (ghcr.io) vs npm registry: שניהם חלק מ-Packages, אבל Docker images בדרך כלל גדולים הרבה יותר (מאות MB) לעומת npm packages (KB-MB). אם אתם משתמשים ב-Docker — storage הוא הסיכון העיקרי. אם npm — bandwidth לרוב לא יהיה בעיה.

Git LFS — Large File Storage

LFS (Large File Storage) מנהל קבצים גדולים ב-Git — תמונות, מודלים, מסדי נתונים, assets של משחקים. Free tier כולל 1GB storage + 1GB bandwidth. מעבר לזה — $5 ל-50GB data pack (כולל storage + bandwidth).

מתי צריכים LFS? אם הריפו מכיל קבצים מעל 50MB, Git מתחיל להתנהג לאט — clone ארוך, diff בעייתי, history תופס מקום. LFS מחזיק רק pointers בריפו, והקבצים עצמם באחסון חיצוני של GitHub.

טיפ: אם אתם צריכים לאחסן קבצים גדולים ולא רוצים לשלם LFS, שקלו להשתמש ב-Git LFS רק ל-tracking ואת הקבצים עצמם לאחסן ב-S3/R2/GCS עם קישור ב-README. אפשרות נוספת: GitHub Releases מאפשרים לצרף assets עד 2GB per file — בחינם.

חישוב מהיר: data pack של $5 נותן 50GB. אם יש לכם 5GB של assets — data pack אחד מספיק לעשרה חודשים (בהנחה שה-bandwidth לא חורג). אם הצוות מושך את הריפו 50 פעם ביום ו-LFS objects = 2GB, ה-bandwidth החודשי הוא 50 x 2GB x 20 = 2TB — הרבה מעבר ל-free tier. במקרה כזה, cache את ה-LFS objects ב-CI כדי לצמצם pulls.

11.4 Copilot כתוספת — מה כלול ומה עולה

GitHub Copilot הוא מוצר נפרד מהתוכניות — הוא לא כלול באף תוכנית (כולל Enterprise) אלא אם רכשתם אותו בנפרד או כחלק מ-GitHub One. הנה המפה:

הנקודה החשובה: אם אתם סטודנטים, מורים, או maintainers של פרויקט open-source פופולרי — אתם זכאים ל-Copilot Pro בחינם. בדקו ב-Settings → Copilot.

Copilot Free vs Pro — שווה לשדרג? Copilot Free נותן 2,000 completions ו-50 chat messages בחודש. לרוב המפתחים שמשתמשים באופן קבוע, זה נגמר תוך שבוע-שבועיים. Pro ($10/חודש) נותן ללא הגבלה. אם אתם משתמשים ב-Copilot יומיומית — Pro שווה. אם אתם משתמשים מדי פעם — Free מספיק.

Copilot Business vs Pro: Business עולה $19/user/חודש אבל מוסיף: IP indemnity (הגנה משפטית), organization-wide policy control (אפשר לכבות Copilot על repos מסוימים), ו-no data retention (GitHub לא שומר את הקוד שלכם ל-training). אם אתם ארגון עם IP רגיש — Business חובה. אם אתם מפתח עצמאי — Pro מספיק.

11.5 מפת עלויות פיצ'ר-אחר-פיצ'ר

הטבלה הזו היא המפה המרכזית של הפרק. שמרו אותה — היא תהיה הבסיס לתרגיל ה-CAPSTONE. כל פיצ'ר שלמדנו ב-10 פרקים, עם הסימון: חינמי, חינמי עם מגבלה, או בתשלום.

* Enterprise Codespaces: free tier תלוי בהסכם. לרוב כלול ללא הגבלה או עם תקציב מוגדר מראש.

מה שהכי מפתיע בטבלה הזו

אחרי שסקרנו כל פיצ'ר, הנה 5 הפתעות שרוב המפתחים לא מודעים אליהן:

1. Projects (v2) חינמי לגמרי. ניהול פרויקטים מלא — board, table, roadmap, custom fields, automation — בכל התוכניות. אין סיבה לשלם על Jira או Trello אם אתם כבר ב-GitHub.
2. Secret scanning חינמי ב-public repos. הרבה אנשים חושבים שצריך Enterprise בשביל secret scanning. לא — ב-public repos זה חינמי. מה שדורש Enterprise (GHAS) הוא secret scanning ב-private repos ו-push protection.
3. Larger runners (מכונות חזקות) דורשים Team. אם אתם צריכים runner עם 8+ cores — לא מספיק Free. צריך Team לפחות. Self-hosted runners, לעומת זאת, עובדים בכל התוכניות.
4. Draft PRs דורשים Team. פיצ'ר שנראה בסיסי, אבל Free לא תומך ב-Draft PRs. Pro מאפשר רק לחשבונות אישיים. אם הארגון שלכם צריך Draft PRs — Team חובה.
5. API rate limits זהים ב-Free, Pro, Team. כולם מקבלים 5,000 requests/שעה עם PAT. רק Enterprise מעלה ל-15,000. אם אתם בונים אוטומציות כבדות — שקלו GitHub App (15,000/שעה) במקום PAT.

11.6 איך למקסם את ה-Free Tier — אסטרטגיות מעשיות

בואו נעבור על 10 אסטרטגיות שחוסכות כסף אמיתי. כל אחת מבוססת על מה שלמדנו בפרקים הקודמים:

1. העדיפו public repos כשאפשר

Public repos מקבלים Actions minutes ללא הגבלה, Packages חינם, ו-GHAS חינם (CodeQL, secret scanning). אם הפרויקט שלכם לא מכיל IP רגיש — עשו אותו public. זה לבד יכול לחסוך את כל עלות ה-Actions. שאלה טובה לשאול: "מה הנזק אם מישהו רואה את הקוד הזה?" אם התשובה היא "כלום" — public.

מתי לא לעשות public: קוד עם לוגיקה עסקית ייחודית, קוד עם credentials מוטמעים (שלא צריכים להיות שם, אבל קשה להסיר), קוד שמכסה פטנט, או קוד של לקוח שדורש פרטיות. כל השאר — כנראה יכול להיות public.

2. השתמשו ב-Linux runners תמיד

כפי שראינו, macOS x10 ו-Windows x2. בדקו כל workflow — אם אין צורך ספציפי ב-macOS (iOS build, Xcode compilation) או Windows (.NET Framework, PowerShell testing) — שנו ל-ubuntu-latest. זה הצעד הכי פשוט עם ה-ROI הכי גבוה.

3. Cache הכל

כל דקה שחוסכים ב-caching היא דקה שלא נספרת. הגדירו cache ל-dependencies (npm, pip, Maven). ראינו בפרק 1 שזה חוסך 60-80% מזמן ההתקנה. הנה ההגדרה הכי פשוטה:

# ב-setup-node — שורה אחת מספיקה:
- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'npm'

# ב-setup-python:
- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'

בלי cache: npm ci לוקח 40-60 שניות. עם cache: 3-5 שניות. על 100 ריצות בחודש זה 50-90 דקות חסכון — משמעותי כשיש 2,000 דקות free.

4. הגדירו concurrency groups

אם דוחפים 3 commits ברצף — בלי concurrency group, 3 workflows רצים במקביל ושורפים דקות. עם cancel-in-progress: true — רק האחרון רץ. שלוש שורות שחוסכות עשרות אחוזים:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

5. השתמשו ב-path filters

שינוי ב-README לא צריך להריץ CI מלא. הוסיפו paths-ignore ל-workflow:

on:
  push:
    branches: [main]
    paths-ignore:
      - '**.md'
      - 'docs/**'
      - '.github/ISSUE_TEMPLATE/**'

זה מונע ריצות מיותרות על שינויים בתיעוד. אם 30% מה-pushes שלכם הם עדכוני docs — זה חיסכון של 30% בדקות.

6. הגדירו timeout קצר

ברירת המחדל ל-job timeout היא 6 שעות (360 דקות). אם ה-workflow שלכם אמור לרוץ 5 דקות — הגדירו timeout-minutes: 15. ככה אם משהו נתקע (infinite loop, network timeout), הוא לא שורף 360 דקות. ההבדל בין 15 דקות timeout ל-360 = חיסכון של 345 דקות על כל תקלה.

7. Codespaces — בחרו machine type קטן

התחילו תמיד עם 2-core. זה 60 שעות/חודש ב-free tier במקום 30 שעות על 4-core. שדרגו רק אם באמת צריך — build כבד, Docker-in-Docker, מודלים גדולים. רוב הקוד (JavaScript, Python, web apps) לא דורש 8 cores. אם אתם כותבים קוד ולא מריצים builds כבדים, 2-core מספיק.

8. Codespaces — הגדירו idle timeout

ברירת המחדל היא 30 דקות idle timeout. הורידו ל-5-10 דקות. כל דקת idle שורפת core-hours. לכו ל-Settings → Codespaces → Default idle timeout. החישוב: 30 דקות idle ביום x 22 ימי עבודה x 4 cores = 44 core-hours/חודש מבוזבזים. עם 5 דקות idle — זה יורד ל-7 core-hours. חיסכון של 37 core-hours — כמעט שליש מה-free tier.

9. Packages — נקו versions ישנים

כל version שפרסמתם צורך storage. הגדירו retention policy שמוחקת versions ישנים. אפשר עם Actions workflow שרץ פעם בשבוע ומנקה versions מעבר ל-10 האחרונים. דוגמה:

- uses: actions/delete-package-versions@v5
  with:
    package-name: my-package
    min-versions-to-keep: 10
    delete-only-pre-release-versions: true

Docker images הם הכי "כבדים" — image של 500MB x 30 versions = 15GB. ניקוי ל-10 versions = 5GB. חיסכון: (15-5) x $0.25 = $2.50/חודש.

10. נצלו את Dependabot בלי לשלם על GHAS

Dependabot (alerts + security updates + version updates) הוא חינמי בכל התוכניות. לא צריך GHAS בשביל זה. הרבה אנשים חושבים שצריך Enterprise בשביל Dependabot — לא נכון.

דוגמאות מייצגות: חיסכון בפועל

דוגמה א — מפתח עצמאי: לפני אופטימיזציה: 5 workflows, 3 עם macOS runner (בלי צורך), ללא caching, ללא concurrency. צריכה: 3,200 דקות/חודש. חריגה: 1,200 דקות x $0.008 = $9.60/חודש. אחרי אופטימיזציה: שינוי ל-Linux, caching, concurrency groups. צריכה: 450 דקות/חודש. חיסכון: $115/שנה.

דוגמה ב — סטארטאפ (5 מפתחים): לפני: Codespaces על 8-core, idle timeout 30 דקות, 3 Codespaces ישנים פתוחים. צריכה: 640 core-hours + 45GB storage. חריגה: 460 core-hours x $0.18 + 30GB x $0.07 x 30 = $82.80 + $63 = $145.80/חודש. אחרי: 4-core, idle timeout 5 דקות, מחיקת ישנים. צריכה: 180 core-hours + 15GB. חיסכון: $1,750/שנה.

דוגמה ג — פרויקט open-source: לפני: private repo עם 2,000 דקות Actions ו-500MB Packages. אחרי: שינוי ל-public repo. Actions: ללא הגבלה (חינמי). Packages: ללא הגבלה (חינמי). Security: CodeQL חינמי. חיסכון: 100% של ה-metered billing.

11.7 מתי לשדרג — מסגרות החלטה

שדרוג תוכנית הוא לא "כש-Free לא מספיק" — זה "כשיש צורך ספציפי ש-Free לא פותר". בואו נפרק את ההחלטה:

תהליך ההחלטה בפועל — שלב אחרי שלב

בואו נעבור את התהליך שמפתח צריך לעשות לפני שמחליט לשדרג:

1. רשמו מה חסר לכם. לא "אולי אצטרך" — אלא מה אתם לא יכולים לעשות עכשיו. אם הכל עובד — אין סיבה לשדרג.
2. בדקו אם יש workaround חינמי. צריכים יותר Actions minutes? אולי caching וconcurrency groups יספיקו. צריכים CODEOWNERS? אולי branch protection בסיסי מספיק.
3. חשבו ROI. אם שדרוג ל-Team עולה $480/שנה ל-10 users, מה אתם מקבלים? CODEOWNERS enforcement שמונע bugs ב-production שווה $480/שנה? כנראה שכן, אם הבאגים עולים לכם יותר מזה.
4. נסו לפני שמתחייבים. GitHub מציעה trial periods לרוב התוכניות. נסו 14 יום של Team לפני שמתחייבים לשנה.
5. סקרו כל רבעון. צרכים משתנים. אולי שדרגתם ל-Team כי הייתם 10 אנשים, ועכשיו אתם 4. אולי כדאי לרדת.

11.8 Spending Limits ובקרת הוצאות

גם אם בחרתם את התוכנית הנכונה, חשוב לשלוט בהוצאות המדודות. בלי שליטה, חשבון Actions או Codespaces יכול להפתיע בסוף החודש.

מה זה Spending Limit?

כל מוצר מדוד (Actions, Codespaces, Packages) מאפשר להגדיר תקרת הוצאות חודשית:

• $0 (ברירת מחדל): אחרי שנגמר ה-free tier, השירות נחסם. לא מחויבים. זו ההגדרה הבטוחה ביותר.
• סכום ספציפי ($10, $50, וכו'): השירות ממשיך מעבר ל-free tier עד שמגיעים לתקרה, ואז נחסם.
• Unlimited: אין תקרה. השירות ממשיך ואתם משלמים על כל שימוש. מסוכן לפרויקטים אישיים.

איך להגדיר Spending Limit

הנתיב: Settings → Billing → Spending limits. שם תראו שלושה שדות — Actions, Packages, Codespaces. לכל אחד הגדירו סכום.

המלצה:

• Actions: $10 — מכסה 1,250 דקות Linux נוספות. מספיק לרוב הפרויקטים.
• Codespaces: $0 — אם נגמר free tier, פשוט מחקו Codespaces ישנים או עברו ל-machine type קטן.
• Packages: $0 — אם אתם מתקרבים למגבלה, נקו versions ישנים.

תרחישי Spending Limit — מה קורה בפועל

בואו נראה מה קורה ב-3 תרחישים:

המלצה לצוותות: הגדירו spending limit שמכסה חודש "שמן" — לרוב x1.5 מהצריכה הממוצעת. אם ממוצע Actions = $15/חודש, הגדירו $25. ככה יש מרווח, אבל לא "חור שחור" תקציבי.

ניטור שוטף — Cost Center ו-Alerts

ב-Team ו-Enterprise אפשר להגדיר:

• Budget alerts: הודעה כש-75% מה-spending limit נוצלו
• Cost centers (Enterprise): הקצאת עלויות לצוותות — מי אחראי על איזה חיוב
• Usage reports: CSV מפורט של כל השימוש

שימוש ב-gh cli לניטור: אפשר לבדוק billing מהטרמינל (פרק 2):

# צפייה בצריכת Actions minutes
gh api /orgs/{org}/settings/billing/actions

# צפייה בצריכת Packages
gh api /orgs/{org}/settings/billing/packages

# צפייה בצריכת Shared Storage
gh api /orgs/{org}/settings/billing/shared-storage

אפשר לבנות Actions workflow שרץ פעם ביום, בודק את ה-billing, ושולח Slack alert אם הצריכה חורגת מסף מסוים. אוטומציה שחוסכת כסף.

11.9 תוכנית פעולה ל-90 יום

עכשיו שיש לכם את כל המידע, הגיע הזמן להפוך אותו לתוכנית פעולה. ה-90 יום מחולקים ל-3 שלבים. כל שלב בונה על הקודם, וכל שבוע יש פעולה מוגדרת ותוצר מדיד.

למה 90 יום? מחקרים מראים שלוקח 66 ימים בממוצע ליצור הרגל חדש. 90 יום נותנים לכם מספיק זמן לא רק ללמוד, אלא להטמיע — לעשות את הדברים כחלק משגרת העבודה, לא כ"משהו שלמדתי פעם".

שלב 1: ימים 1-30 — Audit & Optimize

המטרה של החודש הראשון: להבין מה יש לכם ולייעל.

שלב 2: ימים 31-60 — Build & Automate

המטרה: להפעיל את כל הפיצ'רים החינמיים.

שלב 3: ימים 61-90 — Scale & Decide

המטרה: החלטה מבוססת נתונים — האם לשדרג, מה לשדרג, ומה התוכנית הבאה.

מדדי הצלחה — איך יודעים שזה עובד?

בסוף כל שלב, בדקו את המדדים הבאים:

טיפים להטמעה מוצלחת

• אל תנסו הכל ביום אחד. הסיבה שהתוכנית מפורסת על 90 יום היא שהטמעה צריכה זמן. עשו דבר אחד בשבוע — לא חמישה.
• הגדירו reminder שבועי. שימו ביומן (Google Calendar, Apple Calendar) התראה שבועית: "סקירת GitHub שבועית — 15 דקות". בדקו billing, Dependabot alerts, ו-CI status.
• שתפו עם הצוות. אם אתם עובדים בצוות, שתפו את מפת השימוש ואת התוכנית. ככה כולם מיושרים על אותם הכלים ואותן ההחלטות.
• תעדכנו כל חודש. מפת השימוש היא מסמך חי — לא "שיעורי בית" שמגישים ושוכחים. בסוף כל חודש, עדכנו את העמודה "סטטוס" ואת "פעולה".
• אל תשדרגו בלחץ. אם משהו מפסיק לעבוד כי נגמר free tier — לפני שמשדרגים, בדקו אם אפשר לייעל. ב-95% מהמקרים, אופטימיזציה חוסכת את השדרוג.

11.10 CAPSTONE — מפת השימוש האישית

זה התרגיל הסופי של הקורס. מפת השימוש האישית היא המסמך שמחבר את כל מה שלמדתם ל-action plan אישי. זה לא תרגיל תיאורטי — זה מסמך שתשתמשו בו אחרי הקורס.

| פיצ'ר | פרק | חינמי? | מגבלת Free Tier | האם אני צריך? | סטטוס | פעולה |
|--------|------|--------|-----------------|---------------|--------|--------|

# Actions
pushes/שבוע x דקות/workflow x מכפיל OS x 4 = דקות/חודש
אם > free tier: (חריגה x $0.008) = עלות חודשית

# Codespaces
שעות/יום x cores x ימי עבודה = core-hours/חודש
אם > free tier: (חריגה x $0.18/core-hour) = עלות חודשית

# Packages (private)
סה"כ versions x גודל ממוצע = storage
downloads/חודש x גודל ממוצע = bandwidth

דוגמה למפת שימוש מלאה — מפתח עצמאי

הנה דוגמה לחלק ממפת שימוש שמולאה:

שימו לב: 5 מתוך 7 פיצ'רים לא פעילים — כולם חינמיים. זה טיפוסי. רוב המפתחים מנצלים 20-30% מהפלטפורמה. המפה חושפת את הפער.

תקציב שנתי GitHub:
- תוכנית: [Free/Pro/Team/Enterprise] x [users] x 12 = $____
- Actions (metered): $____ x 12 = $____
- Codespaces (metered): $____ x 12 = $____
- Copilot: $____ x [users] x 12 = $____
- סה"כ: $____
- עם buffer 20%: $____

תקציב שנתי GitHub (Team plan):
- תוכנית: Team x 10 users x $4 x 12 = $480
- Actions (metered): ~$25/חודש x 12 = $300
- Codespaces (metered): ~$15/חודש x 12 = $180
- Copilot Pro: 10 x $10 x 12 = $1,200
- סה"כ: $2,160
- עם buffer 20%: $2,592

השוואה:
- Jenkins self-hosted: ~$500/חודש (שרת + תחזוקה) = $6,000/שנה
- CircleCI Team: $15/user/חודש + compute = ~$4,000/שנה
- GitHub (Team + metered + Copilot): $2,160/שנה
--> GitHub חוסך ~50% לעומת alternatives

11.11 סיכום הקורס ומבט קדימה

סיכום הקורס — מ-Actions עד תוכנית פעולה

ב-11 פרקים עברנו את כל שכבות GitHub. הנה סיכום מהיר של כל פרק — מה למדנו ומה בנינו:

ב-11 פרקים כיסינו את כל שכבות GitHub — מאוטומציה (Actions) דרך סביבות ענן (Codespaces), ניהול פרויקטים (Projects), אבטחה (Security), גישה תכנותית (API), ניהול ארגוני (Organizations), קהילת קוד פתוח (Open Source), ועד מפת תמחור (הפרק הזה). אם עשיתם את כל התרגילים והבנו את כל הפרקים — יש לכם ידע שרוב המפתחים לא מגיעים אליו גם אחרי שנים של שימוש ב-GitHub.

מה עושה את ההבדל? לא הידע עצמו — אלא השימוש. מפתח שמשתמש ב-Actions, Pages, Projects, Dependabot, CodeQL ו-gh cli — מנצל 80% מהפלטפורמה. רוב המפתחים מנצלים 15-20%. הפער הזה הוא פרודוקטיביות, אבטחה, ועלויות — הכל ביחד.

מבט קדימה — מה אחרי הקורס

הקורס הסתיים, אבל GitHub ממשיך להתפתח. כמה דברים שכדאי לעקוב אחריהם:

• GitHub Copilot — המוצר שמתפתח הכי מהר. עקבו אחרי GitHub Changelog לפיצ'רים חדשים.
• GitHub Models — שוק מודלים AI ישירות ב-GitHub. עדיין בשלבים מוקדמים.
• Copilot Workspace — סביבת עבודה AI שמתרגמת issues לקוד אוטומטית. עדיין ב-preview, אבל ההבטחה גדולה.
• שינויי מחירים — GitHub משנה מחירים מעת לעת. המחירים בפרק הזה מעודכנים לאפריל 2026 — בדקו github.com/pricing לעדכונים.
• GitHub Spark — פלטפורמה חדשה לבניית micro-apps ישירות מ-GitHub, בלי deployment חיצוני.

איפה לעקוב? שלושה מקורות שכדאי לסמן:

• GitHub Changelog — כל שינוי ופיצ'ר חדש, יום ביום
• GitHub Blog — מאמרים מעמיקים על פיצ'רים חדשים
• GitHub Community Discussions — שאלות, תשובות, ו-feedback מקהילת המפתחים

טיפ אחרון על שינויי מחירים: GitHub שינתה מחירים כמה פעמים בשנים האחרונות, לרוב לטובת המשתמשים (Free Tier גדל, Copilot Free נוסף, Codespaces free hours נוספו). עם זאת, מחירי metered billing עלולים להשתנות. הרגל טוב: בדקו github.com/pricing פעם ברבעון.

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