עבודת צוות ללא בלבול: הבנת אסטרטגיות הסתעפות ב-Git

מבוא

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

האם יש צורך באסטרטגיות הסתעפות?

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

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

לכן יש לנו שלוש אסטרטגיות לשקול להלן. בוא נלך!

זרימת GitHub

אסטרטגיית הסתעפות זו, באופן מוזר, מועדפת ב- GitHub :) היא מגיעה עם סט כללים :

1. אסור לשבור קוד בסניף המאסטר. זה צריך להיות מוכן לפריסה בכל עת. כלומר, אסור לשים שם קוד שימנע מכם לבנות את הפרויקט ולפרוס אותו לשרת.
2. כאשר אתה מתכנן לעבוד על פונקציונליות חדשה, עליך ליצור ענף תכונה חדש המבוסס על ענף המאסטר ולתת לו שם משמעותי. הגדר את הקוד שלך באופן מקומי ודחף את השינויים שלך באופן קבוע לאותו סניף במאגר המרוחק.
3. פתחו בקשת משיכה (תוכלו לקרוא על בקשות משיכה כאן ) כאשר אתם חושבים שהעבודה מוכנה וניתן למזג אותה לתוך ענף המאסטר (או אם אינכם בטוחים, אך רוצים לקבל משוב על העבודה שנעשתה).
4. לאחר אישור התכונה החדשה בבקשת המשיכה, ניתן למזג אותה לתוך ענף המאסטר.
5. כאשר השינויים מתמזגים לסניף הראשי, יש לפרוס אותם לשרת באופן מיידי.

לפי GitHub Flow, לפני שתתחיל לעבוד על משהו חדש, בין אם זה תיקון או תכונה חדשה, אתה צריך ליצור סניף חדש המבוסס על מאסטר ולתת לו שם מתאים. לאחר מכן, מתחילה העבודה על היישום. אתה צריך כל הזמן לשלוח commits לשרת המרוחק עם אותו שם. כאשר אתה מסיק שהכל מוכן, אתה צריך ליצור בקשת משיכה לסניף המאסטר. אז לפחות אחד, או יותר טוב, שני אנשים צריכים להסתכל על הקוד הזה לפני הלחיצה על "אישור". בדרך כלל, ראש הצוות של הפרויקט ואדם שני בהחלט צריכים להסתכל. לאחר מכן תוכל להשלים את בקשת המשיכה. GitHub Flow ידוע גם בהנעת משלוח רציף (CD) בפרויקטים. הסיבה לכך היא שכאשר שינויים נכנסים לסניף הראשי, יש לפרוס אותם לשרת באופן מיידי.

GitFlow

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

• המאסטר: אף אחד לא צריך לגעת או לדחוף שום דבר לענף הזה. באסטרטגיה זו, מאסטר מייצג את הגרסה היציבה האחרונה, המשמשת בייצור (כלומר, בשרת אמיתי)
• פיתוח: ענף הפיתוח. זה יכול להיות לא יציב.

הפיתוח מתרחש באמצעות שלושה ענפי עזר זמניים :

1. ענפי תכונה - לפיתוח פונקציונליות חדשה.
2. סניפי שחרור - להכנה לקראת יציאת גרסה חדשה של הפרויקט.
3. סניפים של תיקון חם - לתיקון מהיר של באג שנמצאו על ידי משתמשים אמיתיים בשרת אמיתי.

תכונה סניפים

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

שחררו ענפים

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

סניפי תיקונים חמים

סניפי תיקונים חמים נועדו גם לשחרור גרסה חדשה לסניף המאסטר. ההבדל היחיד הוא שהשחרורים האלה לא מתוכננים. ישנם מצבים שבהם באגים נכנסים לגרסה שפורסמה ומתגלים בסביבת הייצור. קח את iOS: ברגע שגרסה חדשה יוצאת, אתה מקבל מיד שלל עדכונים עם תיקונים לבאגים שנמצאו לאחר השחרור. בהתאם לכך, עלינו לתקן במהירות באג ולשחרר גרסה חדשה. בתמונה שלנו, זה מתאים לגרסה 1.0.1. הרעיון הוא שהעבודה על פונקציונליות חדשה לא חייבת להיעצר כאשר יש צורך לתקן באג בשרת אמיתי (או כפי שאנו אומרים, "בפרוד" או "בייצור"). יש ליצור את ענף התיקון החם מהענף הראשי, מכיוון שהוא מייצג את מה שרץ כעת בייצור. ברגע שתיקון הבאגים מוכן, הוא מתמזג למאסטר, ותג חדש נוצר. בדיוק כמו הכנת ענף שחרור, גם ענף תיקון חם צריך למזג את התיקון שלו בחזרה לענף הפיתוח.

זרימת עבודה של מזלג

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

1. המאגר המקורי, אליו ימוזגו כל השינויים.
2. מאגר מזלגות. זהו עותק של המאגר המקורי, בבעלות מפתח אחר שרוצה לבצע שינויים במקור.

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

דוגמה לזרימת העבודה המתפצלת

זרימת העבודה המתפצלת מוחלת ב- GitHub כאשר יש ספרייה שבה אתה רוצה להשתמש. יש לו באג שמונע ממך להשתמש בו באופן מלא. נניח שאתה צולל מספיק עמוק לתוך הבעיה ויודע את הפתרון. באמצעות זרימת העבודה של forking, אתה יכול לתקן את הבעיה ללא זכויות לעבוד במאגר המקורי של הספרייה. כדי להתחיל, עליך לבחור מאגר כלשהו, ​​למשל, מסגרת האביב . מצא ולחץ על כפתור "מזלג" בפינה השמאלית העליונה: זה ייקח זמן מה. לאחר מכן יופיע בחשבונך האישי עותק של המאגר המקורי שיציין שמדובר במזלג: כעת תוכל לעבוד עם המאגר הזה כרגיל, להוסיף שינויים לסניף המאסטר, וכשהכל מוכן, תוכל ליצור בקשה למשוך למאגר המקורי. כדי לעשות זאת, לחץ על כפתור בקשת משיכה חדשה :

באיזו אסטרטגיה לבחור

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

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

זה כל מה שרציתי לומר על אסטרטגיות הסתעפות ב-Git. תודה על תשומת הלב :) עקבו אחרי ב-GitHub , שם אני מפרסם לעתים קרובות את היצירות שלי הכוללות טכנולוגיות וכלים שונים שבהם אני משתמש בעבודתי.