Git worktree או submodule: איך לבחור
הקטעים מתארים מקרים שונים, לא סקריפט אחד. בחרו את המקרה המתאים והחליפו שמות ענפים, נתיבים ו-VERIFIED_COMMIT לפני השימוש. פקודות ביטול שייכות רק לפעולה הפעילה המתאימה; אין לבצע את שני החלופות.
התשובה הקצרה
השתמשו ב-worktree ל-checkout נוסף של אותו מאגר למשימות מקבילות או בדיקת ענף. השתמשו ב-submodule כשהאב צריך לרשום commit מסוים ממאגר אחר כתלות. הראשון מוסיף תיקיית עבודה להיסטוריה משותפת; השני מוסיף מאגר בעל גרסאות עצמאיות שהאב מתעד בחירה מתוכו.
| החלטה | Worktree | Submodule |
|---|---|---|
| היסטוריה | אותו מאגר; עצמים ורוב ההפניות משותפים | מאגר בן נפרד; האב רושם commit מסוים |
| קבצים | HEAD, אינדקס ותיקיית עבודה נפרדים | checkout הבן והקיבועים באב ובאינדקס עשויים להבדיל |
| גרסה | ענף או commit באותו מאגר | commit בן שנבחר, לא רק .gitmodules |
| עדכון | בדיקת הענף שנבחר ושילובו | checkout לקיבוע הרשום; --remote בחירה אחרת |
| מגבלה | בדרך כלל checkout אחד לענף; לא בידוד הרשאות | תמיכה חלקית בכמה worktrees; עבודת הבן נפרדת |
הדוגמה והתנאים
קבעו תחילה מי מנהל את ההיסטוריה. שני סוכנים שבודקים תיקונים חלופיים לאותו יישום צריכים בדרך כלל ענפים ותיקיות נפרדים. ספרייה עם גרסאות משלה עשויה לדרוש קיבוע. שניהם אינם sandbox להרשאות; גישה לקבצים ולסוכנים דורשת בקרות נפרדות.
בדיקת המצב לפני שינוי
ל-worktree מקושר יש HEAD, אינדקס וקבצים משלו, אך עצמים ורוב ההפניות משותפים. אפשר לבדוק ענף אחר בלי להחליף את העבודה הנוכחית. Git מונע בדרך כלל אותו ענף בשני worktrees. שיתוף עצמים לא מעביר אוטומטית עריכות שלא הוכנו.
git status --short
git branch --show-current
git worktree listשמירת הפניה או checkout נפרד
בדקו מצב וצרו review/worktree ב-../topic-review. השתמשו ב-git -C לבדיקת ה-checkout וה-commits לפני שילוב התוצאה שנבחרה. תיקיות נפרדות מפחיתות ערבוב משימות, לא מבטיחות שינויים תואמים. בדקו שילוב ומנעו שתי תוכנות שמשנות אותו checkout בו-זמנית.
git worktree add -b review/worktree ../topic-review HEAD
git -C ../topic-review status --short
git -C ../topic-review branch --show-currentהמסלול הראשון
submodule הוא מאגר עצמאי בנתיב בתוך האב. עץ האב המאושר רושם gitlink, בדרך כלל מצב 160000, ל-commit בן. האינדקס יכול להכין קיבוע אחר ו-HEAD הבן עשוי להבדיל משניהם. .gitmodules מתאר נתיב וכתובת; ה-commit הרשום קובע גרסה.
בחירה מכוונת בתוצאה אחרת
ב-deps/library בדקו בנפרד submodule status, gitlink של HEAD האב, gitlink באינדקס ו-HEAD הבן. pull באב יכול לשנות קיבוע בלי להזיז את הבן. submodule update משתמש בבחירה הרשומה; --remote בוחר מעקב מרוחק במכוון, החלטת גרסה אחרת ולא ניקוי מצב בלבד.
git submodule status -- deps/library
git ls-tree HEAD -- deps/library
git ls-files --stage -- deps/library
git -C deps/library rev-parse HEAD
git --no-optional-locks -C deps/library status --shortמגבלות וחריגים
Git מתעד תמיכה לא מלאה ב-submodules בכמה worktrees. --recursive אינו הופך כל שילוב לסביבה מבודדת נתמכת. בדקו מגבלות ומסלול checkout ועדכון בפועל; שקלו clone נפרד למצב עצמאי. זו אינה הוראה אוניברסלית לאוטומציה של שילובם.
התנגשויות וניקוי
לפני הסרת worktree בדקו קבצים מקומיים וענף והשתמשו ב-worktree remove, לא מחיקה עיוורת של תיקייה. שמרו ענף נחוץ או merge שנבדק. לפני שינוי קיבוע, בצעו commit ופרסום של שינוי הבן בתהליך שלו כדי ש-clone אחר יוכל לקבלו, ואז רשמו באב.
git -C ../topic-review status --short
git worktree remove ../topic-review
git worktree listאימות התוצאה
ב-worktree בדקו ענף, מצב ותוצאה משולבת. ב-submodule השוו שלושה מצבים ואמתו שהמשתמשים המיועדים יכולים לקבל את עצם הבן. אב נקי לא מבטיח ילדים נקיים. אף מנגנון אינו גיבוי קבוע לקבצים ללא commit; הבדיקה תלויה ביחס ההיסטוריות.
git worktree list
git submodule status -- deps/libraryשאלות נפוצות
למה worktree? ענף נוסף בלי להחליף checkout נוכחי. מתי submodule? תלות בעלת גרסאות משלה המקובעת באב. למה להימנע? כללי עדכון נפרדים דורשים תיאום. מנהל חבילות, vendoring, subtree או clone עצמאי הם חלופות לפי בעלות ומסירה, בלי מנצח כללי.
בדיקת הפעולה ב-FluxGit
השתמשו בהיסטוריה החזותית ובתצוגת השינויים של FluxGit לבדיקת הפעולה וה-commits הרלוונטיים. שמרו את בדיקות הענף, השיתוף והקבצים המקומיים מהדוגמה. דף ההורדה מציג גרסאות ופלטפורמות זמינות כעת.