Git

תהליכי עבודה (Workflows)

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

1. Feature Branch Workflow

הפשוט והנפוץ ביותר. מתאים לרוב הצוותים הקטנים והבינוניים.

עקרונות

• main תמיד יציב וזמין לפריסה
• כל פיצ'ר מקבל branch משלו
• merge ל-main מתבצע דרך Pull Request

זרימה

# 1. סנכרון main
git switch main
git pull

# 2. branch חדש לפיצ'ר
git switch -c feature/user-profile

# 3. עבודה וcommits
git add .
git commit -m "Add user profile component"

# 4. דחיפה
git push -u origin feature/user-profile

# 5. יצירת Pull Request ב-GitHub

# 6. אחרי merge - ניקוי
git switch main
git pull
git branch -d feature/user-profile

יתרונות

• פשוט להבנה
• מתאים לכל גודל צוות
• ה-main נשאר נקי ויציב

2. Git Flow

זרימה מורכבת יותר עם branches קבועים מרובים. מתאימה לפרויקטים גדולים עם releases מתוכננים.

Branches קבועים

Branches זמניים

זרימה

# פיצ'ר חדש
git switch develop
git switch -c feature/login
# ...עבודה...
git switch develop
git merge feature/login

# הכנת release
git switch -c release/v1.2.0 develop
# ...בדיקות, תיקוני באגים קטנים...
git switch main
git merge release/v1.2.0
git tag v1.2.0
git switch develop
git merge release/v1.2.0

# Hotfix
git switch -c hotfix/critical-bug main
# ...תיקון...
git switch main
git merge hotfix/critical-bug
git tag v1.2.1
git switch develop
git merge hotfix/critical-bug

יתרונות

• מתאים ל-releases מסודרים
• הפרדה ברורה בין production ל-development

חסרונות

• מורכב
• לא מתאים לפרויקטים עם CI/CD רציף

3. GitHub Flow

הפשוט מבין השלושה. כל פיצ'ר ישר ל-main, בלי develop באמצע.

עקרונות

• רק branch אחד קבוע: main
• כל פיצ'ר ב-feature branch
• merge ל-main = פריסה ל-production מיד

זרימה

git switch main
git pull
git switch -c feature/login
# ...עבודה...
git push -u origin feature/login
# יצירת PR
# מיזוג + פריסה אוטומטית

מתי מתאים?

• פרויקטי SaaS עם CI/CD חזק
• צוותים שעושים deploy מספר פעמים ביום
• מוצרי web

4. Trunk-Based Development

קיצון של GitHub Flow - branches קצרים מאוד (שעות-יום), לפעמים בכלל ישירות ל-main מאחורי feature flags.

עקרונות

• אין branches ארוכי-חיים
• שינויים קטנים, תכופים
• שימוש ב-feature flags לכיבוי פיצ'רים שלא מוכנים
• CI חזק שמוודא ש-main תמיד יציב

מתי מתאים?

• צוותים עם תרבות CI/CD בוגרת
• צוותים גדולים שצריכים להימנע מקונפליקטים גדולים

איך לבחור?

קונבנציות שמות branches

לא משנה איזה workflow בחרת - השמות צריכים להיות מובנים:

feature/user-profile
feature/checkout-flow
bugfix/header-alignment
bugfix/login-error-message
hotfix/security-vulnerability
release/v2.0
experiment/new-architecture
chore/update-deps

הקידומת מסבירה מיד מהו ה-branch. השם אחריה ברור ותמציתי.