איך GitHub בונה מחדש את תשתית Git בשביל סוכני AI

כשמפתח עובד עם Git, הוא עושה commit כמה פעמים ביום, push מדי פעם, ו־CI רץ אחרי כל push. סוכן קוד עובד אחרת: הוא עושה commit כמעט אחרי כל פעולה, עובד על ענף משלו, ויכול לרוץ במקביל לעוד אלף סוכנים על אותו מאגר. GitHub פרסמה השבוע איך העומס הזה נראה אצלה, ולמה היא בונה מחדש את תשתית ה־Git שלה. גם אם אתם לא מנהלים שרתי Git, יש כאן שיעור טוב על ארכיטקטורה תחת עומס, ועל מה שמשתנה כשסוכנים הופכים למשתמשים העיקריים של מערכת.

הכתבה מבוססת על Building Git infrastructure for agent-scale development של בריאן סלנזה, מהנדס ב־GitHub, מ־6 באוקטובר 2026.

המספרים: מה סוכנים עושים ל־Git

הנתונים ש־GitHub פרסמה, בהשוואה לשנה הקודמת:

והמספר שממחיש את הבעיה יותר מכול: המאגר העמוס ביותר קיבל כמיליארד בקשות באוגוסט 2026. מאגר אחד.

חמשת צווארי הבקבוק

GitHub מזהה חמש נקודות שבהן תשתית שנבנתה לבני אדם נתקעת מול סוכנים:

1. זמן ה־commit של כל סוכן. סוכן עושה commit אחרי כמעט כל צעד. כשכל commit לוקח זמן, הזמן הזה הופך לגבול של כמות העבודה שהסוכן מספיק.
2. קצב הכתיבה. אלפי סוכנים, כל אחד על ענף משלו, יוצרים זרם קבוע של push שמתנקז לאותן נקודות במערכת.
3. תחרות על המיזוג. בפיתוח מבוסס trunk (ענף ראשי אחד שכולם ממזגים אליו), כל השינויים נכנסים לאותו reference אחד. זה צוואר בקבוק מעצם ההגדרה.
4. הכפלת קריאות. כל push מפעיל CI וסריקות קוד, שעושים clone או fetch לאותו ענף אלפי פעמים בדקה. push אחד הופך לאלפי קריאות.
5. תחזוקה. דחיסה של המאגר ו־garbage collection (ניקוי אובייקטים שאף אחד לא מצביע עליהם) גדלים עם כל כתיבה חדשה.

למה הארכיטקטורה הקיימת נתקעת

התשתית הנוכחית של GitHub נקראת Spokes. כל מאגר נשמר כעותק מלא על הדיסקים של חמישה שרתי קבצים, ופרוטוקול three-phase commit (פרוטוקול שבו כל השרתים מסכימים על כתיבה לפני שהיא נחשבת גמורה) דואג שכולם יישארו מסונכרנים.

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

• עמידות: ככל שיש יותר עותקים, כך קטן הסיכוי לאבד מידע.
• קריאה: ככל שיש יותר עותקים, כך יותר שרתים יכולים לענות לקריאות.

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

העיקרון הראשון: לתאם רק מה שחייב

הרעיון הראשון בארכיטקטורה החדשה הוא להפריד בין מה שדורש הסכמה לבין מה שיכול לרוץ לבד. ב־push, הדבר היחיד שבאמת דורש תיאום הוא עדכון ה־reference עצמו: הרגע שבו הענף מתחיל להצביע על ה־commit החדש.

כל השאר רץ במקביל:

• שמירת האובייקטים.
• בדיקה שהאובייקטים שלמים ומחוברים.
• סריקת סודות (secret scanning).

גם התחזוקה זזה הצידה: דחיסה ו־garbage collection רצים על workers נפרדים, מול האחסון הקבוע, ולא על השרתים שעונים לבקשות. התוצאה היא שהנתיב הקריטי של push מתכווץ לצעד הקטן שבאמת חייב תיאום.

העיקרון השני: להפריד אחסון מחישוב

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

• אחסון: העותק הקובע של המאגר נשמר ב־Azure Blob Storage, שאחראי לעמידות ולשכפול.
• חישוב: workers קלים שומרים מטמון (cache) של המידע ועונים לבקשות Git.

ההפרדה הזו פותרת את הבעיה מהחלק הקודם. אפשר להוסיף workers לפי התנועה בלי להאט כתיבות, וכתיבה לא צריכה לחכות לעשרות עותקים. גם נפילה נראית אחרת: worker שנפל הוא כמו cache miss. worker חדש מתחיל לענות מיד וממלא את המטמון מהאחסון.

לפני: כל שרת הוא גם אחסון וגם חישוב
  push ← חמישה שרתים מסכימים ← כולם כותבים לדיסק ← כולם עונים לקריאות

אחרי: שתי שכבות נפרדות
  push ← עדכון reference מתואם ← שמירה ב־Azure Blob Storage
  קריאות ← workers עם מטמון, כמה שצריך לפי התנועה

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

העיקרון השלישי: בני אדם נשארים בשליטה

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

• ענפים, review, מיזוג והיסטוריה.
• הגנות על ענפים ו־review חובה, כך ששינוי של סוכן לא נכנס בלי בדיקה.
• audit logs לצוותי אבטחה.
• אוטומציה ומדדים לצוותי התפעול.

המעבר עצמו שקוף: אין חלון הסבה ואין שינוי בצד המשתמש.

מה זה אומר לצוותים שעובדים עם סוכנים

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

• המיזוג הוא צוואר הבקבוק, לא הכתיבה. אם אתם מריצים כמה סוכנים במקביל על אותו מאגר, הם יתחרו על הענף הראשי. ענף לכל סוכן ותור מיזוג (merge queue) עדיפים על מיזוג ישיר.
• CI הוא חלק מהעלות. כל push של סוכן מפעיל pipeline. הגדירו מה באמת צריך לרוץ על כל push, ומה רק לפני מיזוג.
• ההגנות חשובות יותר, לא פחות. כשסוכנים כותבים חלק גדול מהקוד, review חובה והגנה על הענף הראשי הם מה שמשאיר את ההחלטה אצל בני אדם.

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

בקצרה

1. 01העומס

   פי 5 ב־commits ופי 4.9 ב־push בשנה, בעיקר בגלל סוכני קוד.

2. 02הבעיה

   אותם עותקים משמשים לעמידות ולקריאה, וכל עותק מאט כתיבה.

3. 03הפתרון

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

4. 04התוצאה

   עד פי 35 בקצב כתיבה, בלי שינוי בעבודה של הצוות.