הגדרת כללי הגנה על ענפים עבור GitHub ו-GitLab

כיצד אנו מגנים על הענפים שלכם: הגדרת כללי הגנה על ענפים

תארו לעצמכם: בערב יום שישי, מפתח דוחף בטעות קוד גולמי ל-main, והייצור קורס. מציאת הגורם לבעיה אורכת 3 שעות, ותיקונה עוד חצי יום. אילו היו קיימים כללי הגנה על ענפים, ה-commit לא היה עובר — CI היה נכשל, והמיזוג היה נחסם. ראינו תקריות כאלה עשרות פעמים בפרויקטים שונים, מסטארטאפים ועד ארגונים גדולים. בכל פעם הן עלו לצוות שעות של ניפוי באגים ועצבים. כללי הגנה על ענפים הם המחסום המכני היחיד שמונע זאת. הגדרה נכונה של ענפים מוגנים מפחיתה תקריות force-push לאפס וחוסכת עד 80% מזמן הצוות המושקע בתיקון תקלות מקריות. מאמר זה חולק ניסיון מעשי בהגדרת הגנה על ענפים עבור GitHub ו-GitLab, עם תצורות אמיתיות והמלצות מוכחות. המהנדסים שלנו הגדירו הגנה על למעלה מ-200 מאגרים במשך מספר שנים.

מדוע הגנה על ענפים היא קריטית?

ללא כללים, כל מפתח יכול:

• לדחוף ישירות ל-main — והייצור נשבר.
• לבצע force-push — ולאבד commits של עמיתים.
• למזג PR ללא אישור אחד — קוד שלא נבדק נכנס לגרסת release.

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

כיצד להגדיר הגנה ב-GitHub?

ההגדרה נמצאת ב-Settings → Branches → Add branch protection rule. שלב אחר שלב:

1. ציינו את תבנית הענף (לדוגמה, main או release/*).
2. הפעילו "Require a pull request before merging" — דחיפה ישירה אסורה.
3. הגדירו "Required approvals" — אנו ממליצים על 2.
4. הפעילו "Require status checks" וציינו את שמות משימות ה-CI (לדוגמה, build, test).
5. הפעילו "Require up-to-date branches" ו-"Require conversation resolution".
6. הפעילו "Do not allow bypassing" — אפילו מנהלים חייבים לציית לכללים.

להלן הגדרות אופייניות לענף ייצור:

חשוב: עבור Require status checks, עליכם לציין במפורש את שמות המשימות (לדוגמה, build, test). ללא זאת, הכלל לא יפעל. ראו תיעוד GitHub לפרטים.

כיצד להגדיר הגנה ב-GitLab?

ההגדרה ב-GitLab (Settings → Repository → Protected Branches) מפורטת יותר. שלבים:

1. בחרו את הענף (לדוגמה, main).
2. הגדירו "Allowed to push and merge" = "No one".
3. "Allowed to merge" = "Maintainers".
4. הפעילו "Code owner approval required".

Branch: main Allowed to push and merge: No one Allowed to merge: Maintainers Code owner approval: Required 

הגדרת Allow to push = No one מבטיחה שאפילו בעל המאגר לא יכול לדחוף ישירות — רק דרך Merge Request. זה אוכף משמעת טוב יותר מכל הנחיות לבדיקת קוד.

GitLab תומך גם ב-Push Rules (Settings → Repository → Push Rules):

• דחיית commits לא חתומים — רק commits עם חתימת GPG
• בדיקה אם המחבר הוא משתמש GitLab — חוסם commits מכתובות אימייל לא ידועות
• מניעת דחיפת קבצים סודיים — אוסר על קבצים כמו Branch: main Allowed to push and merge: No one Allowed to merge: Maintainers Code owner approval: Required , .pem, .key
• ביטוי רגולרי להודעת commit — מזהה משימה חובה: id_rsa

ראו תיעוד GitLab לפרטים.

אילו כללים מגנים על הענף שלכם?

כללי הגנה על ענפים מכסים מספר שכבות אבטחה. הראשונה היא PR חובה ואישורים. השנייה היא בדיקות סטטוס: CI חייב להיות ירוק. השלישית היא הגבלות על force-push וקבצים חסויים. שילוב שכבות אלה נותן הגנה מפני 99% מהשגיאות האופייניות.

השוואה בין GitHub ו-GitLab

מה כלול בהגדרת הגנה על ענפים?

• ביקורת תצורה נוכחית — בדיקת כללים קיימים, זיהוי נקודות חולשה
• עיצוב כללים — מותאם למודל הענפים שלכם (GitFlow, Trunk-based, GitHub Flow)
• הגדרה בכל המאגרים — כולל כללים ברמת הארגון (GitHub Enterprise / GitLab Premium)
• תיעוד — תיאור הכללים והמלצות לצוות
• הדרכת מפתחים — כיצד לעבוד עם ענפים מוגנים
• תמיכה — סיוע בתקריות, התאמות לכללים

בנוסף, אנו יכולים להגדיר CODEOWNERS להקצאה אוטומטית של סוקרים. קובץ לדוגמה:

# Глобально — tech lead * @myorg/tech-leads
# Инфраструктура — SRE infrastructure/ @myorg/sre-team *.tf @myorg/sre-team
# Frontend src/components/ @myorg/frontend-team
# Backend src/api/ @myorg/backend-team

---
# .github/protected-branches.yml
branch_protection:
  - pattern: main
    require_pr: true
    required_approvals: 2
    dismiss_stale: true
    require_status_checks:
      - build
      - test
    require_up_to_date: true
    require_conversation_resolution: true
    enforce_admins: true
    allow_force_pushes: false
    allow_deletions: false

Force Push: מתי לאפשר, מתי לאסור

אנו תמיד אוסרים זאת עבור main ו-develop — force-push משכתב היסטוריה. אם מישהו כבר פרס commit שנכתב מאוחר יותר, נוצרות אי-התאמות שקשה לנפות. עבור ענפי feature, ניתן לאפשר force-push, אך רק עם ^(PROJ-\d+|Merge branch) (לא # Глобально — tech lead * @myorg/tech-leads # Инфраструктура — SRE infrastructure/ @myorg/sre-team *.tf @myorg/sre-team # Frontend src/components/ @myorg/frontend-team # Backend src/api/ @myorg/backend-team ). פקודה זו מסרבת להמשיך אם לשרת יש commits שאינם קיימים מקומית. כך לא תאבדו שינויים של אחרים.

ציר זמן ועלות

הגדרת כללי הגנה על ענפים למאגר יחיד אורכת 2-3 שעות. עם CODEOWNERS, push rules ותיעוד — חצי יום. מערכת כללים ברמת הארגון (חלה על כל המאגרים) — יום אחד. העלות מחושבת באופן אישי — תלויה במספר המאגרים, מורכבות הכללים וצורך בהדרכת צוות. חיסכון ממוצע בזמן לאחר היישום מגיע ל-80% — על ידי ביטול rollbacks ידניים וזמני השבתה. במשך מספר שנים, הגדרנו הגנה על יותר מ-200 מאגרים — מסטארטאפים ועד אשכולות ארגוניים. למהנדסים שלנו יש ניסיון של שנים. אנו מבטיחים שההגדרה לא תחסום תהליכי פיתוח — אנו בודקים כל כלל על מאגרי דוגמה.

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