Commit בענף הלא נכון: העברת השינוי בבטחה עם Git

הדוגמה והתנאים

הדוגמה מתחילה במקרה מוגדר: commit רגיל אחד, שאינו merge, בקצה main, השייך לענף feature/fix שכבר קיים. תיקיית העבודה נקייה. החליפו את השמות בשמות שלכם. כשיש כמה commits, merge או עבודה מאוחרת, זהו את הטווח המדויק לפני שימוש ב-reset שבדוגמה.

בדיקת המצב לפני שינוי

קראו מצב, ענף נוכחי וגרף אחרון. בדקו קבצים ושינוי, לא רק כותרת: commit עלול לכלול כמה משימות. שמרו מזהה מלא ב-SCHOOL_MISTAKE כדי לזהות את המקור גם אחרי מעבר ענף. בררו מי כבר קיבל את ההיסטוריה לפני תיקון main.

git status --short
git branch --show-current
git log -5 --oneline --decorate
git show --stat HEAD
SCHOOL_MISTAKE=$(git rev-parse HEAD)

שמירת הפניה או checkout נפרד

ענף חילוץ משאיר את עצם ה-commit נגיש, אך אינו מעתיק שינויים שלא בוצע להם commit. שמרו ואמתו אותם בנפרד באמצעות commit מכוון, stash שנבדק או עותק חיצוני. stash עם -u כולל קבצים לא מנוטרים, אך לא קבצים מוחרגים. reflog אינו שומר אוטומטית את תוכנם הלא שמור.

git branch rescue/wrong-branch "$SCHOOL_MISTAKE"
git show --stat rescue/wrong-branch

המסלול הראשון

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

git switch feature/fix
git cherry-pick "$SCHOOL_MISTAKE"
git show --stat HEAD

בחירה מכוונת בתוצאה אחרת

רק בקצה פרטי, חזרו ל-main ובדקו ש-HEAD עדיין שווה SCHOOL_MISTAKE. בתיקייה נקייה ועם ענף חילוץ שמור, reset להורה מסיר את ה-commit מ-main. hard reset מחליף גם קבצים מנוטרים. אם main התקדם או ה-commit שותף, הרצף הזה כבר אינו מתאים.

git switch main
git status --short
git rev-parse HEAD
git reset --hard "${SCHOOL_MISTAKE}^"

מגבלות וחריגים

בענף משותף העדיפו revert רגיל. הוא מוסיף commit הפוך בלי למחוק את ההיסטוריה שאחרים קיבלו. בדקו בנפרד את ה-cherry-pick ביעד ואת ה-revert במקור. תיאמו שילובים מאוחרים עם הצוות; זו אינה הוראה ל-force push אוטומטי.

git switch main
git revert "$SCHOOL_MISTAKE"

התנגשויות וניקוי

cherry-pick עשוי לעצור בהתנגשות. קראו status, פתרו והכינו את הקבצים הנכונים והמשיכו; השתמשו ב-cherry-pick --abort לבחירה שגויה. ל-revert פקודות המשך וביטול משלו. ביטול פעולה פעילה אינו גיבוי כללי לשינויים שנעשו מחוצה לה.

git status
git cherry-pick --abort

git revert --abort

אימות התוצאה

הגרף הסופי צריך להראות שינוי ב-feature/fix ותיקון שנבחר ב-main. השוו שני patches ומצב בכל checkout. השאירו rescue/wrong-branch עד תום הבדיקה. מצב נקי אינו מוכיח שהיישום עדיין נכון; בדקו גם את ההתנהגות שהושפעה.

git log -6 --oneline --decorate --all
git show --stat feature/fix
git status --short

שאלות נפוצות

כמה commits? בדקו סדר, תלות וטווח. reset --soft מזיז הפניה ושומר אינדקס וקבצים, אך אינו מעביר לבדו commit לענף אחר. כבר ביצעתם push? התחילו ממקרה revert של היסטוריה משותפת ותאמו במפורש כל שכתוב חריג.

בדיקת הפעולה ב-FluxGit

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

תיעוד Git הרשמי

• git-cherry-pick
• git-reset
• git-revert