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

מבוא

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

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

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

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

לכן, להלן שלוש אסטרטגיות. ללכת!

אסטרטגיית זרימת GitHub

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

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

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

אסטרטגיית GitFlow

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

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

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

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

מאפיינים סניפים

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

שחררו ענפים

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

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

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

אסטרטגיית זרימת העבודה של Forking

כחלק מאסטרטגיית Forking Workflow, הפיתוח מתבצע בצורה כזו שיש שני מאגרים:

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

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

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

ה-Forking Flow משמש ב-GitHub כאשר יש ספריה כלשהי שאתה רוצה להשתמש בה. יש לו פגם שמונע ממנו להשתמש במלואו. נניח שהתעמקת מספיק בבעיה ויודעת את הפתרון. באמצעות אסטרטגיית Forking Workflow, אתה יכול לפתור בעיה זו מבלי להעניק זכויות לעבוד במאגר הספרייה המקורי. כדי להתחיל, עליך לבחור מאגר, למשל, ליבת Spring Framework מצא את כפתור המזלג בפינה הימנית העליונה ולחץ עליו: זה ייקח זמן מה, ולאחר מכן עותק של המאגר המקורי הזה יופיע אצלך. חשבון אישי, שיעיד שמדובר במזלג: לאחר מכן תוכלו לעבוד עם המאגר הזה כרגיל, להוסיף שינויים לסניף המאסטר וכשהכל מוכן, ליצור Pull-Request למאגר המקורי. כדי לעשות זאת, לחץ על כפתור בקשת משיכה חדשה :

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

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

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

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

קישורים שימושיים

• זרימת GitHub: הדרך הטובה ביותר להשתמש ב-Git וב-GitHub
• משוך בקשות ב-GitHub או איך אני יכול לבצע שינויים בפרויקט של מישהו אחר
• GitHub: אודות Pull-Requests
• אינטגרציה מתמשכת, אספקה ​​ופריסה מובחנת
• יסודות Git: עבודה עם תגיות
• Habr: מודל הסתעפות מוצלח עבור Git