שחזור אחרי git reset --hard עם reflog
הקטעים מתארים מקרים שונים, לא סקריפט אחד. בחרו את המקרה המתאים והחליפו שמות ענפים, נתיבים ו-VERIFIED_COMMIT לפני השימוש. פקודות ביטול שייכות רק לפעולה הפעילה המתאימה; אין לבצע את שני החלופות.
התשובה הקצרה
אחרי git reset --hard, מצאו את ה-commit הקודם ב-reflog, בדקו אותו וצרו ענף הצלה. אובייקט ה-commit חייב עדיין להישמר.
הדוגמה והתנאים
המסלול הזה משחזר עבודה שנשמרה ב-commit. ה-reflog אינו שומר עריכות שהיו רק בתיקיית העבודה ולא נשמרו.
בדיקת המצב לפני שינוי
עצרו בינתיים reset, rebase ומעברים נוספים בין ענפים. קראו git reflog ובדקו את התוכן עם git show לפני הזזת הפניה.
git status --short
git reflog --date=iso
git show VERIFIED_COMMITשמירת הפניה או checkout נפרד
צרו rescue/lost-work על VERIFIED_COMMIT. כך נותנים ל-commit הפניה בלי לשנות את הענף הנוכחי או לדרוס את קובצי העבודה.
git branch rescue/lost-work VERIFIED_COMMIT
git log -5 --oneline rescue/lost-workהמסלול הראשון
בדקו את ההיסטוריה ואת ה-patch של הענף ששוחזר. אפשר לבחון אותו ב-checkout אחר או לשלב במכוון את השינויים הדרושים.
בחירה מכוונת בתוצאה אחרת
reset ישיר ל-commit המשוחזר משנה שוב את הענף, האינדקס והקבצים. שמרו תחילה שינויים נוכחיים והפניית הצלה.
מגבלות וחריגים
HEAD@{1} מציין מיקום ב-reflog, לא בהכרח את ה-commit הנכון. ORIG_HEAD עשוי להכיל את הקצה הקודם, אך פעולות אחרות יכולות להחליף אותו.
התנגשויות וניקוי
תפוגת ה-reflog וניקוי אובייקטים הם מנגנונים נפרדים שניתנים להגדרה. רשומה ישנה לא יכולה ליצור מחדש אובייקט שנמחק.
אימות התוצאה
בדקו את ה-commit, הקבצים וההיסטוריה של ענף ההצלה. הריצו בדיקות מתאימות לפני שילוב השינויים.
git show --stat rescue/lost-work
git status --shortשאלות נפוצות
git revert יוצר commit הפוך ולא מחזיר את הענף למיקום שלפני reset. לתוכן שרק הוכנס לאינדקס, git fsck עשוי למצוא blobs, ללא הבטחת שמות או מבנה תיקיות.
בדיקת הפעולה ב-FluxGit
FluxGit מרכז תנועות reflog ונקודות שחזור ב-Safety Timeline. כשהתכונה מופעלת ומזוהים שינויים מקומיים, reset מכוסה עשוי לשמור stash בטיחות. ה-reset הרגיל במסוף שבסרטון אינו משתמש בהגנה הזו.
תיעוד Git הרשמי
ביטול git reset --hard: שחזור הקומיט שאבד
אפשר לשחזר שינוי שנשמר בקומיט לאחר git reset --hard באמצעות ה־reflog המקומי כל עוד אובייקט הקומיט נשמר. השחזור אינו מובטח לאחר תפוגת ה־reflog או ניקוי האובייקטים.
צפייה ב-YouTube — נפתח בלשונית חדשה
הוקלט במאגר בדיקה.
קריאת תמליל הקריינות
- הרצת git reset --hard, והקומיט האחרון שלך נעלם. זה קורה לכולם פעם אחת. כך משחזרים אותו, וזו הסיבה שזה עובד.
- תחילה, עבודה שנשמרה בקומיט: ניסיון חוזר של קריאת התשלום פעמיים.
- אחר כך, במסוף: git reset --hard HEAD~1.
- FluxGit מזהה זאת מיד. הענף חזר לאחור, והקומיט כבר אינו עליו.
- זו הסיבה שהוא לא אבד. ענף הוא רק תווית שמצביעה על קומיט. reset מזיז את התווית לאחור, אבל הקומיט נשאר במאגר, ו־reflog, היומן של Git, עדיין מתעד אותו. יוצרים ענף על הקומיט הזה, והוא חוזר.
- ב־FluxGit, האפשרות Recover lost work מסבירה זאת במילים פשוטות ומובילה למקום הנכון.
- Safety Timeline מציגה את פעולת ה־reset במשפט אחד. יוצרים ענף מתוך הרגע שלפני הפעולה.
- הקומיט חזר, על ענף משלו.
- עבודה שלא נשמרה בקומיט אינה ב־reflog. כשנקודות השחזור מופעלות ומזוהים שינויים מקומיים, FluxGit יכול לשמור stash בטיחותי לפני hard reset. פעולת ה־reset במסוף בדוגמה הזאת משתמשת ב־Git רגיל ועוקפת את ההגנה הזאת.
- אותו הדבר במסוף: git reflog, מוצאים את השורה שלפני פעולת ה־reset, ויוצרים ענף על הקומיט הזה.
- סיכום: reset מזיז תווית. reflog זוכר היכן היא הייתה. יוצרים ענף כדי לשמור על הקומיט. בשיעור הבא: שחזור ענף שנמחק.