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

Basic Plan

כללי אצבע לבחירת המודל:

• ­בכל פעם משחררים גרסה אחת ויחידה של המוצר/מערכת
• ­כל הלקוחות משדרגים באותו הזמן לגרסה החדשה
• ­כל הבעיות והתוספות יראו אור בגרסה הבאה

Development – נועד לעבודה על הגרסה הבאה.

• ­ ניתן לייצר מס' ענפים ע"פ חלוקה למודולים,יכולות עסקיות, צוותים וכו'.
• ­ כל ענף הוא ענף מלא של Main. הכוונה היא לא לבצע branching למס' קבצים חלקי.
• ­ בצע Merge מ- main בכל פעם שיש build מוצלח. תשאף לכל יום יומיים.
• ­ בצע Merge אל ה- Main ע"פ קריטריונים ברורים ועמידה ברמת האיכות שנקבעה

Release  – משם תשחרר את הגרסה הראשית

• ­ענף מלא של Main
• גרסת המוצר/מערכת תשוחרר מענף זה
• שינויים או תיקונים שבוצעו על Release יכולים לעלות בחזרה ל- Main. אי ן לבצע Merge מ- Main
  שכן הוא כבר עשוי להכיל שינויים של הגרסה הבאה.
• ­עבור הגרסה הבאה, יש לייצר ענף Release חדש.

Standard Plan

כללי אצבע לבחירת המודל:

• ­ יש צורך לתמוך בעדכוני גרסאות (Service Packs)
• ­ קיים צורך לפתח במקביל service pack לגרסה נוכחית ויכולות עבור הגרסה הבאה
• ­ קיים צורך להקפיא גרסה לצורך בקרה או ע"פ תקינה מסוימת

בנוסף על האמור לגבי Basic Plan:

Service Pack

• נוצר כענף של main
• ­נועד לצורך תיקון ומתן שירות לגרסה שיצאה ועלתה לאוויר
• שינויים שבוצעו ב- Service Pack יכולים לעלות ל- Main ע"י merge
• לגרסה הראשית הבאה, יש לייצר ענף Service Pack חדש.

Release

• נוצר כענף של Service Pack
• נועד לשמור על גרסה סטטית שלא משתנה
• לאחר שחרור הגרסה, הענף הופך ל- read-only
• יכולות להיות מס' גרסאות שיצאו מאותו ענף Service Pack

Advanced Plan

כללי אצבע לבחירת המודל:

• יש צורך לתמוך במקביל במספר גרסאות שונות של release, Service Packs ו- Hot Fixes.
• ­Service Packs נוצרים כענפים של Main
• Hotfix נוצר שענף של Service Pack
• ל- Service Pack יכולים להיות מס' ענפי Hotfix
• Release נוצר כענף של ה- Hotfix