ארגונים וצוותות — ניהול בקנה מידה

9.1 ארגון vs חשבון אישי — מתי להקים Organization

כל חשבון GitHub הוא אחד משני סוגים: Personal account (חשבון אישי) או Organization (ארגון). הם נראים דומים מבחוץ — שניהם יכולים להכיל ריפוזיטורים, שניהם מופיעים עם שם ב-URL — אבל מתחת למכסה הם שונים לחלוטין.

חשבון אישי הוא אתם. כל ריפוזיטורי שייך לכם, כל הרשאה עוברת דרככם, ואין שום מבנה ארגוני. זה עובד מצוין כשאתם עובדים לבד, או עם 1-2 שותפים. אבל ברגע שהצוות גדל — דברים נשברים:

• הרשאות — אין דרך לתת לפרונטאנד הרשאה לריפו של הפרונטאנד בלבד. Collaborator מקבל גישה ל-repo ספציפי, אבל אין שום היררכיה.
• בעלות — אם אתם עוזבים את הפרויקט, הריפוזיטורים שלכם. אין transfer אוטומטי, אין ירושה.
• Billing — כל collaborator צריך PAT או SSH key משלו. אין billing מרכזי.
• Secrets — secrets ברמת repo בלבד. אין org-level secrets ששייכים לכולם.
• Audit — אין audit log. אין דרך לדעת מי שינה מה ומתי.

Organization פותר את כל הבעיות האלה. זה חשבון משותף שמכיל ריפוזיטורים, צוותות ומשתמשים. בעלות שייכת לארגון, לא לאדם. הרשאות מנוהלות דרך צוותות, לא דרך הזמנות אישיות. וכל פעולה מתועדת ב-audit log.

בואו נבין את ההבדל הבסיסי. חשבון אישי הוא כמו דירה בשכירות — אתם גרים שם לבד ומנהלים הכל. Organization הוא כמו בניין משרדים — יש ניהול מרכזי, חדרים לצוותות שונים, ומפתחות שונים לאנשים שונים.

הנה ההשוואה הבסיסית:

הכלל הפשוט

אם אחד מהתנאים הבאים מתקיים — הגיע הזמן לארגון:

1. יותר מ-2 אנשים עובדים על אותם ריפוזיטורים באופן קבוע
2. צריך הפרדת הרשאות — צוותות שונים צריכים גישה שונה
3. הפרויקט לא שייך לאדם אחד — זה מוצר של חברה, קהילה או צוות
4. צריך billing מרכזי — חשבונית אחת לכל הצוות
5. צריך audit trail — רגולציה, compliance או פשוט שקיפות

חשוב: ארגון ב-GitHub הוא חינמי. אין עלות ליצירת ארגון. העלות מתחילה רק כשמשדרגים לתוכנית Team ($4/user/חודש) או Enterprise ($21/user/חודש). עם Free plan מקבלים ארגון עם unlimited public repos, unlimited collaborators, ורוב הפיצ'רים הבסיסיים.

דוגמאות מייצגות — מתי ארגון שינה את המצב

נסתכל על שלושה מצבים אופייניים:

מצב 1: סטארטאפ בשלב מוקדם. שלושה מפתחים, 4 ריפוזיטורים. בהתחלה עבדו מהחשבון האישי של ה-CTO. יום אחד ה-CTO עבר לפרויקט אחר — וכל הריפוזיטורים נשארו "שלו". התוצאה: חודש של בירוקרטיה להעביר בעלות. עם ארגון — הריפוזיטורים שייכים לארגון, ואף אדם בודד לא יכול "לקחת" אותם.

מצב 2: פרויקט קוד פתוח שגדל. מפתח בודד פתח ריפוזיטורי ציבורי. 10 תורמים הצטרפו. בלי ארגון — כל collaborator מקבל Write ישירות. אחד מהם מחק branch בטעות. אין audit log, אין דרך לדעת מי עשה את זה. עם ארגון — צוותות עם הרשאות מדויקות, audit log שמתעד כל פעולה.

מצב 3: חברה עם 15 מפתחים. צוות פרונטאנד, צוות בקאנד, ו-DevOps. כולם צריכים גישה לריפוזיטורים שונים ברמות שונות. בלי ארגון — 15 x 12 = 180 הרשאות אישיות לנהל. עם ארגון — 3 צוותות, כל צוות עם הגדרות ברורות. מפתח חדש? מוסיפים לצוות ומסיימים.

9.2 הגדרת ארגון — מאפס לארגון עובד

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

שלב 1: יצירת ארגון

1. כנסו ל-github.com/account/organizations/new
2. בחרו תוכנית — Free מספיקה כדי להתחיל ולתרגל את כל מה שנלמד
3. בחרו שם לארגון — זה יהיה ה-namespace שלכם: github.com/your-org-name
4. הזינו email ליצירת קשר
5. ענו על השאלה "This organization belongs to" — my personal account אם זה לצרכי לימוד

טיפ לבחירת שם: שם הארגון מופיע ב-URL של כל ריפו, ב-package names (למשל @your-org/package), וב-container images (ghcr.io/your-org/image). בחרו שם קצר, ייחודי, ללא מקפים מיותרים. אי אפשר לשנות שם ארגון בקלות — זה שובר URLs, packages ו-CI.

שמות טובים: acme-labs, your-company, project-name. שמות גרועים: my-org-2026-v2, john-and-friends-projects. חשבו: אם החברה גדלה ל-100 אנשים — האם השם עדיין הגיוני?

יצירה דרך gh CLI

אפשר ליצור ארגון גם מהטרמינל (אם למדתם פרק 2 — GitHub CLI):

# יצירת ארגון חדש (פותח דפדפן לסיום)
gh api /user/orgs --method POST \
  -f login="your-org-name" \
  -f name="Your Organization Display Name" \
  -f billing_email="billing@example.com"

# בדיקה שהארגון נוצר
gh org list

שימו לב: יצירה דרך ה-API דורשת שלמשתמש שלכם יש permission ליצור ארגונים (זה ברירת המחדל). אחרי היצירה, עדיין צריך להגדיר את ההגדרות דרך ה-UI או דרך API calls נוספים.

שלב 2: הגדרות ברירת מחדל קריטיות

אחרי היצירה, כנסו ל-Settings של הארגון. ההגדרות הבאות חובה לעדכן מייד:

Member Privileges (Settings → Member privileges)

Security (Settings → Code security and analysis)

הפעילו את כל האפשרויות הבאות ברמת הארגון — הן יחולו על כל ריפוזיטורי חדש:

• Dependency graph — Enabled (חובה ל-Dependabot)
• Dependabot alerts — Enabled
• Dependabot security updates — Enabled
• Secret scanning — Enabled
• Push protection — Enabled

אם למדתם את פרק 7 (Security), אתם כבר מכירים את כל הפיצ'רים האלה. ההבדל: כאן אתם מפעילים אותם ברמת הארגון — מה שאומר שכל ריפוזיטורי חדש שנוצר מקבל את ההגדרות האלה אוטומטית, בלי שמישהו צריך לזכור להפעיל.

הגדרות Actions (Settings → Actions → General)

ברמת ארגון אפשר לשלוט מי יכול להריץ Actions:

• Actions permissions: "Allow all actions and reusable workflows" (ברירת מחדל) או להגביל ל-actions של GitHub בלבד ושל creators מאומתים
• Required workflows: workflows שחייבים לרוץ על כל ריפו בארגון — מצוין ל-CI מינימלי אחיד
• Fork pull request workflows: מומלץ להגדיר "Require approval for first-time contributors" — מונע הרצת actions זדוני מ-PRs של זרים

Org-level Secrets (Settings → Secrets and variables → Actions)

אחד היתרונות הגדולים של ארגון הוא org-level secrets. במקום להגדיר את אותו API key ב-20 ריפוזיטורים — מגדירים פעם אחת ברמת הארגון ובוחרים אילו ריפוזיטורים (או כולם) יכולים לגשת:

# הגדרת secret ברמת ארגון דרך gh cli
gh secret set NPM_TOKEN \
  --org your-org \
  --visibility selected \
  --repos "repo1,repo2,repo3"

# או ניתן לכל הריפוזיטורים
gh secret set DEPLOY_KEY \
  --org your-org \
  --visibility all

שלוש רמות visibility ל-org secrets:

• All repositories — כולם יכולים לגשת. שימוש: API keys שכל הפרויקטים צריכים.
• Private repositories — רק ריפוזיטורים פרטיים. מונע חשיפה דרך public repos.
• Selected repositories — רשימה ספציפית. הכי מאובטח — least privilege.

9.3 תפקידים והרשאות — Least Privilege בפעולה

ניהול הרשאות ב-GitHub Organization עובד בשלוש שכבות: תפקיד ברמת הארגון (org role), הרשאה ברמת הריפוזיטורי (repo role), והרשאות ברמת צוות (team permission). ההבנה של שלוש השכבות האלה היא המפתח לניהול נכון.

תפקידים ברמת הארגון

הרשאות ברמת ריפוזיטורי

כל ריפוזיטורי תומך ב-5 רמות הרשאה. כשאתם מוסיפים צוות לריפו, אתם בוחרים אחת מהרמות:

הכלל: Start Narrow, Expand Later

עיקרון ה-Least Privilege אומר: תנו את ההרשאה המינימלית שמספיקה לבצע את העבודה. תמיד אפשר להוסיף הרשאות — קשה מאוד להוריד אותן בלי לשבור משהו.

בפועל זה אומר:

• מפתח חדש מקבל Write על הריפוזיטורים שהוא עובד עליהם — לא Admin
• Tech lead מקבל Maintain — יכול לנהל settings בלי יכולת למחוק את הריפו
• מנהל מוצר מקבל Triage — יכול לנהל issues ו-PRs בלי push לקוד
• QA מקבל Read — יכול לצפות בקוד ולפתוח issues, אבל לא לשנות
• Admin רק לריפוזיטורים קריטיים, ורק ל-owners בפועל

אם מישהו מבקש "אני צריך Admin" — שאלו: "מה ספציפית אתה צריך לעשות?" ברוב המקרים, Write או Maintain מספיק. Admin נחוץ רק ל-webhook configuration, branch protection changes, ומחיקת ריפו — דברים שאדם ממוצע לא צריך לעשות יומיומית.

Custom Repository Roles — Enterprise בלבד

ב-Enterprise, אפשר ליצור Custom Repository Roles — תפקידים מותאמים שמשלבים הרשאות ספציפיות מעבר ל-5 הרמות הסטנדרטיות. למשל:

• "Security Reviewer" — Read + manage security advisories + view secret scanning results. יכול לראות בעיות אבטחה בלי Write על הקוד.
• "Release Manager" — Write + manage releases + manage GitHub Pages. יכול לפרסם releases בלי Admin.
• "CI Manager" — Write + manage Actions + manage webhooks. יכול לנהל CI/CD בלי גישה ל-settings של הריפו.

יצירת custom role: Organization → Settings → Roles → Create a role. בוחרים base role (Read/Triage/Write/Maintain) ומוסיפים הרשאות ספציפיות. אחרי היצירה, ניתן לתת את התפקיד לצוותות על ריפוזיטורים ספציפיים.

אם אתם לא ב-Enterprise — לא צריך את זה ברוב המקרים. 5 הרמות הסטנדרטיות מכסות 95% מהתרחישים. Custom roles הם "נחמד שיש" לארגונים גדולים עם דרישות מדויקות.

הזמנת חברים — Best Practices

כשמזמינים חבר חדש לארגון, יש כמה דברים שכדאי לעשות:

1. הזמינו כ-Member, לא כ-Owner. תמיד. גם אם זה ה-CTO. Owner רק למי שמנהל את הארגון בפועל.
2. הוסיפו לצוות מייד. Member בלי צוות = Member בלי הרשאות (אם base permission הוא Read). ודאו שהאדם מצטרף לצוות הנכון ברגע שהוא מתקבל.
3. דרשו 2FA. ב-Organization → Settings → Authentication security, הפעילו "Require two-factor authentication". כל חבר שלא מגדיר 2FA תוך שבועיים — מוסר אוטומטית.
4. ליצרו onboarding checklist. קובץ ONBOARDING.md שמסביר: אילו צוותות יש, איך לבקש גישה, מה מותר ומה אסור.

9.4 צוותות — מבנה היררכי שעובד

צוותות (Teams) הם הלב של ניהול הרשאות בארגון. במקום לתת הרשאות לכל אדם בנפרד על כל ריפוזיטורי, אתם יוצרים צוות, מוסיפים אנשים, ונותנים לצוות גישה לריפוזיטורים. כשאדם חדש מצטרף — מוסיפים אותו לצוות, והוא מקבל את כל ההרשאות אוטומטית.

למה צוותות ולא הרשאות ישירות?

דמיינו ארגון עם 20 מפתחים ו-15 ריפוזיטורים. בלי צוותות, צריך לנהל 20 x 15 = 300 הרשאות אישיות. עם 4 צוותות, צריך לנהל 4 x 15 = 60 הרשאות צוותיות + 20 חברויות. כשמישהו עוזב, במקום לעבור על 15 ריפוזיטורים ולהסיר — מסירים מהצוות ומסיימים.

יצירת צוות

1. בדף הארגון, לחצו על טאב Teams
2. לחצו New team
3. בחרו שם — מומלץ: frontend, backend, devops, design
4. הוסיפו תיאור — "צוות הפרונטאנד — React, Next.js, CSS"
5. בחרו Visibility: Visible (כולם רואים) או Secret (רק חברי הצוות)
6. אם רלוונטי — בחרו Parent team ליצירת nested team

Nested Teams — צוותות מקוננים

GitHub תומך ב-nested teams — צוות בתוך צוות. צוות ילד יורש את כל ההרשאות של צוות ההורה, ואפשר להוסיף לו הרשאות נוספות. זה שימושי במבנים ארגוניים גדולים:

בדוגמה הזו, @org/engineering הוא צוות ההורה. כל מי שב-@org/frontend מקבל גם את ההרשאות של @org/engineering. אם engineering יקבל Read על ריפוזיטורי docs — כל חברי frontend, backend ו-devops יקבלו את ההרשאה הזו אוטומטית.

Team Maintainers

כל צוות יכול שיהיו לו maintainers — חברים שיכולים להוסיף ולהסיר חברים מהצוות, לשנות שם ותיאור, ולנהל את הצוות בלי להיות Owner של הארגון. זה מאפשר דלגציה: ה-tech lead של הפרונטאנד מנהל את צוות frontend בלי צורך בגישת admin לכל הארגון.

ניהול צוותות דרך gh CLI

אם למדתם פרק 2 (GitHub CLI), הנה פקודות שימושיות לניהול צוותות מהטרמינל:

# רשימת צוותות בארגון
gh api /orgs/YOUR-ORG/teams --jq '.[] | "\(.slug): \(.members_count) members"'

# יצירת צוות חדש
gh api /orgs/YOUR-ORG/teams --method POST \
  -f name="mobile" \
  -f description="צוות מובייל — iOS ו-Android" \
  -f privacy="closed"

# הוספת חבר לצוות
gh api /orgs/YOUR-ORG/teams/frontend/memberships/USERNAME --method PUT \
  -f role="member"

# מתן הרשאה לצוות על ריפו
gh api /orgs/YOUR-ORG/teams/frontend/repos/YOUR-ORG/REPO --method PUT \
  -f permission="push"

Team Discussions ו-Mentions

צוותות ב-GitHub הם לא רק מנגנון הרשאות — הם גם ערוץ תקשורת. כל צוות תומך ב:

• @mentions — כתבו @org/frontend ב-issue, PR או comment — כל חברי הצוות יקבלו notification. זה הרבה יותר יעיל מלתייג כל אדם בנפרד.
• Team Discussions — כל צוות יכול לנהל דיונים פנימיים. שימושי ל-RFCs, החלטות ארכיטקטוניות, או עדכונים שנוגעים רק לצוות.
• Review requests — כשמבקשים review מ-@org/frontend, GitHub יכול לחלק את הבקשה בין חברי הצוות לפי load balancing (CODEOWNERS with round-robin).

טיפ מעשי: בכל PR שנוגע בקוד של צוות אחר — תייגו את הצוות, לא אדם ספציפי. אם @sarah בחופשה — ה-PR תקוע. אם @org/backend — מישהו אחר מהצוות ישים לב.

9.5 CODEOWNERS — מי אחראי על מה

CODEOWNERS הוא קובץ שמגדיר מי חייב לאשר שינויים בקבצים מסוימים. כשנפתח PR שמשנה קובץ שיש לו CODEOWNER — GitHub מוסיף אוטומטית את ה-owner כ-reviewer, ואם branch protection מחייב CODEOWNER approval — ה-PR לא יכול להתמזג בלי האישור שלהם.

זה המנגנון הכי חשוב שיש ל-code quality בצוותות גדולים. בלי CODEOWNERS, כל אחד עם Write יכול לשנות כל קובץ. עם CODEOWNERS, שינוי ב-infrastructure code חייב לעבור דרך צוות DevOps, ושינוי ב-API חייב לעבור דרך צוות Backend.

יצירת קובץ CODEOWNERS

הקובץ חייב להיקרא CODEOWNERS (באותיות גדולות) ולשבת באחד מהמיקומים:

• CODEOWNERS — בשורש הריפוזיטורי
• .github/CODEOWNERS — בתיקיית .github (מומלץ — מסודר יותר)
• docs/CODEOWNERS — בתיקיית docs

הסינטקס פשוט — כל שורה מכילה pattern ואחריו owners:

# CODEOWNERS — הגדרת בעלות על קוד
# כל שורה: pattern owner1 owner2 ...

# ברירת מחדל — כל קובץ שלא מוגדר אחרת
*                       @org/engineering

# Frontend — כל מה שב-src/components ו-src/pages
/src/components/        @org/frontend
/src/pages/             @org/frontend
*.css                   @org/frontend @user-design-lead
*.scss                  @org/frontend

# Backend — כל מה שב-api/
/api/                   @org/backend
/database/              @org/backend @user-dba

# DevOps — תשתית ו-CI
/.github/workflows/     @org/devops
/infrastructure/        @org/devops
Dockerfile              @org/devops
docker-compose.yml      @org/devops

# Security — קבצים רגישים
/security/              @org/security-team
.env.example            @org/security-team @org/devops

# Documentation
/docs/                  @org/engineering
README.md               @org/engineering

כללים חשובים

• השורה האחרונה שמתאימה מנצחת. אם שתי שורות מתאימות לקובץ — השורה האחרונה קובעת. סדרו מכללי לספציפי.
• Owners יכולים להיות: @username, @org/team-name, או email@example.com
• Patterns עובדים כמו gitignore: * = הכל, *.js = כל קובצי JS, /src/ = תיקייה ספציפית
• CODEOWNERS לא עובד בלי branch protection. הקובץ מגדיר מי, branch protection מגדיר שחייב.

CODEOWNERS + Branch Protection — השילוב שעובד

CODEOWNERS לבד לא אוכף כלום. הוא רק מציע reviewers. כדי שה-approval יהיה חובה, צריך גם branch protection או ruleset שמגדיר "Require review from Code Owners". הנה איך שני המנגנונים עובדים ביחד:

1. מפתח פותח PR שמשנה קובץ ב-/api/
2. CODEOWNERS מזהה שהבעלים של /api/ הוא @org/backend
3. GitHub מוסיף אוטומטית את @org/backend כ-reviewer
4. Branch protection/ruleset דורש שלפחות חבר אחד מ-@org/backend יאשר
5. עד שהאישור מגיע — ה-PR מסומן כ-"Review required" ולא ניתן ל-merge

בלי branch protection, ה-PR יכול להתמזג גם בלי אישור — CODEOWNERS רק מציע. תמיד שלבו את שני המנגנונים ביחד.

פתרון בעיות נפוצות ב-CODEOWNERS

כמה מצבים שכולם נתקלים בהם ואיך לפתור:

• "Invalid CODEOWNERS file" — בדרך כלל שם צוות שגוי. ודאו שהצוות קיים ושאתם כותבים @org/team-name ולא @team-name.
• PR תקוע כי CODEOWNER לא זמין — פתרון: הגדירו צוות כ-owner, לא אדם ספציפי. אם הצוות מכיל 3 אנשים — תמיד מישהו יהיה זמין.
• שני patterns מתנגשים — זכרו: השורה האחרונה שמתאימה מנצחת. סדרו מכללי (למעלה) לספציפי (למטה).
• CODEOWNER review לא נדרש — ודאו שב-branch protection/ruleset מסומן "Require review from Code Owners".

mkdir -p src/frontend src/backend docs .github/workflows
touch src/frontend/app.js src/backend/server.js docs/README.md
touch .github/workflows/ci.yml

# Default — כל מה שלא מוגדר אחרת
*                       @your-org/engineering

# Frontend code
/src/frontend/          @your-org/frontend

# Backend code
/src/backend/           @your-org/backend

# CI/CD workflows
/.github/workflows/     @your-org/devops

# Documentation
/docs/                  @your-org/engineering

9.6 Repository Rulesets — הדור החדש של Branch Protection

Repository Rulesets הם המנגנון המרכזי של GitHub לאכיפת מדיניות על branches ו-tags. הם הגרסה החדשה והמשופרת של Branch Protection Rules — יותר גמישים, ניתנים לניהול ברמת הארגון, ותומכים ב-bypass lists מדויקים.

Branch Protection vs Rulesets — מה ההבדל?

ההמלצה: אם אתם מתחילים מאפס — השתמשו ב-Rulesets. אם יש לכם branch protection קיים — אין צורך לעבור מייד, אבל כדאי לתכנן מעבר.

יצירת Ruleset

כנסו ל-Repository → Settings → Rules → Rulesets → New ruleset:

1. Ruleset name: שם מתאר — למשל "main-branch-protection"
2. Enforcement status:
   • Active — אוכף מייד
   • Evaluate — מדווח ב-insights בלי לאכוף (מצוין לבדיקה לפני הפעלה)
   • Disabled — כבוי
3. Bypass list: מי יכול לעקוף את ה-ruleset — היו מינימליסטים. אפשר: roles, teams, apps.
4. Target branches: על איזה branches הכלל חל — main, release/*, או Default branch

Rules שכדאי להפעיל

echo "test" >> test.txt
git add test.txt
git commit -m "test direct push"
git push origin main

Org-level Rulesets — כלל אחד לכל הארגון

אחד היתרונות הגדולים של rulesets הוא היכולת להגדיר אותם ברמת הארגון. במקום להגדיר ruleset בכל ריפוזיטורי בנפרד, אפשר ליצור ruleset אחד שחל על כל הריפוזיטורים (או על בחירה ספציפית).

כדי ליצור org-level ruleset: Organization → Settings → Rules → New ruleset. בשדה Repository targeting, בחרו:

• All repositories — הכלל חל על כל ריפו בארגון
• Dynamic list by name — pattern כמו production-* — רק ריפוזיטורים שמתאימים
• Dynamic list by property — לפי custom properties (Enterprise)
• Select repositories — רשימה ספציפית

דוגמה מעשית: ארגון עם 30 ריפוזיטורים רוצה שכל branch של main יהיה מוגן — חייב PR, חייב review, אסור force push. במקום 30 rulesets — ruleset אחד ברמת הארגון שחל על כולם. מפתח חדש יוצר ריפו? ה-ruleset חל אוטומטית.

Evaluate Mode — בדיקה לפני אכיפה

אחד הפיצ'רים החכמים ב-rulesets הוא Evaluate mode. כשמגדירים ruleset ב-evaluate, הוא מדווח אילו פעולות היו נחסמות — בלי באמת לחסום. זה מאפשר לכם:

1. ליצור ruleset חדש ב-Evaluate
2. לחכות שבוע ולבדוק ב-insights כמה פעולות היו נחסמות
3. אם מעט מדי — אולי ה-ruleset רפוי מדי
4. אם יותר מדי — אולי ה-ruleset מחמיר מדי ויפריע לצוות
5. כשמרוצים — העבירו ל-Active

גישה ל-insights: Repository → Settings → Rules → Rulesets → Rule Insights. מציג כמה pushes נחסמו (או היו נחסמים) על ידי כל ruleset.

Tag Protection עם Rulesets

Rulesets יכולים להגן גם על tags — לא רק branches. זה חשוב כי tags בדרך כלל מייצגים releases: v1.0.0, v2.3.1. אם מישהו מוחק או משנה tag — זה יכול לשבור deploy pipelines, package versions ו-changelogs.

ליצירת tag ruleset: Settings → Rules → Rulesets → New ruleset → New tag ruleset. הגדרו target tag pattern (למשל v*) והפעילו "Block deletion" ו-"Block force push".

ייצוא וייבוא Rulesets

Rulesets תומכים ב-JSON export/import. זה שימושי כשרוצים ליצור ruleset זהה ב-repositories או ארגונים שונים:

# ייצוא ruleset ל-JSON
gh api /repos/ORG/REPO/rulesets/RULESET_ID --jq '.' > ruleset.json

# ייבוא לריפו אחר (אחרי עריכה)
gh api /repos/ORG/OTHER-REPO/rulesets --method POST \
  --input ruleset.json

Ruleset Stacking — מה קורה כשיש כמה rulesets?

אחד הפיצ'רים החזקים של rulesets הוא stacking — אפשר שמספר rulesets יחולו על אותו branch. כשזה קורה, הכלל הכי מחמיר מנצח:

• Ruleset A דורש 1 reviewer
• Ruleset B דורש 2 reviewers
• התוצאה: 2 reviewers נדרשים

זה שימושי כשיש org-level ruleset בסיסי (מינימום 1 reviewer) ועל ריפוזיטורים קריטיים מוסיפים repo-level ruleset מחמיר יותר (2 reviewers + signed commits). שני ה-rulesets חלים ביחד — לא צריך לשכפל הגדרות.

חשוב: Stacking עובד רק עם rulesets, לא עם branch protection rules. זו עוד סיבה לעבור ל-rulesets.

9.7 Audit Log — מי עשה מה ומתי

Audit log הוא יומן שמתעד כל פעולה ניהולית בארגון. כל פעם שמישהו מוסיף חבר, משנה הגדרה, מוחק ריפו, מפעיל deploy key, או מתקין GitHub App — זה נרשם ב-audit log. זה הכלי שמאפשר לכם לענות על השאלה "מי עשה את זה?" בלי לשאול אנשים.

גישה ל-Audit Log

Organization → Settings → Audit log (דורש Owner permission)

ב-Free plan תקבלו 90 יום של היסטוריה. ב-Enterprise — עד 180 יום (וניתן להגדיר streaming חיצוני ל-S3, Splunk, Datadog ועוד).

סוגי אירועים חשובים

חיפוש ב-Audit Log

Audit log תומך בחיפוש מובנה. הנה queries שימושיים:

# מי שינה visibility של ריפוזיטורי?
action:repo.access

# איזה ריפוזיטורים נמחקו בחודש האחרון?
action:repo.destroy

# מי הוסיף GitHub App חדשה?
action:integration_installation.create

# מה עשה משתמש ספציפי?
actor:username

# כל הפעולות על ריפו ספציפי
repo:org-name/repo-name

מה לא מופיע ב-Audit Log

חשוב לדעת גם מה לא מתועד:

• Git operations רגילות — push, pull, clone לא מופיעים (חוץ מ-Enterprise עם Git events מופעל)
• קריאת קוד — צפייה בקובץ דרך הדפדפן לא מתועדת
• Actions runs — הרצות workflows לא מופיעות ב-audit log (יש לוגים נפרדים ב-Actions)
• Code review comments — תגובות על PRs לא מתועדות ב-audit log (הן חלק מה-PR עצמו)

Audit log מתמקד בפעולות ניהוליות — שינויים בהגדרות, בהרשאות, בחברויות ובמדיניות. לניטור של פעילות git (מי דחף מה ומתי), צריך כלים אחרים או Enterprise עם Git events.

Audit Log API

לארגונים שצריכים ניטור אוטומטי, ניתן לגשת ל-audit log דרך ה-API:

# שליפת audit log דרך gh cli
gh api /orgs/YOUR-ORG/audit-log \
  --method GET \
  -f phrase='action:repo.destroy' \
  --jq '.[] | "\(.created_at) \(.actor) \(.action) \(._document_id)"'

ב-Enterprise, ניתן גם להגדיר Audit log streaming — שליחה אוטומטית של כל האירועים לשירות חיצוני: Amazon S3, Azure Blob Storage, Google Cloud Storage, Splunk, או Datadog. זה מאפשר שמירה ארוכת טווח, התראות אוטומטיות ודשבורדים.

תרחישים שבהם Audit Log מציל

הנה מצבים אמיתיים שבהם audit log הוא ההבדל בין "בלש" ל-"ניחוש":

• "מי שינה את ה-visibility של הריפו שלנו ל-public?" — חפשו action:repo.access. תראו בדיוק מי, מתי, ומאיזו IP.
• "למה ה-CI נשבר פתאום?" — חפשו action:protected_branch — אולי מישהו שינה branch protection rules.
• "מי התקין את ה-GitHub App הזו?" — חפשו action:integration_installation.create. חשוב במיוחד כי GitHub Apps מקבלות הרשאות רחבות.
• "האם מישהו ניגש לריפוזיטורים רגישים?" — חפשו action:repo.clone עם actor:suspicious-username.

9.8 SSO, SAML ו-SCIM — אימות ארגוני

SSO (Single Sign-On) מאפשר לחברי הארגון להתחבר ל-GitHub דרך ספק הזהות הארגוני — Okta, Azure AD, OneLogin או אחר. במקום שכל מפתח ינהל סיסמה נפרדת ל-GitHub, הוא מתחבר פעם אחת דרך הספק הארגוני ומקבל גישה לכל השירותים, כולל GitHub.

חשוב: SSO/SAML דורש תוכנית Enterprise. הוא לא זמין ב-Free או Team. אם אתם בארגון קטן עם Free/Team — קראו את הסעיף הזה כדי להבין מה Enterprise מציע, אבל אל תנסו ליישם.

שלושה מושגים שצריך להכיר

למה SSO חשוב?

• אבטחה: מפתח שעוזב את החברה — מוסר אוטומטית מ-GitHub (דרך SCIM). בלי SSO, צריך לזכור להסיר ידנית.
• Compliance: רגולציות רבות (SOC 2, ISO 27001, GDPR) דורשות ריכוז אימות. SSO מספק את זה.
• חוויית משתמש: כניסה אחת — לא צריך לזכור סיסמה נוספת ל-GitHub.
• MFA מרוכז: ה-MFA מנוהל בספק הזהות, לא בכל שירות בנפרד.

SCIM — סנכרון אוטומטי של משתמשים

SCIM (System for Cross-domain Identity Management) הוא השכבה שמעל SAML. בזמן ש-SAML מטפל באימות (מי אתה), SCIM מטפל בprovisioning (ניהול החשבונות):

• Provisioning: עובד חדש נוסף ב-Okta → SCIM יוצר אוטומטית חשבון GitHub → מוסיף לצוותות הנכונים
• De-provisioning: עובד עוזב → מוסר מ-Okta → SCIM מסיר מ-GitHub → הגישה נחסמת מייד
• Group sync: קבוצות ב-Okta ממופות לצוותות ב-GitHub. שינוי קבוצה ב-Okta → שינוי צוות ב-GitHub

בלי SCIM, כשעובד עוזב צריך לזכור להסיר אותו ידנית מ-GitHub. בארגון של 100 אנשים, עם 10 עזיבות בשנה — זה 10 הזדמנויות לשכוח ולהשאיר גישה פתוחה. SCIM מבטל את הסיכון הזה לגמרי.

ספקי זהות נתמכים

GitHub תומך רשמית ב-SAML SSO עם הספקים הבאים:

9.9 Billing ועלויות — Free, Team ו-Enterprise

GitHub מציע שלוש תוכניות לארגונים. הבחירה משפיעה על כל מה שלמדנו בפרק: הרשאות, rulesets, audit log, SSO, ו-CODEOWNERS enforcement. הנה ההשוואה המעשית:

הנקודות הקריטיות

• Branch protection/rulesets על private repos — זה מה שמכריח את רוב הצוותות לשדרג ל-Team. אם יש לכם ריפוזיטורים פרטיים וצריכים code review מחייב — אתם צריכים Team.
• SSO — זמין רק ב-Enterprise. אם הארגון דורש SSO — אין ברירה.
• Custom roles — ב-Free ו-Team יש רק 5 רמות הרשאה (Read-Admin). ב-Enterprise אפשר ליצור תפקידים מותאמים.
• Internal repos — visibility שקיים רק ב-Enterprise. Internal repo נגיש לכל חברי הארגון אבל לא לציבור. שימושי לספריות משותפות.

חישוב עלות מעשי

בואו נחשב עלות חודשית לתרחישים שונים:

תרחיש 1: סטארטאפ, 5 מפתחים, private repos, צריך code review מחייב.

• Free לא מספיק — branch protection על private repos דורש Team
• עלות: 5 x $4 = $20/חודש
• פלוס: 3,000 Actions minutes (במקום 2,000) ו-2GB Packages (במקום 500MB)

תרחיש 2: חברה, 30 מפתחים, צריכים SSO + audit streaming.

• Team לא מספיק — SSO דורש Enterprise
• עלות: 30 x $21 = $630/חודש
• פלוס: 50,000 Actions minutes, SCIM, custom roles, internal repos

תרחיש 3: פרויקט open source, 50 תורמים, public repos בלבד.

• Free מספיק — branch protection עובד על public repos, Actions unlimited על public repos
• עלות: $0

9.10 מיגרציה — מחשבון אישי לארגון

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

מה קורה ב-Transfer?

כשמעבירים ריפוזיטורי מחשבון אישי לארגון:

• URL משתנה: github.com/username/repo → github.com/org-name/repo. GitHub מגדיר redirect אוטומטי מה-URL הישן, אבל ה-redirect הזה לא עובד לכל מקום (API calls, webhook URLs, links בתוך CI).
• Git remotes נשברים: כל מי שעשה clone צריך לעדכן את ה-remote: git remote set-url origin NEW_URL
• Issues ו-PRs: נשמרים כולם, כולל labels, milestones ו-assignees.
• Stars ו-Watchers: נשמרים.
• GitHub Pages: הדומיין משתנה ל-org-name.github.io/repo. אם יש custom domain — צריך לעדכן.
• Actions secrets: לא מועברים — צריך להגדיר מחדש בארגון.
• Webhooks: נשמרים, אבל בדקו שה-URLs עדיין נכונים.
• Branch protection: נשמר.
• Collaborators: הופכים ל-outside collaborators. צריך להוסיף אותם לצוותות.

צ'קליסט לפני מיגרציה

לפני שמעבירים ריפוזיטורי — עברו על הרשימה הזו ותעדו הכל:

תהליך ההעברה

1. לפני: ודאו שיש לכם Owner permission בארגון היעד
2. לפני: תעדו את כל ה-secrets, webhooks ו-CI settings של הריפו (טבלה למעלה)
3. לפני: הודיעו לכל חברי הצוות שה-URL ישתנה
4. כנסו ל-Repository → Settings → General → גללו לתחתית → Transfer repository
5. הקלידו את שם הארגון היעד
6. אשרו את ההעברה (GitHub יבקש הקלדת שם הריפו לאישור)
7. אחרי: הגדירו secrets מחדש — שימו לב שאם כבר יש org-level secrets, הריפו יכול לגשת אליהם
8. אחרי: עדכנו remotes אצל כל חברי הצוות: git remote set-url origin NEW_URL
9. אחרי: הוסיפו צוותות עם ההרשאות הנכונות
10. אחרי: בדקו ש-CI עובד — ה-workflow הראשון אחרי transfer הוא הבדיקה הטובה ביותר

זמן ההעברה: מיידי. ברגע שאתם מאשרים — הריפו עובר. אבל redirect מה-URL הישן יכול לקחת כמה דקות להתעדכן.

העברה של מספר ריפוזיטורים — Batch Transfer

אם צריך להעביר 5, 10, או 20 ריפוזיטורים — אפשר לעשות את זה דרך ה-API במקום ידנית:

# רשימת כל הריפוזיטורים שלכם
gh repo list --limit 100 --json name,owner \
  --jq '.[] | select(.owner.login == "YOUR-USERNAME") | .name'

# העברה דרך API (לכל ריפו בנפרד)
gh api /repos/YOUR-USERNAME/REPO-NAME/transfer \
  --method POST \
  -f new_owner="YOUR-ORG"

# בדיקה שההעברה הצליחה
gh repo view YOUR-ORG/REPO-NAME --json url --jq '.url'

שימו לב: גם דרך API, secrets לא מועברים. אחרי transfer של מספר ריפוזיטורים, עברו על כולם וודאו ש-CI עובד.

מתי לא להעביר

לא כל ריפו צריך להיות בארגון. ריפוזיטורים אישיים — dotfiles, ניסויים, side projects — עדיף שיישארו על החשבון האישי. הכלל: אם ריפו הוא חלק מהעבודה של הצוות → ארגון. אם הוא פרויקט אישי שלכם → חשבון אישי. אם אתם לא בטוחים — שאלו: "אם אני עוזב מחר, האם מישהו אחר צריך גישה לריפו הזה?" אם כן → ארגון.

gh repo create migration-test --public --clone
cd migration-test
echo "# Migration Test" > README.md
git add . && git commit -m "Initial" && git push

git remote set-url origin https://github.com/your-org/migration-test.git
git remote -v  # ודאו שה-URL חדש

9.11 סיכום ומבט קדימה

# הכלל הבסיסי שמספיק ל-80% מהמקרים:
# .github/CODEOWNERS
*    @your-org/engineering

טעויות נפוצות — סיכום

לפני שממשיכים, הנה חמש הטעויות הנפוצות ביותר בניהול ארגוני GitHub — וודאו שאתם לא עושים אותן:

gh api /orgs/YOUR-ORG/audit-log \
  --method GET \
  -f phrase='action:team' \
  --jq '.[] | "\(.created_at | split("T")[0]) | \(.actor) | \(.action)"'

מבט קדימה

בפרק הבא: נלמד את הצד השני של ניהול ארגון — קוד פתוח. איך לפתוח פרויקט לתרומה מבחוץ, איך ליצור README מקצועי, issue templates, contributing guidelines, ואיך לבנות קהילה בריאה סביב הקוד. הארגון שבנינו בפרק הזה הוא הבסיס — עכשיו נלמד לפתוח אותו לעולם.

מה שמגיע בהמשך:

• פרק 10: קוד פתוח — README profiles, issue templates, Discussions, Sponsors, רישיונות
• פרק 11: המפה המלאה — חינמי vs בתשלום, אסטרטגיית שדרוג, מיקסום free tier