כמפתח, רבים מאיתנו צריכים לבחור בין מיזוג לריבייס. עם כל הפניות שאנחנו מקבלים מהאינטרנט, כולם מאמינים "אל תשתמש ב- Rebase, זה עלול לגרום לבעיות חמורות." כאן אסביר מה הם מיזוג וביסוס חוזר, מדוע כדאי (ולא כדאי) להשתמש בהם וכיצד לעשות זאת.
Git Merge ו- Git Rebase משרתים את אותה מטרה. הם נועדו לשלב שינויים ממספר ענפים לאחד. למרות שהמטרה הסופית זהה, שתי השיטות הללו משיגות זאת בדרכים שונות, ומועיל לדעת מה ההבדל ככל שאתה הופך למפתח תוכנה טוב יותר.
שאלה זו פיצלה את קהילת גיט. יש הסבורים שתמיד צריך לבסס מחדש ואחרים שתמיד צריך להתמזג. לכל צד יש יתרונות משכנעים.
Git Merge
מיזוג הוא נוהג נפוץ עבור מפתחים המשתמשים במערכות בקרת גרסאות. בין אם נוצרים סניפים לצורך בדיקה, תיקוני באגים או סיבות אחרות, מיזוג מחייב שינויים למיקום אחר. ליתר דיוק, מיזוג לוקח את התוכן של ענף מקור ומשלב אותם עם ענף יעד. בתהליך זה משתנה רק ענף היעד. היסטוריית ענף המקור נותרה זהה.
יתרונות
- פשוט ומוכר
- שומר על היסטוריה מלאה וסדר כרונולוגי
- שומר על הקשר הסניף
חסרונות
- היסטוריית ההתחייבות יכולה להיות מזוהמת על ידי הרבה התחייבויות מיזוג
- ניפוי באגים באמצעות
git bisectיכול להיות קשה יותר
איך לעשות את זה
מיזג את ענף המאסטר לענף התכונות באמצעות הפקודות checkoutו- merge.
$ git checkout feature $ git merge master (or) $ git merge master featureפעולה זו תיצור " מיזוג התחייבות " חדש בענף התכונות המחזיק בהיסטוריה של שני הסניפים.
גיט ריבייס
Rebase היא דרך נוספת לשילוב שינויים מענף אחד למשנהו. Rebase דוחס את כל השינויים ל"תיקון "יחיד. ואז הוא משלב את התיקון לענף היעד.
בניגוד למיזוג, מאגד מחדש משטח את ההיסטוריה מכיוון שהוא מעביר את העבודה שהושלמה מענף אחד למשנהו. בתהליך, היסטוריה לא רצויה מסולקת.
Rebases הם הדרך בה השינויים צריכים לעבור ממעלה ההיררכיה כלפי מטה, ומיזוגים הם איך שהם זורמים חזרה כלפי מעלה
יתרונות
- מייעל היסטוריה שעלולה להיות מורכבת
- קל לבצע התחייבות יחידה (למשל לבטל אותם)
- נמנע ממיזוג לבצע "רעש" ברבדים עמוסים עם ענפים תפוסים
- מנקה את התחייבויות הביניים על ידי ביצוע התחייבות אחת, שיכולה להועיל לצוותי DevOps
חסרונות
- ריסוק הפיצ'ר לקומץ התחייבויות יכול להסתיר את ההקשר
- שינוי מאגר של מאגרים ציבוריים עלול להיות מסוכן בעבודה כצוות
- זה יותר עבודה: שימוש ב- rebase כדי לעדכן תמיד את ענף התכונות שלך
- שינוי בסיסי עם ענפים מרוחקים מחייב אותך לכפות דחיפה. הבעיה הגדולה ביותר שאנשים מתמודדים איתם היא שהם מכריחים דחיפה אך לא הגדירו את ברירת המחדל של git push. התוצאה היא עדכונים לכל הסניפים בעלי אותו השם, באופן מקומי ומרחוק, וזה נורא להתמודד.
איך לעשות את זה
העבר מחדש את ענף התכונות לענף המאסטר באמצעות הפקודות הבאות.
$ git checkout feature $ git rebase masterזה מעביר את כל ענף התכונות על גבי סניף המאסטר. היא עושה זאת על ידי כתיבה מחדש של היסטוריית הפרויקט על ידי יצירת התחייבויות חדשות עבור כל התחייבות בענף המקורי (התכונה).
החלפה מחדש אינטראקטיבית
זה מאפשר לשנות את ההתחייבויות כאשר הן עוברות לסניף החדש. זה חזק יותר מאשר rebase אוטומטי, מכיוון שהוא מציע שליטה מלאה בהיסטוריית ההתחייבות של הסניף. בדרך כלל זה משמש לניקוי היסטוריה מבולגנת לפני מיזוג ענף תכונות למאסטר.
$ git checkout feature $ git rebase -i masterפעולה זו תפתח את העורך על ידי רשימת כל ההתחייבויות שעומדות לעבור.
pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3זה מגדיר בדיוק איך ייראה הסניף לאחר ביצוע ה- rebase. על ידי הזמנה מחדש של הישויות, תוכלו לגרום להיסטוריה להיראות כמו כל מה שתרצו. לדוגמה, אתה יכול להשתמש בפקודות כמו fixup, squash, editוכו ', במקום pick.
באיזה מהם להשתמש
אז מה הכי טוב? על מה ממליצים המומחים?
קשה להכליל ולהחליט על זה או אחר, מכיוון שכל קבוצה שונה. אבל אנחנו צריכים להתחיל איפשהו.
צוותים צריכים לשקול מספר שאלות בעת קביעת מדיניות Git rebase לעומת מיזוג. כי כפי שמתברר, אסטרטגיית זרימת עבודה אחת אינה טובה יותר מהאחרת. זה תלוי בצוות שלך.
שקול את רמת ההתחברות והמיומנות של Git ברחבי הארגון שלך. קבע את המידה בה אתה מעריך את פשטות ההתחלפות לעומת עקיבות ההיסטוריה של המיזוג.
לבסוף, יש לשקול החלטות על מיזוג ושינוי בסיס מחדש בהקשר של אסטרטגיית הסתעפות ברורה ( עיין במאמר זה כדי להבין יותר אסטרטגיית הסתעפות). אסטרטגיית הסתעפות מוצלחת מתוכננת סביב ארגון הצוותים שלך.
על מה אני ממליץ?
ככל שהצוות יגדל, יהיה קשה לנהל או לעקוב אחר שינויים בפיתוח באמצעות מדיניות של מיזוג תמיד. להיות בעל היסטוריית התחייבות נקייה ומובנת , שימוש ב- Rebase הוא סביר ויעיל.
על ידי בחינת הנסיבות וההנחיות הבאות, תוכל להפיק את המיטב מ- Rebase:
- אתה מתפתח באופן מקומי: אם לא שיתפת את עבודתך עם אף אחד אחר. בשלב זה, עליך להעדיף החלפה מחדש על בסיס מיזוג כדי לשמור על ההיסטוריה שלך מסודרת. אם יש לך את המזלג האישי שלך של המאגר וזה לא משותף עם מפתחים אחרים, אתה בטוח לבסיס מחדש גם לאחר שדחפת לסניף שלך.
- הקוד שלך מוכן לבדיקה: יצרת בקשת משיכה. אחרים בודקים את עבודתך ועלולים להביא אותה למזלג שלהם לבדיקה מקומית. בשלב זה, אתה לא צריך לבסס מחדש את העבודה שלך. עליך ליצור התחייבויות 'עיבוד חוזר' ולעדכן את ענף התכונות שלך. זה עוזר למעקב אחר בקשת המשיכה ומונע שבירת היסטוריה בשוגג.
- הסקירה נעשית ומוכנה לשילוב בענף היעד. מזל טוב! אתה עומד למחוק את ענף התכונות שלך. בהתחשב בכך שמפתחים אחרים לא ישיגו מיזוגים בשינויים אלה מנקודה זו ואילך, זו ההזדמנות שלך לטהר את ההיסטוריה שלך. בשלב זה, אתה יכול לשכתב את ההיסטוריה ולקפל את ההתחייבויות המקוריות וה- 'עיבוד חוזר' ו'מיזוג 'המעורערים למערך קטן של התחייבויות ממוקדות. יצירת מיזוג מפורש עבור התחייבויות אלה היא אופציונלית, אך יש לה ערך. זה מתעד מתי התכונה סיימה את לימודיה.
סיכום
אני מקווה שהסבר זה נתן כמה תובנות על המיזוג Git ו Git rebase. תמיד ניתן להתווכח על אסטרטגיית מיזוג לעומת ריבייס. אבל אולי מאמר זה יעזור להפיג את הספקות שלך ויאפשר לך לאמץ גישה שעובדת עבור הצוות שלך.
אני מצפה לכתוב על תהליכי עבודה של Git ומושגים של גיט . האם להגיב על הנושאים שאתה רוצה שאכתוב עליהם בהמשך. לחיים!
code = coffee + developer
בית ספר לקידוד למפתחי תוכנה
