איך נותנים לסוכן קוד לפתור merge conflicts בלי לאבד את כוונת השינוי?
בפוסט שלי על האחריות לשינוי כתבתי שכבר בנינו בצוות אוטומציות לפתיחת PR, ל-self review, לתיקון קונפליקטים ולעבודה על הערות review. הדגש שלי עבר להסבר הבעיה, ההחלטה והסיכונים. המדריך הזה מציע דרך להפוך את הדגש הזה לתהליך שאפשר לחזור עליו.
בקצרה
מוסרים לסוכן את מטרת שני השינויים, שומרים נקודת חזרה ובודקים את התוצאה המשולבת. פתרון קונפליקט אינו רק הסרת סימנים מהקובץ. צריך לוודא שההתנהגות שכל צד התכוון לשמור עדיין קיימת.
מזהים מה באמת מתנגש
קונפליקט אומר ש-Git לא הצליח לחבר חלק מהשינויים אוטומטית. הוא אינו קובע איזו התנהגות נכונה. שני צדדים יכולים להיות נכונים בנפרד ועדיין לדרוש החלטה חדשה כשמחברים אותם.
המחשה: ענף אחד מוסיף בדיקת הרשאה לפני שמירה. ענף אחר משנה את השמירה כדי למנוע פעולה כפולה. הבחירה בגרסה של צד אחד יכולה למחוק את ההגנה של האחר גם אם הקוד מתקמפל. זו דוגמה סינתטית, לא תקלה שתועדה אצל לקוח.
שומרים מצב שאפשר להסביר ולשחזר
לפני שמתחילים, בדקו באיזה ענף נמצאים, אילו קבצים השתנו ומה עדיין לא נשמר. בתיעוד Git יש אזהרה מפני merge עם שינויים מקומיים משמעותיים שלא נשמרו. הפקודה git merge --abort מנסה להחזיר את המצב שקדם למיזוג, אך אינה מבטיחה לשחזר שינויים מקומיים כאלה בכל מצב.
בקשו מהסוכן לזהות את המצב ולדווח עליו לפני פעולה. אל תתנו לו למחוק עבודה מקומית כדי "לנקות" את סביבת העבודה. commit מקומי או שמירה אחרת צריכים לשמר את החומר, בהתאם לנוהל של הצוות. סודות אינם חומר שמכניסים ל-commit.
נותנים שתי כוונות, לא רק שני קבצים
צרפו את הסיבה לשינוי בכל צד, קישורים לדיון או תיאור ה-PR והבדיקות שמייצגות את ההתנהגות. קראו עם הסוכן גם את הקוד הסמוך. שינוי בשם משתנה יכול להסתיר שינוי בחוזה של פונקציה.
בקשה מוצעת לסוכן:
הסבר את כוונת כל צד ואת ההתנגשות. הצע תוצאה שמשמרת את הדרישות של שני הצדדים. אם הן סותרות, עצור עם שאלה ממוקדת. תקן רק את הקונפליקט שסוכם. הראה diff של הפתרון ותוצאות בדיקה בפועל. אל תבצע push או merge מרוחק בלי הוראה נפרדת.
מגדירים כאן גבול חשוב: הסוכן יכול להכין תיקון מקומי, אבל החלטת מוצר או הרשאה חדשה דורשת הכרעה של מי שמחזיק אותה.
נזהרים מבחירה אוטומטית של צד
בתיעוד Git, האפשרות ours בתוך אסטרטגיית המיזוג מעדיפה את הצד הנוכחי בחלקים המתנגשים. האפשרות theirs מעדיפה את הצד האחר. אלה הכרעות טכניות שיכולות לאבד דרישה.
קיימת גם אסטרטגיית מיזוג בשם ours, שמתעלמת מהשינויים של הצד האחר ומשאירה את העץ של הצד הנוכחי. היא שונה מהאפשרות שמעדיפה רק חלקים מתנגשים. לכן פקודה שנראית כמו קיצור דרך יכולה לשנות את משמעות המיזוג כולו.
כברירת עבודה, בקשו הסבר לפני בחירה גורפת. אם הצוות החליט לוותר על שינוי, תעדו מה הוחלט ולמה, במקום להסתיר את הוויתור מאחורי סימון "resolved".
בודקים את השילוב, לא רק את הסימנים
הפקודה git diff --check מזהירה על סימני קונפליקט או שגיאות רווח שנוספו בשינוי. לפי תיעוד Git היא מחזירה קוד יציאה שאינו אפס כשנמצאות בעיות. היא אינה בודקת שהרשאה, מניעת כפילות או התנהגות אחרת נשמרו.
בדקו תרחיש שמייצג כל צד, ואז תרחיש שמפעיל את שניהם יחד. בדוגמת ההרשאה והשמירה, בדקו משתמש מורשה, משתמש שאינו מורשה ופעולה חוזרת. הרשימה היא המחשה ותלויה בחוזה האמיתי של הקוד.
לצד בדיקות אוטומטיות, עברו על ה-diff מול הכוונות שתועדו. סימני קונפליקט שנעלמו הם שלב בתהליך, לא ראיית הצלחה.
מחזירים דוח קצר לפני שממשיכים
בסיום הסוכן צריך להציג אילו קונפליקטים טופלו, מה נשמר מכל צד, אילו פקודות הורצו ומה לא נבדק. שינוי נוסף שנדרש כדי להשלים את החיבור צריך להיות גלוי בפני עצמו.
אם התוצאה אינה שומרת על שתי הדרישות, חוזרים להחלטה. התפקיד של הסוכן הוא להוריד את העבודה המכאנית, בלי להפוך בחירה עסקית או הנדסית למשהו שקורה במקרה בתוך קובץ.
מקורות ופרטים נוספים
ההמלצות הן דרך עבודה מוצעת. ההמחשות מובחנות מטענות על ניסיון ותוצאות בפועל. המקורות הטכניים נבדקו ב-13.10.2026.
שאלות נפוצות
האם אין סימני קונפליקט פירושו שהמיזוג נכון?
זה אומר שהסימנים הוסרו. עדיין צריך לבדוק את ההתנהגות של שני הצדדים ואת התוצאה המשולבת.
האם merge --abort תמיד מחזיר הכול?
Git מנסה לשחזר את המצב לפני המיזוג. כשיש עבודה מקומית שלא נשמרה, השחזור אינו מובטח בכל מצב.
האם git diff --check בודק את הלוגיקה?
הוא מזהה סימני קונפליקט ושגיאות רווח. בדיקת ההתנהגות דורשת תרחישים וראיות נפרדים.