Git rebase וההבדל בינו לבין git merge

על git rebase וההבדל בינו לבין git merge
Git logo

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

הצגה של תהליך pull
הצגה של תהליך pull

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

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

דוגמה ל git rebase
דוגמה לאיך rebase עובד.

כלומר, ה-rebase עושה רולבק עד לנקודת הזמן שבו היה הפיצול. לוקח את הקומיט הראשון לפי תאריך ושם אותו. לוקח את הקומיט השני ושם אותו על הראשון וכך הלאה עד שמסיימים. אם יש קונפליקט, התהליך עוצר ונדרש מהמשתמש ליישב את הקונפליקט ורק אז להמשיך בתהליך. רק אחרי שכל הקומיטים – המרוחקים והנוכחיים הסתיימו, רק אז ה-rebase מושלם ואפשר לפתוח Pull request.

מבחינה טכנית עושים את זה ככה:

git rebase origin develop

ובמידה ויש קונפליקט, יש ליישב אותו ואז:

git rebase --continue

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

git rebase --abort

אחרי שהכל תקין, עושים קומיט עם כל השינויים ואז פותחים pull request.

מתי משתמשים ב-rebase?

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

מתי לא משתמשים ב-rebase?

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

במאמר הבא אנחנו נראה דוגמה בפועל של שימוש בגיט בקוד אמיתי. stay tuned!

פוסטים נוספים שכדאי לקרוא

תמונה של עציץ, רספברי פיי ורמקול
רספברי פיי

לגרום לעציץ שלכם לדבר

כך תשתמשו ברספברי פיי, חיישנים וגם בינה מלאכותית שמותקנת על הרספברי פיי (כן) כדי ליצור… עציץ המדבר.

פתרונות ומאמרים על פיתוח אינטרנט

יישום של nonce על מנת להגן מפני התקפות injection

בפוסט הקודם הסברתי על hash עם CSP על משאבי inline – שזה נחמד ומעולה אבל פחות ישים בעולם האמיתי שבו בדרך כלל התוכן ה-inline (בין

פתרונות ומאמרים על פיתוח אינטרנט

SSG עם next

אחרי שלמדנו במאמר הקודם מה זה SSR והבנו שלא מדובר בקליע כסף שפותר את כל הבעיות שלנו, נלמד על SSG שיכול להקל על כמה מהבעיות של SSR.

גלילה לראש העמוד