תחזוקת המאגר
git אף פעם לא אומר לכם כמה מאגר עולה. הוא ממשיך לעבוד בכל מצב שמסד האובייקטים שלו נמצא בו, ולכן הסימן הראשון לצרה הוא בדרך כלל שכפול שזוחל או לפטופ בלי מקום בדיסק — הרבה אחרי הנקודה שבה פקודה אחת הייתה פותרת את זה.
הפאנל הזה הוא הקריאה החסרה: לאן הלך המקום, כמה ממנו ניתן לשחרור, ומה כל משימה עושה עוד לפני שאתם מריצים אותה.
⌘K ← תחזוקת המאגר.
קריאת המספרים
הכול מגיע מ־git count-objects -v וממעבר נגישות אמיתי — שום דבר אינו הערכה.
| שורה | מה זה | למה זה גדל |
|---|---|---|
| ארוז | אובייקטים בתוך packfiles, דחוסים ומדולתים | זה המצב הבריא |
| פזור | קובץ אחד לכל אובייקט, כמעט בלי דחיסה | כל קומיט וכל הבאה כותבים כאלה |
| בלתי נגיש | אובייקטים ששום דבר כבר לא מצביע עליהם | קומיטים שנזרקו, הודעות שתוקנו, ריבייסים שנזנחו |
המונה שליד פזור — ״n אובייקטים, m כבר ארוזים״ — הוא זה ששווה לעקוב אחריו.
אותם m שמורים פעמיים: פעם אחת פזורים, פעם אחת בתוך חבילה. הם כפילות טהורה,
ו־git gc הוא מה שמקפל אותם.
בלתי נגיש עדיין אינו זבל. אותם אובייקטים הם הדרך שבה git reflog מחזיר קומיט
שאיפסתם החוצה. git שומר אותם שבועיים בכוונה.
המשימות
| כפתור | מריץ | עלות |
|---|---|---|
| אופטימיזציה | git gc |
שניות עד דקה. כמעט תמיד התשובה הנכונה |
| אריזה מחדש מאפס | git gc --aggressive |
דקות במאגר גדול. מחשב מחדש כל דלתא |
| בנייה מחדש של גרף הקומיטים | git commit-graph write --reachable |
מהיר. הופך מעברי log וגרף למהירים בצורה מורגשת |
| בדיקת שלמות | git fsck --dangling |
איטי במאגר גדול, ולא משנה דבר |
| זריקת הבלתי נגישים עכשיו | git gc --prune=now |
הורס את רשת הביטחון של ה־reflog |
אופטימיזציה היא זו שכדאי להושיט אליה יד. היא אורזת אובייקטים פזורים, זורקת מה שהיה בלתי נגיש למעלה משבועיים, ומשאירה את ההיסטוריה האחרונה ניתנת לשחזור.
אריזה מחדש מאפס נמכרת ביתר. היא זורקת כל דלתא קיימת ומחשבת מחדש מכלום, דבר שלוקח דקות ובדרך כלל חוסך אחוזים בודדים לעומת gc רגיל. שווה לעשות פעם אחת אחרי ייבוא של היסטוריה ענקית; לא שווה לעשות באופן שגרתי.
זריקת הבלתי נגישים עכשיו שואלת קודם, והאישור אומר כמה אובייקטים וכמה מקום. אחריה, קומיט שאיפסתם החוצה לפני שעה אינו ניתן לשחזור — רשומת ה־reflog אולי עדיין תופיע ברשימה, אבל האובייקט שמאחוריה נעלם.
בדיקת שלמות
git fsck מאמת שכל אובייקט שמופנה על ידי אובייקט אחר באמת נוכח ועקבי מבפנים.
- אובייקטים משתלשלים הם נורמליים. הם הבלתי נגישים, מפורטים לפי שם. מאגר עם מאות כאלה אחרי ריבייס הוא מאגר בריא.
- אובייקטים חסרים הם נזק — כתיבה שנקטעה, דיסק פגום, העברה שהופסקה. אם מופיעים כאלה, אל תארזו מחדש: אריזה מחדש של מסד פגום יכולה להפוך בעיה ניתנת לשחזור לבעיה קבועה. שכפלו עותק תקין מהרימוט שלכם והעבירו את הענפים שלא נדחפו בעזרת חבילה.
תחזוקה ברקע
תיבת הסימון רושמת את המאגר ל־git maintenance, שאורז ומביא מראש לפי לוח זמנים
שמערכת ההפעלה שלכם מריצה (launchd, systemd או Task Scheduler).
שום דבר כאן אינו ייחודי ל־Gitcito: אותו לוח זמנים משרת את הטרמינל שלכם,
ו־git maintenance unregister מבטל אותו מכל מקום. הסרת הסימון עושה בדיוק את זה,
ומשאירה את לוח הזמנים במקומו עבור כל מאגר אחר שרשום.
מגבלות ששווה להכיר
- מונה הבלתי נגישים דורש מעבר נגישות מלא, ולכן פתיחת הפאנל במאגר גדול מאוד לוקחת רגע. זה המספר הכן, לא הערכה.
- הגדלים הם מה שהדיסק מוותר עליו, לא אורך התוכן. אובייקט פזור של 400 בייט עדיין תופס בלוק של 4 קילו־בייט, ולכן אלף כאלה עולים מגה־בייטים — ולכן שווה לארוז אותם.
- לעץ עבודה או לתת־מודול יש
.gitמשלהם, ולכן הגודל המוצג הוא של המאגר הזה בלבד. - תחזוקה אינה יכולה לכווץ היסטוריה. אם בלוב של 400 מגה־בייט נמצא בקומיט, הוא נגיש, ו־gc ישמור אותו לנצח — זו הסרת קובץ מההיסטוריה, פעולה אחרת והרבה יותר משבשת.
- Gitcito לעולם אינו מריץ gc מאחורי הגב שלכם. ה־
gc --autoשל git עצמו עדיין עשוי, כמו תמיד; אם אחד נכשל הוא משאיר פתק ב־.git/gc.log, שהפאנל הזה מציף.
ראו גם: הסרת קובץ מההיסטוריה · חבילות וארכיונים · שחזור