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

1. מתי כדאי לעשות rebase על main

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

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

(מה זה "להפעיל" קומיט בענף אחר? נניח שקומיט הוסיף 2 שורות לסוף קובץ readme.txt אז להפעיל את הקומיט זה לכתוב את אותן שתי שורות לקובץ readme.txt בענף האחר).

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

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

2. מתי אעדיף למזג את main לענף שלי

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

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

לכן העצה שלי, בענף ארוך עם היסטוריה משמעותית, במיוחד כזה שמתעדכן שוב ושוב יהיה יותר נוח לעדכן באמצעות merge מהענף הראשי מאשר לחזור ולעשות rebase על הענף הראשי.