מדריך ל-Git Interactive Rebase, עם דוגמאות מעשיות

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

למה ריבסי התייחדות קונבנציונאלית צריכה להיות חלק מאביזרי העבודה של כל מפתח

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

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

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

מה ריבסי התייחדות קונבנציונאלית יכולה לעשות עבורך

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

• לערוך הודעת גרסה ישנה
• למחוק גרסה
• למעורבב/לשלב מספר גרסאות
• לשנות סדר הגרסאות
• לתקן ישנות התאריכים
• להפריד/לפתוח מחדש ישנות התאריכים לעריכה

מתי להשתמש ב-Interactive Rebase (ומתי בלבד לא!)

כמו כמה כלים גיט אחרים, Interactive Rebase "משנה את ההיסטוריה". זה אומר שכשאתה משנה סדרת תאריכים באמצעות Interactive Rebase, החלק הזה מההיסטוריה שלך יהיה משנה: ראשי המילים SHA-1 של התאריך ישתנו. הם בדיוק כמו עצמים חדשים של התאריך, אם כן.

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

המנגנון הבסיסי של פעולת Interactive Rebase

למרות שיש כל כך הרבה דברים שונים שאפשר להשתמש ב-Interactive Rebase, הנהל העבודה הבסיסי תמיד זהה. ברגע שבטחת בבסיסיות זו, Interactive Rebase תאבד את אוויר ה"מיסתורין המורכב" ותהפוך לפריט בעל ערך ונגישות בכלי שלך.

שלב 1: איפה כדאי להתחיל את הפעילות?

השאלה הראשונה שעליך לענות עליה היא: "איזה חלק מההיסטוריה של התאריכים שלי אני רוצה לשנות?" זה אומר לך איפה כדאי להתחיל את פעילות ה-Interactive Rebase שלך. בואו נעשה דוגמה מעשית ונאמר שאנו רוצים לערוך הודעת תאריך ישנה (מה שנעשה למעשה בפועל בעוד רגע).

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

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

שלב 2: התחלת המסע האמיתי!

התחלת המסע האמיתי היא די פשוטה:

$ git rebase -i HEAD~3

אנו משתמשים בפקודה git rebase עם התג -i (כדי לציין שאכן אנו רוצים שזה יהיה "תלוי") ומספקים את הממפעל הבסיסי (שהגענו אליו בשלב הראשון לעיל). בדוגמה זו, השתמשתי בHEAD~3 כדי לציין את הממפעל שהוא "3 מאחורי הממפעל HEAD". או שיכולתי גם לספק ספרת מפתח SHA-1 ספציפית.

שלב 3: אמירת דברים לגיט מה אתה רוצה לעשות

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

יש שני דברים חשובים לזכור בשלב זה:

1. הממפעלים מופיעים בסדר הפוך! הממפעל העדכני ביותר, שהיינו מצפים לראות אותו בראש, יופיע בתחתית הרשימה. אל תדאגו: מאגר הגיט שלכם בריא כמו פיתה! 🥳 זכרו שאנו נמצאים בתהליך ביצוע מיזוג תגובה תלוי, וזה דורש מגיט להחיל את הממפעלים מהישנים לחדשים בסוף הפעולה.
2. אל תעשה את השינויים האמיתיים בחלון העורך הזה! למרות שאולי איתת לעשות זאת ולשנות את ההודעה של הזימון בחלון העורך הזה (אחרי הכול, זה מה שאנו באמת רוצים לעשות…), אתה צריך להפוך סבלנות. כאן, אנו רק הולכים להגיד ל-Git מה אנו רוצים לעשות – אך לא לבצע את השינוי האמיתי. אני אדגים את הנקודה הזו בפועל בקרוב!

עם הסקירה התיאורטית הזו מוכרחה, בואו נצלול לכמה מקרים מעשיים יחד!

עריכת הודעת זימון ישנה

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

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

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

למשל בדוגמא שלנו, נניח שהיינו רוצים לערוך את ההודעה של הזימון שכרגע נקראת "לייעל את מבנה התבניות באינדקס…"

שלבנו הראשון הוא לקבוע את הכפיסת הבסיס להתחלת סשן המיקום האינטראקטיבי הזה. מכיוון שעלינו לחזור לפחות להורה של הכפיסת "תפוח הרע" שלנו, אנו מתחילים את הסשן שלנו ב-HEAD~3 (שלוש כפיסות אחורה מהכפיסה הראשית, שהיא הכפיסה שכותרתה "שינוי כותרים…"):

$ git rebase -i HEAD~3

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

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

באופן מעשי, כל המילים המתאימות לפעולה מתועדות בתחתית החלון הזה – כך שאין צורך לזכור משהו בלבד!

לאחר שהחלפת את מילת הפעולה הסטנדרטית pick (מה שאומר "קח את הכפיסה כפי שהיא") עם מילת הפעולה המועדפת עליך, אתה יכול פשוט לשמור ולסגור את החלון.

לאחר מכן, חלון עורך חדש ייפתח שמכיל את מסר הכפיסה הנוכחי. סוף סוף, אנו רשאים לעשות את מה שהתכווננו לעשות מלכתחילה: לערוך את מסר הכפיסה הישן הזה!

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

מחיקת כפיסה לא רצויה

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

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

נתחיל בקביעת הקומיט הבסיסי עבור מסע המחברת האינטראקטיבי שלנו. מכיוון שאנו צריכים להתחיל לפחות בהורה של הקומיט הרע, אנו משתמשים בקומיט "להכניס מבנה מרקם מושלם…" כבסיס שלנו:

$ git rebase -i 6bcf266b

שים לב שהפעם, השתמשתי בסיסמה SHA-1 קונקרטית בפקודת git rebase -i. במקום סימן הקומיט, כמובן, יכולתי להשתמש בHEAD~2 כדי לכתוב את הקומיט ההוא.

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

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

עם זאת שים לב שלאחר ששמרת וסגרת את חלון העורך, הקומיט ימחק מהיסטוריה של המאגר שלך!

שילוב קומיטים מרובים לתוך אחד

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

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

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

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

בואו נעבור על דוגמה מעשית יחד וניקח את המצב המתואר למטה כמצב ההתחלתי שלנו.

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

$ git rebase -i HEAD~3

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

I already mentioned that we’re going to use the squash action keyword in this case. There’s an important thing to know about how squash works: the line you mark up with the keyword will be combined with the line directly above! This explains why I marked line 2 with the squash keyword in our example.

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

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

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

מימוש כוח הרבייה המסונכרנת

I hope you agree that Git’s interactive rebase tools can be very valuable! As developers, it’s important for us to strive for a clean and clear commit history. It’s a crucial ingredient in keeping a codebase healthy and easy to understand (both for your teammates, and yourself, after some time has passed).

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

תהנה!

שאלות שולחן פיתחון (FAQs) על הרבייה מסונכרנת של Git