לידידי הייתה בעייה קטססטרופלית עם git לפני מספר ימים , הוא ביצע rebase היה קונפליקט בחר לבצע skip ואז abort והבין שהופ והמידע שלו נעלם מהענף עליו עבד.
התקשר אלי בשביל לנסות לראות אם אפשר להציל את המידע ונענה .
אני מאמין שבעיות כאלה יכולים לקרות לכל אדם אז כככל אני ממליץ את צורת עבודה :
לצערי ידידי לא הקשיב לי (אבל אני עובד עם PRs ! לא צריך את צורת העבודה הזאת ) וחשב כי איבד את עבודתו , בשביל להציל את המידע אנחנו משתמשים בכלי המדהים שנקרא reflog , ולדעתי כל אדם שעובד עם git חייב להכיר את הכלי הזה.
בשביל להציל את המידע אנו מפעילים git reflog ומוצאים את ה hash לפני rebase, לקחתי דוגמה מהצלה אחרת אבל בה היה מקרה דומה (גם שם יש עבודה לא נכונה כפי שרואים) :
הקומיטים שנעלמו לנו היו 606fb656349 ו 089c98cb217 בשביל להציל את הקומיט הזה מספיק לעשות :
git checkout -b sos_rescue 606fb656349 , כי לפי ההיסטוריה פה (ובבדיקה) הקומיטים נמצאים אחד אחרי השני.
ענף הפיתוח החדש sos_rescue יכיל את מה ש"נעלם" מההיסטוריה שלנו.
אותה הבעייה יכולה להתקיים גם עם git rebase --abort , שם המצב מפחיד בהרבה כי בדר"כ לא מצפים ש abort יוביל לאיבוד מידע ולא חזרה להתחלה.
לדעתי כל אדם שמתחיל לעבוד עם git חייב לעבור על כל הפעולות תחת docs, יש שם דברים שבהתחלה יכולים לחשוב שזה לא חשוב או לא תשתמשו בהם , אבל כל אחת מהסעיפים שם תציל אותכם אחרי זה.
התקשר אלי בשביל לנסות לראות אם אפשר להציל את המידע ונענה .
אני מאמין שבעיות כאלה יכולים לקרות לכל אדם אז כככל אני ממליץ את צורת עבודה :
- מבצעים pull על ה master
- עוברים לענף פיתוח git checkout -b something_usefull ועודבים בתוכו
- חוזרים לענף ה master מבצעים pull
- חוזרים לענף הפיתוח ומגבים את ענף הפיתוח :
git checkout -b something_usefull_backup_rebasing - מבצעים rebase master
- חוזרים ל master ומבצעים git merge something_usefull_backup_rebasing
- מוחקים את ענף הפיתוח והגיבויי:
git rebase -D something_usefull_backup_rebasing
git rebase -D something_usefull
לצערי ידידי לא הקשיב לי (אבל אני עובד עם PRs ! לא צריך את צורת העבודה הזאת ) וחשב כי איבד את עבודתו , בשביל להציל את המידע אנחנו משתמשים בכלי המדהים שנקרא reflog , ולדעתי כל אדם שעובד עם git חייב להכיר את הכלי הזה.
בשביל להציל את המידע אנו מפעילים git reflog ומוצאים את ה hash לפני rebase, לקחתי דוגמה מהצלה אחרת אבל בה היה מקרה דומה (גם שם יש עבודה לא נכונה כפי שרואים) :
7d8e22cc631 (HEAD -> nieuwe_maas, origin/master, origin/HEAD) HEAD@{0}: rebase (skip) (finish): returning to refs/heads/nieuwe_maas
7d8e22cc631 (HEAD -> nieuwe_maas, origin/master, origin/HEAD) HEAD@{1}: pull origin master (start): checkout 7d8e22cc63117d3667c3490a9910850c2690e6d3
606fb656349 HEAD@{2}: rebase (abort): updating HEAD
7d8e22cc631 (HEAD -> nieuwe_maas, origin/master, origin/HEAD) HEAD@{3}: pull origin master (start): checkout 7d8e22cc63117d3667c3490a9910850c2690e6d3
606fb656349 HEAD@{4}: commit: Correct IPv6 route handeling
089c98cb217 HEAD@{5}: checkout: moving from rotterdam to nieuwe_maas
ee8d88108d3 (rotterdam) HEAD@{6}: rebase (skip) (finish): returning to refs/heads/rotterdam
ee8d88108d3 (rotterdam) HEAD@{7}: pull origin master (start): checkout ee8d88108d3964731d423d2b7ad36ae8860f6970
089c98cb217 HEAD@{8}: rebase (abort): updating HEAD
ee8d88108d3 (rotterdam) HEAD@{9}: pull origin master (start): checkout ee8d88108d3964731d423d2b7ad36ae8860f6970
089c98cb217 HEAD@{10}: commit: BUGFIX: null derefernece
הקומיטים שנעלמו לנו היו 606fb656349 ו 089c98cb217 בשביל להציל את הקומיט הזה מספיק לעשות :
git checkout -b sos_rescue 606fb656349 , כי לפי ההיסטוריה פה (ובבדיקה) הקומיטים נמצאים אחד אחרי השני.
ענף הפיתוח החדש sos_rescue יכיל את מה ש"נעלם" מההיסטוריה שלנו.
אותה הבעייה יכולה להתקיים גם עם git rebase --abort , שם המצב מפחיד בהרבה כי בדר"כ לא מצפים ש abort יוביל לאיבוד מידע ולא חזרה להתחלה.
לדעתי כל אדם שמתחיל לעבוד עם git חייב לעבור על כל הפעולות תחת docs, יש שם דברים שבהתחלה יכולים לחשוב שזה לא חשוב או לא תשתמשו בהם , אבל כל אחת מהסעיפים שם תציל אותכם אחרי זה.
לצערי גם git reflog הוא לא חסר מבעיות , ולמעשה אחת הבעיות המובנות שאני סובל מהם קשות זה ש reflog שומר רק שלושה חודשים ואני מוצא את עצמי מגבה את תיקיית ה .git אחת לחודש כי כל פתרונות הגיבוי שאני מכיר לוקים בחסר אבל זה כבר סיפור אחר.
אין תגובות:
הוסף רשומת תגובה