כולם יודעים שבעבודה עם גיט צריך לפתוח Branch חדש לכל פיצ'ר שעובדים עליו, כשהקוד מוכן לייצר PR ואחרי בדיקות ו Code Review למזג לענף הראשי. ובכל זאת צוותים שונים נבדלים ביניהם בזמנים שכל סיבוב כזה לוקח - במיוחד בפיצ'רים גדולים.

גישה אחת, שנקראת בדרך כלל Git flow, מעודדת יצירת Branch עבור הפיצ'ר כולו ולמזג אותו "בסוף", כשהכל מוכן. התוצאה של גישה כזאת היא שבראנצ'ים יכולים לחיות לאורך זמן לפני שימוזגו לתוך הענף הראשי, ופעם בכמה זמן המתכנת שעובד על אותו בראנץ' צריך לעשות ריבייס כדי לקבל את השינויים המרכזיים מהענף הראשי. בצורה כזאת אנחנו לא צריכים להתמודד עם עבודה של מתכנתים אחרים עד שהיא הופכת לעובדה מוגמרת.

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

מעניין לשים לב להשפעה של כל גישה על התקשורת בתוך הצוות: בגישת Git Flow מתכנתים עובדים פחות או יותר עצמאית, יש פחות נקודות סינכרון (רק כשרוצים למזג) וכל אחד אחראי על הקונפליקטים בקוד שלו; בגישת TBD הסינכרון הוא יומי, וכולם כל היום צריכים להתמודד עם שינויים של אחרים. גישה כזאת יכולה לעבוד רק בצוותים מגובשים, הרבה פעמים שעובדים באותו אזור זמן, ועם מתכנתים ששמחים להסתכל ולפתור בעיות גם בקוד שאחרים כתבו.

היבט נוסף להשוואה הוא מבנה הלוג וההיסטוריה - בגישת Git Flow יש לנו הזדמנות לפני המיזוג לערוך את הבראנץ', למזג קומיטים ולתקן הודעות קומיט כדי שהכל יראה יפה בסוף. ב TBD כמעט כל פיצ'ר מעניין מתפרש על פני מספר בראנצ'ים - כי אנחנו שוברים את הפיצ'ר לחלקים קטנים וכל חלק ייכתב בתור בראנץ' וימוזג בסוף היום - ולכן קשה יותר לראות במקום אחד את רצף הקומיטים שקשור לפיצ'ר מסוים.

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

מכירים גישות נוספות? איך עובדים אצלכם בצוות? ואיזה גישה אתם מעדיפים?