Git worktree לסוכני AI: מפרידים גם את סביבת הריצה

Git worktree vs branch: תיקייה אינה סביבת ריצה

ענף (branch) הוא קו פיתוח. Worktree מקושר (linked worktree) הוא תיקיית עבודה נוספת שמחוברת לאותו מאגר, וכך אפשר להחזיק יותר מענף אחד פתוח בו זמנית. המדריך הרשמי של Git (נבדק ב-11 בנובמבר 2026) מציין גם שקובץ ההגדרות של המאגר משותף כברירת מחדל לכל ה-worktrees. לכן לא מתייחסים לתיקיות נפרדות כאל מאגרים עצמאיים לגמרי, ושום דבר במדריך לא מציג אותן כסביבות מבודדות מבחינת אבטחה. התיעוד הרשמי מופיע ברשימת המקורות למטה.

מומלץ לעקוב אחרי שתי זהויות בכל משימה: עותק העבודה שמכיל את הקוד, והסביבה שאליה פונה התהליך שרץ. מתעדים נתיב מלא, ענף, גרסת קוד (revision), כתובת היישום ויעד נתוני הבדיקה. לפי המדריך, הפקודה git worktree list מציגה לכל worktree את גרסת הקוד ואת הענף שפתוחים בו, וזה מכסה רק את הזהות הראשונה. תוצאת בדיקה בלי הזהות השנייה יכולה להיראות מרגיעה, אף שבפועל היא בדקה שרת של משימה אחרת.

גם שני ענפים נקיים יכולים להפריע זה לזה

דוגמה להמחשה בלבד, לא סיפור לקוח: סוכן אחד משנה את ה-parser של קובצי ייבוא במערכת לגאסי (legacy), וסוכן אחר מעדכן דוח פנימי. כל אחד עובד ב-worktree משלו, אבל שני היישומים מתחברים לאותו בסיס נתונים של סביבת הפיתוח. איפוס נתוני הבדיקה של ה-parser מוחק שורות שבדיקת הדוח מצפה למצוא. השינוי בבסיס הנתונים המשותף לא מופיע באף אחד משני ה-diffs.

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

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

בדיקה מקדימה לפני שמריצים סוכנים במקביל

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

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

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

מפרידים במכוון פרטי גישה והשפעות חיצוניות

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

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

משלבים פעם אחת, ואז בודקים את המסלול המלא

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

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

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