6 אוטומציה — Worktrees

Git Worktrees and Parallel Development — פיתוח מקבילי

Claude Code מאפשר להריץ כמה sessions במקביל, כל אחד על branch נפרד, בלי שום התנגשות. בפרק הזה נלמד מה זה Git Worktree, איך הפלאג -w הופך פיתוח מקבילי לחוויה חלקה, איך להשתמש ב-sparse checkout למונורפוס, מה הם הכלים EnterWorktree ו-ExitWorktree, איך לנהל sessions מרובים עם tmux, ואיך /batch מנצל worktrees כדי לפצל משימות ל-30 agents במקביל. עדכני למרץ 2026 (v2.1.81).

מה יהיה לך בסוף הפרק הזה
מה תוכל/י לעשות אחרי הפרק הזה
דרישות קדם
הפרויקט שלך

בפרק 5 למדנו לגלות, להתקין ולבנות Plugins — חבילות שלמות של Skills, Hooks ו-Agents. בנינו Plugin מותאם אישית, ניהלנו תוספים מותקנים, וביצענו ביקורת אבטחה. עכשיו אנחנו עולים רמה: הכוח האמיתי של Claude Code נמדד ביכולת שלך לעבוד במקביל. כל ה-Plugins, Hooks ו-Agents שבנית? הם ילוו אותך לכל worktree — אוטומטית, בלי שום הגדרה נוספת. בפרק הזה נלמד איך לפתוח כמה "יקומים מקבילים" בפרויקט אחד ולעבוד עליהם בו-זמנית — בלי שום קונפליקט.

מתחיל 8 דקות חינם מושג

מה זה Git Worktree ולמה זה חשוב

Git Worktree (עותק עבודה) הוא תיקייה נפרדת שמקושרת לאותו repository של Git. כל worktree מחזיק branch משלו, אבל כולם חולקים את אותו היסטוריית commits — את אותו .git. זה אומר שאתה יכול לעבוד על שני features במקביל, כל אחד בתיקייה שלו, בלי להפריע אחד לשני.

נשמע פשוט? זה פשוט. אבל זה משנה את כל הדרך שבה אתה עובד עם Claude Code.

בעולם שבו Claude Code יכול לעבוד עצמאית על קבצים, עריכות, tests ו-commits — הצוואר בקבוק הוא לא המהירות של ה-AI, אלא כמה דברים אתה יכול להריץ במקביל. Worktrees מסירים את הצוואר בקבוק הזה. במקום Claude Code session אחד שעובד על דבר אחד, אתה מריץ 3, 5, או אפילו 30 sessions — כל אחד על worktree משלו — ומקבל פי 3, 5, או 30 יותר תפוקה.

זו הסיבה ש-Anthropic השקיעו בתמיכה מובנית ב-worktrees: הם הבינו שכדי שמפתחים יפיקו את המקסימום מ-Claude Code, הם צריכים דרך פשוטה להריץ agents מרובים במקביל בלי קונפליקטים. התמיכה הזו הוסיפה את הפלאג -w בגרסאות 2026, שיתוף הגדרות אוטומטי ב-v2.1.63, sparse checkout ב-v2.1.76, ואת הכלים הפרוגרמטיים EnterWorktree/ExitWorktree ב-v2.1.72.

העולם בלי Worktrees

בלי worktrees, אם אתה באמצע עבודה על feature-payments ופתאום צריך לתקן באג דחוף ב-auth, הזרימה נראית ככה:

הדרך הישנה — Branch Switching

git stash — שמור את השינויים הנוכחיים בצד
git checkout bugfix-auth — עבור ל-branch של הבאג
... עבוד על התיקון ...
git commit -m "fix auth" — שמור
git checkout feature-payments — חזור ל-feature
git stash pop — שחזר את השינויים ששמרת

הבעיות: stash שוכחים לשחזר, עריכות נאכלות, context של Claude Code נמחק כי הקבצים השתנו, וכל ה-session "מתבלבל" כי הפרויקט נראה פתאום אחרת.

העולם עם Worktrees

עם worktrees, כל feature חי בתיקייה משלו. אתה לא "עובר" לשום מקום — אתה פותח חלון נוסף.

הדרך החדשה — Parallel Worktrees

טרמינל 1: claude -w feature-payments — עובד על תשלומים
טרמינל 2: claude -w bugfix-auth — מתקן באג ב-auth

שניהם רצים במקביל. שניהם רואים את אותו repository. אף אחד לא משפיע על השני. כשמסיימים — עושים merge דרך PR.

x3-x5

שיפור משוער בפרודוקטיביות כשעוברים מ-branch switching ל-parallel worktrees. במקום "תור" (סדרתי) — עובדים ב"מקביל". שלושה features שלוקחים שעה כל אחד? עם worktrees הם לוקחים שעה ביחד. המכפיל תלוי בטיב ההפרדה בין המשימות ובמשאבי ה-tokens הזמינים.

מסגרת החלטה: "Worktrees = יקומים מקבילים"

חשבו על כל worktree כיקום מקביל: בכל יקום אפשר לעשות שינויים בלי להשפיע על היקומים האחרים. כשהשינויים מוכנים — מאחדים (merge) את היקומים. אם ניסוי נכשל — פשוט מוחקים את היקום הזה. שום דבר לא נפגע.

מתי Worktrees חיוניים

מצב בלי Worktrees עם Worktrees
באג דחוף באמצע feature stash, switch, fix, switch back, pop — 10+ דקות overhead פתח טרמינל חדש, -w bugfix — 30 שניות
ניסוי עם 3 גישות שונות commit, branch, try, switch, try, switch... כאוס 3 worktrees, 3 sessions, השוואת תוצאות
Frontend + Backend במקביל אחד ממתין לשני — צוואר בקבוק worktree-api + worktree-ui — פיתוח בו-זמני
Code review + המשך פיתוח עוצרים הכל בשביל ה-review worktree-review + worktree-next-feature
Production hotfix + ספרינט שוטף כל הצוות עוצר למצב חירום worktree-hotfix רץ בצד, השאר ממשיכים

מה קורה מתחת למכסה המנוע

כשאתה מריץ git worktree add, Git עושה כמה דברים:

זה אומר ש-worktree חדש לא תופס הרבה יותר מקום מ-checkout רגיל. כל ההיסטוריה (.git/objects/) משותפת. מה שתופס מקום זה רק הקבצים עצמם — ה-working copy.

טיפ: Worktrees מול Git Clone

למה לא פשוט לעשות git clone נוסף? כי clone יוצר repository חדש לגמרי — כולל .git מלא. worktree חולק את ה-.git. בפרויקט עם 2GB של היסטוריה, clone = 2GB נוסף. Worktree = רק גודל ה-working copy (אולי 100MB). בנוסף, worktrees רואים commits אחד של השני מיד — בלי git fetch.

עשה עכשיו 2 דקות

פתח טרמינל בפרויקט Git כלשהו (גם אם זה פרויקט ניסיוני ריק) והקלד: git worktree list. התוצאה תראה לך את ה-worktree הראשי (main) ואת ה-branch שלו. זו נקודת ההתחלה — בהמשך הפרק נוסיף worktrees חדשים.

בינוני 10 דקות תרגול

הפלאג -w — תמיכה מובנית ב-Claude Code

ב-2026 Claude Code הוסיף תמיכה מובנית (native) ב-Git Worktrees דרך הפלאג -w (או הגרסה המלאה: --worktree). זה הופך את כל תהליך יצירת worktree, branch, ו-session לפקודה אחת.

הפקודה הבסיסית

יצירת Worktree עם Claude Code

claude -w feature-payments

מה קורה מאחורי הקלעים:

1. נוצרת תיקייה חדשה: .claude/worktrees/feature-payments/
2. נוצר branch חדש בשם cc/feature-payments
3. ה-worktree מכיל עותק מלא של הפרויקט על ה-branch החדש
4. Claude Code מתחיל session חדש שרואה רק את קבצי ה-worktree
5. כל עריכה שתעשה — תישאר בתוך ה-worktree בלבד

שימו לב לקונבנציית השמות: שם ה-worktree הופך לשם ה-branch עם prefix של cc/. אז -w payments יוצר branch בשם cc/payments. זה עוזר לזהות בקלות אילו branches נוצרו על ידי Claude Code — כשאתה רואה branch שמתחיל ב-cc/, אתה יודע מיד שהוא נוצר דרך worktree של Claude Code.

שילוב עם session naming

מגרסה v2.1.76 (מרץ 2026), אפשר לשלב את הפלאג -w עם הפלאג -n (session naming) כדי לתת לכל session שם תיאורי:

Worktree עם שם Session

claude -w feature-payments -n "Stripe integration sprint 42"

עכשיו יש לך worktree עם branch cc/feature-payments, והשם "Stripe integration sprint 42" מופיע בכותרת ה-session. כשאתה מנטר כמה sessions במקביל, זה עוזר מאוד לזהות מי עושה מה.

גרסה מלאה מול קיצור

צורה פקודה תוצאה
קיצור claude -w feature-payments worktree + branch cc/feature-payments
מלא claude --worktree feature-payments זהה לחלוטין
עם שם claude -w payments -n "Sprint 42" worktree + branch + session שם תיאורי

מה קורה בתוך ה-Session

ברגע שהפעלת claude -w feature-payments, אתה בעולם נפרד. Claude Code רואה רק את קבצי ה-worktree — לא את קבצי ה-main branch שלך. כל קובץ שתערוך, כל קובץ שתיצור, כל commit שתעשה — הכל נשאר בתוך ה-worktree בלבד.

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

מ-Worktree ל-PR

1. claude -w feature-payments — עבדת על ה-feature
2. Claude עשה commits ל-branch cc/feature-payments
3. git push origin cc/feature-payments — דחוף לרמוט
4. פתח PR מ-cc/feature-payments ל-main
5. Review, approve, merge — כמו כל PR אחר

אזהרה: Worktree לכל branch ייחודי

אי אפשר לפתוח שני worktrees על אותו branch. אם branch cc/payments כבר checked out ב-worktree אחד, ניסיון ליצור worktree שני עם אותו שם ייכשל. כל worktree חייב branch ייחודי — זה גם הגיוני: שני "יקומים" על אותו branch פשוט לא הגיוני.

תרחישי שימוש מתקדמים עם -w

הפלאג -w לא רק ל-feature branches. הנה תרחישים נוספים:

תרחיש פקודה מה מקבלים
ניסוי סיכון גבוה claude -w experiment-new-arch worktree מבודד שאפשר למחוק אם הניסוי נכשל. אפס סיכון לקוד הראשי.
Code Review claude -w review-pr-42 worktree מבודד שבו Claude בודק PR ספציפי. לא מפריע לעבודה הנוכחית שלך.
Hotfix דחוף claude -w hotfix-login-crash תיקון מהיר בלי לגעת ב-feature שאתה באמצע. תקן, דחוף, חזור לעבוד.
דמו ללקוח claude -w demo-client-acme הכן גרסת דמו מותאמת בלי להשפיע על ה-development branch.
CI/CD debugging claude -w debug-ci-pipeline worktree ייעודי לניסויים על pipeline בלי לשבור את ה-main workflow.

הרעיון המרכזי: כל פעם שיש לך משימה שאתה לא רוצה שתשפיע על מה שאתה עושה עכשיו, -w הוא הפתרון. זה "sandbox" מיידי.

עשה עכשיו 5 דקות

בפרויקט Git שלך, הרץ claude -w test-worktree. ברגע שה-session עולה, בקש מ-Claude: "צור קובץ בשם hello-worktree.txt עם הטקסט 'זה worktree ניסיוני'". אחרי שהקובץ נוצר, צא מה-session (Ctrl+C). עכשיו בדוק: הקובץ קיים ב-.claude/worktrees/test-worktree/ אבל לא בתיקייה הראשית של הפרויקט. זה ההפרדה בפעולה.

בינוני 12 דקות תרגול

Sessions מקביליים ב-Worktrees שונים

ה-Killer Feature של worktrees ב-Claude Code הוא פשוט: אתה פותח כמה טרמינלים, מריץ claude -w עם שם אחר בכל אחד, ונותן לכל session לעבוד על משימה שונה. במקביל.

הדוגמה הקלאסית: שלוש משימות בו-זמנית

Three Parallel Sessions

טרמינל 1:
claude -w feature-payments
"Implement the Stripe payment integration for the checkout flow"

טרמינל 2:
claude -w bugfix-auth
"Fix the JWT token expiration handling — tokens expire after 15 minutes instead of 24 hours"

טרמינל 3:
claude -w refactor-database
"Refactor all database queries to use prepared statements instead of string concatenation"

כל session הוא לחלוטין מבודד:

מה קורה בפועל

כשאתה מריץ שלושה sessions במקביל, בפועל שלושה agents עצמאיים עובדים על הפרויקט שלך. הם קוראים קבצים, כותבים קוד, מריצים tests — כל אחד בענף שלו, בלי שום התנגשות.

אבל יש עלות: כל session צורך tokens. שלושה sessions במקביל = בערך פי 3 בעלות של session בודד. זה ה-trade-off — אתה משלם יותר, אבל מסיים מהר יותר. במנויי Max/Team/Enterprise עם 1M context (Opus 4.6, מרץ 2026), כל session יכול להכיל הרבה יותר context — מה שאומר שהוא יכול לעבוד על משימות מורכבות יותר בלי compaction.

$2-5

עלות משוערת של session עבודה רגיל ב-Claude Code (תלוי במודל, אורך ה-session ומורכבות המשימה). הרצת 3 sessions במקביל יכולה להגיע ל-$6-15, אבל אם זה חוסך שעה של עבודה (בערך $50-100 של זמן מפתח) — ה-ROI ברור. חשוב: העלויות משתנות — בדוק את המחירון העדכני של Anthropic.

טיפ: שמות תיאוריים = סדר

תמיד תן ל-worktrees שמות תיאוריים: feature-X, bugfix-Y, refactor-Z. כשיש לך 3-4 טרמינלים פתוחים, שמות כמו test1 ו-test2 הם מתכון לבלבול. השם צריך לספר לך מה ה-session עושה במבט חטוף.

חוקי הזהב לעבודה מקבילית

כלל למה דוגמה
משימות עצמאיות בלבד אם session 2 תלוי בתוצאה של session 1 — הם לא יכולים לרוץ במקביל payments + auth = מקבילי. payments + checkout-that-uses-payments = סדרתי
אל תערוך אותו קובץ בשני worktrees זה יצור merge conflict כשתאחד אם שניהם צריכים את config.ts — שלב ידנית אחרי merge
push לפני merge worktrees חולקים היסטוריית Git. אם תעשה merge מקומי — worktrees אחרים ייראו את השינוי תמיד push ל-remote, פתח PR, ועשה merge דרך GitHub/GitLab
הגבל ל-3-5 sessions מעבר לזה — קשה לעקוב. disk ו-tokens מתבזבזים 3 sessions = sweet spot לרוב הפרויקטים
בדוק disk לפני שמתחיל כל worktree תופס מקום. 5 worktrees על פרויקט של 1GB = 5GB הרץ df -h לפני שפותח worktrees חדשים בפרויקט גדול

תרחיש מעשי: סטארטאפ ישראלי עם 3 מפתחים

נניח שאתם צוות של 3 מפתחים בסטארטאפ בתל אביב. יש לכם אפליקציית SaaS עם backend ב-Node.js ו-frontend ב-React. בוקר יום רביעי, המצב ככה:

דוגמאות מייצגות: יום עבודה עם Worktrees

08:30 — נעם (Backend)
claude -w feature-billing-api -n "Billing API Sprint 42"
"Build the new billing API with Stripe integration. Support monthly and annual plans."
Claude עובד על 12 קבצים ב-src/api/billing/. Commits נוצרים אוטומטית.

08:35 — שירה (Frontend)
claude -w feature-billing-ui -n "Billing UI Sprint 42"
"Build the billing settings page: plan selection, payment method management, invoice history."
Claude עובד על 8 components ב-src/components/billing/. Mock data עד שה-API מוכן.

09:00 — דני (DevOps)
claude -w infra-billing-webhook -n "Stripe Webhooks"
"Set up Stripe webhook handler: verify signatures, handle payment success/failure events, update database."
Claude עובד על src/webhooks/stripe.ts ו-infrastructure/terraform/.

11:00 — שלושתם סיימו
3 PRs מוכנים ל-review. Merge לפי סדר: API → webhook → UI. תוך 2.5 שעות — 3 מפתחים סיימו feature שלם.

בלי worktrees, אותו feature היה לוקח יום וחצי לפחות — כי כל אחד היה ממתין לשני. עם worktrees, הכל רץ במקביל.

עשה עכשיו 8 דקות

פתח שני טרמינלים. בראשון: claude -w session-alpha ובקש מ-Claude ליצור קובץ alpha.txt. בשני: claude -w session-beta ובקש ליצור קובץ beta.txt. אחרי ששניהם סיימו, בדוק: ב-worktree של alpha קיים רק alpha.txt, וב-worktree של beta קיים רק beta.txt. ובתיקייה הראשית? אף אחד מהם. ההפרדה עובדת.

מתקדם 10 דקות מושג + תרגול

Sparse Checkout למונורפוס

אם הפרויקט שלך הוא מונורפו (Monorepo — מאגר אחד גדול שמכיל הרבה חבילות), כל worktree חדש מעתיק את כל הפרויקט. עם 10 חבילות שכל אחת 500MB, זה 5GB לכל worktree. 5 worktrees = 25GB. זה לא מעשי.

הפתרון: Sparse Checkout. הגדרה שאומרת ל-Git "תמשוך רק את התיקיות הספציפיות האלה". שאר הקבצים קיימים בהיסטוריית Git, אבל לא תופסים מקום ב-disk.

ההגדרה: worktree.sparsePaths

מגרסה v2.1.76 (מרץ 2026), Claude Code תומך בהגדרת worktree.sparsePaths בקובץ settings.json:

הגדרת Sparse Checkout

בקובץ .claude/settings.json:

{
  "worktree": {
    "sparsePaths": ["packages/payments/", "shared/", "config/"]
  }
}

עכשיו כשתריץ claude -w feature-payments, ה-worktree יכיל רק את התיקיות packages/payments/, shared/ ו-config/. כל שאר התיקיות — לא ייטענו.

למה זה קריטי

בלי Sparse Checkout עם Sparse Checkout
כל worktree = עותק מלא של המונורפו כל worktree = רק התיקיות הרלוונטיות
5GB per worktree (מונורפו גדול) 200MB per worktree (3 תיקיות ספציפיות)
Claude Code רואה אלפי קבצים לא רלוונטיים Claude Code רואה רק מה שצריך — context ממוקד
יצירת worktree לוקחת דקות יצירת worktree לוקחת שניות

היתרון הנסתר של sparse checkout הוא לא רק חיסכון ב-disk — הוא גם חיסכון ב-context. כש-Claude Code סורק את ה-worktree, הוא רואה רק את הקבצים הרלוונטיים. פחות קבצים = פחות tokens על סריקה = יותר context פנוי לעבודה בפועל. במונורפו של 500+ קבצים, ההבדל יכול להיות משמעותי.

מסגרת החלטה: "Sparse Worktree Strategy"

למונורפוס, הגדירו sparse paths לפי feature, לא לפי team:

Feature: Payments → ["packages/payments/", "shared/", "config/"]
Feature: Auth → ["packages/auth/", "shared/", "packages/users/"]
Feature: Dashboard → ["packages/dashboard/", "shared/", "packages/ui-kit/"]

שימו לב שתמיד כוללים shared/ או config/ — קבצים משותפים שכל feature צריך. בלעדיהם, ה-build יישבר.

שילוב עם CLAUDE.md ממוקד

כשאתה משתמש ב-sparse checkout, כדאי לשלב גם הנחיות ממוקדות בקובץ CLAUDE.md של ה-worktree. ככה Claude Code יודע בדיוק על מה לעבוד:

CLAUDE.md ל-Sparse Worktree

# Payments Worktree

This worktree focuses on the payments package.
Key files: packages/payments/src/
Shared utilities: shared/utils/
Config: config/payments.json

Do NOT reference files outside these directories —
they are not available in this sparse checkout.

Sparse Checkout — שגיאות נפוצות

כמה טעויות שכולם עושים עם sparse checkout:

שגיאה מה קורה הפתרון
שכחת לכלול shared/ קבצים שמייבאים utilities משותפים נשברים. Build errors. תמיד כלול את תיקיות ה-shared/common
שכחת לכלול config/ קובצי קונפיגורציה (tsconfig, eslint, package.json root) חסרים כלול קבצי config ברמת ה-root
כללת יותר מדי תיקיות ה-sparse checkout לא חוסך כלום. כמעט כל הקבצים נטענים כלל: מקסימום 3-4 תיקיות. אם צריך יותר — אולי לא צריך sparse
שינית sparsePaths אחרי שכבר יצרת worktree ה-worktree הקיים לא מתעדכן מחק את ה-worktree וצור חדש עם ההגדרה החדשה
אזהרה: Sparse Checkout ו-Tests

אם ה-test suite שלך רץ מרמת ה-root ומנסה לגשת לקבצים מחוץ ל-sparse paths — הוא ייכשל. וודא שה-tests של ה-package הספציפי לא תלויים בקבצים מתיקיות אחרות, או כלול את תיקיית __tests__/ / tests/ הרלוונטית ב-sparsePaths.

עשה עכשיו 3 דקות

גם אם הפרויקט שלך הוא לא מונורפו, נסה את ההגדרה. פתח את .claude/settings.json והוסף: "worktree": { "sparsePaths": ["src/", "config/"] }. עכשיו צור worktree עם claude -w sparse-test ובדוק אילו תיקיות נוצרו בתוכו. ראית רק את src/ ו-config/? מצוין. אחרי הבדיקה, הסר את ההגדרה אם לא צריך אותה.

מתקדם 8 דקות מושג

EnterWorktree / ExitWorktree — כלים פרוגרמטיים

מגרסה v2.1.72 (מרץ 2026), Claude Code כולל שני כלים (tools) חדשים: EnterWorktree ו-ExitWorktree. אלה לא פקודות שאתה מפעיל — אלה כלים ש-Claude עצמו יכול להשתמש בהם באופן פרוגרמטי במהלך הריצה.

מה זה אומר בפועל

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

EnterWorktree בפעולה

1. EnterWorktree("approach-a") — Claude נכנס ל-worktree חדש
2. מיישם את גישה A, מריץ tests
3. ExitWorktree() — חוזר לתיקייה המקורית
4. EnterWorktree("approach-b") — נכנס ל-worktree אחר
5. מיישם את גישה B, מריץ tests
6. ExitWorktree() — חוזר
7. משווה תוצאות ובוחר את הגישה הטובה ביותר

המפתח כאן: הקוד המקורי שלך לא נגע. כל הניסויים קרו ב-worktrees מבודדים. אם כל שלוש הגישות נכשלו — אף שורה לא השתנתה בקוד שלך.

מי באמת משתמש בכלים האלה?

ב-99% מהמקרים, אתה לא תשתמש ב-EnterWorktree / ExitWorktree ישירות. הם כלים פנימיים שמשמשים:

טיפ: מתי כן להשתמש ישירות

אם אתה בונה Skill שצריך isolation — למשל Skill שמנסה שתי גרסאות של refactoring ומשווה ביצועים — אתה יכול לבקש מ-Claude להשתמש ב-EnterWorktree. אבל ברוב המקרים, הפלאג -w מספיק. תחשוב על EnterWorktree כ-API פנימי, ועל -w כממשק המשתמש.

EnterWorktree מול -w — מה ההבדל

תכונה -w Flag EnterWorktree Tool
מי מפעיל המשתמש (בשורת הפקודה) Claude (באופן פרוגרמטי)
מתי בתחילת ה-session באמצע ריצה — Claude מחליט שצריך isolation
use case עבודה על feature/bugfix Skills, /batch, agents שצריכים worktrees דינמיים
ניקוי ידני (git worktree remove) אוטומטי (ExitWorktree יכול למחוק)
מספר worktrees 1 per session מרובים — Claude יכול ליצור כמה שצריך באותו session

איך /batch באמת משתמש ב-EnterWorktree

בואו נפתח את הקופסה ונראה מה קורה כש-/batch רץ. הבנה של התהליך הפנימי עוזרת כשמשהו לא עובד כצפוי:

מה /batch עושה מאחורי הקלעים, צעד אחר צעד

1. Claude מנתח את המשימה ויוצר רשימת units
2. לכל unit, Claude קורא ל-EnterWorktree("batch-unit-1")
3. בתוך ה-worktree, Claude יוצר agent חדש (subagent) עם ההנחיות הספציפיות ל-unit
4. ה-agent עובד לבד: קורא קבצים, כותב קוד, מריץ tests
5. כשהוא מסיים: commit, push, פתיחת PR
6. Claude קורא ל-ExitWorktree() וחוזר לבסיס
7. חוזר לשלב 2 עם ה-unit הבא

בגרסאות חדשות, שלבים 2-6 רצים במקביל — לא אחד אחרי השני. זה מה שמאפשר ל-30 agents לעבוד בו-זמנית.

הנה הנקודה החשובה: אם unit נכשל (טסטים לא עוברים, build שבור), ה-ExitWorktree עדיין נקרא — ה-worktree נשמר עם מצב הכישלון, וה-PR נפתח עם הערה שהוא "needs attention". זה מאפשר לך לראות מה השתבש ולתקן ידנית.

אזהרה: כשדברים משתבשים

אם /batch קרס באמצע (למשל: גבול tokens, ניתוק רשת, הפסקת חשמל), ייתכנו worktrees "יתומים" — worktrees שנוצרו אבל ה-agent שלהם לא סיים. הרץ git worktree list כדי לראות אותם, ו-git worktree remove כדי לנקות. זה לא מסוכן — רק מבלגן את ה-disk.

עשה עכשיו 3 דקות

ב-session רגיל של Claude Code (בלי -w), בקש מ-Claude: "Create a worktree called 'experiment', make a small change there, then exit the worktree and tell me what happened." Claude ישתמש ב-EnterWorktree ו-ExitWorktree כדי לבצע את הפעולה. תראה בלוג מה הכלים עשו.

בינוני 8 דקות מושג + תרגול

שיתוף הגדרות בין Worktrees

אחד הדברים הכי חשובים לדעת על worktrees ב-Claude Code: ההגדרות משותפות. מגרסה v2.1.63 (פברואר 2026), כל ה-worktrees שמקושרים לאותו repository חולקים את אותן הגדרות — אוטומטית, בלי שום קונפיגורציה נוספת.

מה בדיוק משותף

רכיב משותף? פירוט
CLAUDE.md כן קובץ CLAUDE.md של הפרויקט הראשי נטען בכל worktree
settings.json כן הגדרות פרויקט (.claude/settings.json) פעילות בכל worktree
Auto-memory כן זיכרון אוטומטי מ-sessions קודמים זמין בכל worktree
Custom commands כן Skills ב-.claude/commands/ זמינים בכל worktree
Agents כן Agent definitions ב-.claude/agents/ עובדים בכל worktree
Hooks כן Hooks שמוגדרים בפרויקט הראשי מופעלים גם ב-worktrees
.claude/rules/ כן כללים מותנים נטענים בכל worktree לפי הגלובים שלהם
Plugins כן Plugins מותקנים פעילים בכל worktree — לא צריך להתקין מחדש

זה אומר: אתה מגדיר פעם אחת בפרויקט הראשי, וכל ה-worktrees יורשים. ה-Plugins שהתקנת בפרק 5? הם עובדים בכל worktree. ה-Hooks שבנית בפרק 1? הם מופעלים בכל worktree. ה-Agents מפרק 2? זמינים בכל worktree.

חריגה: הגדרות ספציפיות ל-worktree

לפעמים אתה רוצה הגדרה שונה ב-worktree ספציפי. למשל, worktree שמוקדש לניסויים ואתה רוצה לבטל את ה-Hook שמוודא lint. במקרה כזה, אפשר ליצור settings.json בתוך תיקיית .claude/ של ה-worktree — והוא ידרוס את ההגדרות הגלובליות.

דריסת הגדרות ב-Worktree ספציפי

הגדרה ראשית (.claude/settings.json):
{ "hooks": { "PostToolUse": [{ "command": "npm run lint" }] } }

דריסה ב-worktree (.claude/worktrees/experiment/.claude/settings.json):
{ "hooks": {} }

התוצאה: ב-worktree "experiment" לא ירוצו Hooks. בכל שאר ה-worktrees — ה-lint ימשיך לרוץ.

טיפ: Configure Once, Work Everywhere

זו אחת הסיבות הכי טובות להשקיע בהגדרת CLAUDE.md, settings.json, hooks ו-agents כמו שצריך. כל עבודה שאתה שם בקונפיגורציה של הפרויקט הראשי — מתגלגלת אוטומטית לכל worktree. השקעה חד-פעמית שמשתלמת בכל session מקבילי.

המשמעות בפועל: Configure Once, Run Everywhere

בואו נראה מה זה אומר בתרחיש מעשי. נניח שבפרק 1 (Hooks) בנית Hook שרץ npm run lint אחרי כל עריכת קובץ. בפרק 2 (Agents) יצרת agent ל-security review. בפרק 4 (Skills) יצרת Skill בשם /deploy-staging. בפרק 5 (Plugins) התקנת Plugin לבדיקת code quality.

כל אלה עובדים בכל worktree שתיצור.

אין צורך להעתיק settings, להגדיר מחדש hooks, או להתקין plugins שוב. הכל אוטומטי. זו אחת הסיבות ששיתוף ההגדרות הוצג כ-feature מרכזי בגרסה v2.1.63.

עשה עכשיו 3 דקות

אם יש לך CLAUDE.md בפרויקט, צור worktree חדש (claude -w config-test) ובדוק: בקש מ-Claude "What does the CLAUDE.md say?" — הוא צריך לדעת את תוכן הקובץ למרות שאתה ב-worktree נפרד. זה שיתוף ההגדרות בפעולה.

בינוני 12 דקות תרגול

tmux + Multiple Claude Code Sessions

עד עכשיו דיברנו על "פתח כמה טרמינלים". אבל בפועל, ניהול 3-5 חלונות טרמינל נפרדים הוא כאב ראש. הפתרון: tmux (Terminal Multiplexer) — כלי שמאפשר לנהל כמה sessions בתוך חלון טרמינל אחד.

tmux בשלוש דקות

tmux מחלק את הטרמינל ל-panes (חלוניות) ו-windows (חלונות). כל pane הוא טרמינל עצמאי. אפשר לראות כמה panes במקביל על אותו מסך.

tmux Workflow ל-Parallel Development

שלב 1: יצירת session
tmux new-session -s dev — יוצר session בשם "dev"

שלב 2: יצירת panes
Ctrl+b % — מפצל אנכית (שני panes זה לצד זה)
Ctrl+b " — מפצל אופקית (שני panes אחד מעל השני)

שלב 3: Claude Code בכל pane
Pane 1: claude -w feature-payments
Ctrl+b → — עבור ל-pane הבא
Pane 2: claude -w bugfix-auth
Ctrl+b → — עבור ל-pane הבא
Pane 3: claude -w refactor-db

שלב 4: ניטור
Ctrl+b o — מחזורי בין panes
Ctrl+b z — zoom על pane ספציפי (מלא מסך)

פקודות tmux חיוניות

פקודה מה עושה מתי
tmux new-session -s name יוצר session חדש בתחילת יום העבודה
Ctrl+b c יוצר window חדש (טאב) כשצריך עוד worktree
Ctrl+b % מפצל pane אנכית לראות שני sessions זה לצד זה
Ctrl+b " מפצל pane אופקית לראות שני sessions אחד מעל השני
Ctrl+b o מעבר ל-pane הבא לניטור מהיר
Ctrl+b z zoom/unzoom על pane כשצריך לראות output מלא
Ctrl+b n / p window הבא / הקודם מעבר בין windows
Ctrl+b d detach — ה-sessions ממשיכים לרוץ ברקע סגירת מכסה הלפטופ
tmux attach -t name חזרה ל-session שרץ ברקע אחרי detach / reconnect SSH
מסגרת החלטה: "The Multi-Session Dashboard"

חשבו על tmux כמרכז שליטה. כל pane הוא חלון לעולם אחר — worktree עם Claude Code session משלו. אתם מנטרים, מכוונים ומתאמים מהמרכז. כשמשימה מסתיימת ב-pane אחד, אתם נותנים לו את המשימה הבאה. כשמשהו נתקע — אתם עוברים ל-pane ומתערבים.

tmux + SSH = פיתוח מרחוק שלא נעצר

ה-killer feature של tmux עבור worktrees: detach ו-reattach. נניח שאתה עובד מהבית דרך SSH לשרת הפיתוח. יש לך 3 worktrees פעילים עם Claude Code. פתאום האינטרנט נופל.

בלי tmux: כל 3 ה-sessions נהרגים. כל ה-context אבד. אתה צריך לפתוח הכל מחדש.

עם tmux: ה-sessions ממשיכים לרוץ ברקע על השרת. Claude Code ממשיך לעבוד. כשהאינטרנט חוזר, אתה פשוט מתחבר מחדש:

Reconnect אחרי ניתוק

ssh dev-server — חיבור מחדש לשרת
tmux attach -t parallel — חזרה ל-session
כל ה-panes שם, כל ה-Claude Code sessions עדיין רצים, כל ה-worktrees פעילים. כאילו שום דבר לא קרה.

זה במיוחד קריטי כשמריצים /batch עם 30 agents — אתה לא רוצה שניתוק רשת יהרוג שעה של עבודה.

חלופות ל-tmux

tmux הוא לא הדרך היחידה. הנה אלטרנטיבות:

כל אחת מהחלופות עובדת. היתרון של tmux: הוא עובד בכל מקום (כולל SSH), ה-sessions שורדים ניתוק, ואפשר לשתף session עם חבר צוות.

עשה עכשיו 10 דקות

התקן tmux אם עדיין לא מותקן (sudo apt install tmux / brew install tmux). צור session בשם "parallel": tmux new-session -s parallel. פצל לשני panes (Ctrl+b %). ב-pane השמאלי הרץ claude -w alpha וב-pane הימני claude -w beta. עבור ביניהם עם Ctrl+b o. זה ה-Dashboard שלך. אתה מוכן לעבודה מקבילית.

מתחיל 5 דקות תרגול

שמות Sessions ו-/color — ניהול ויזואלי

כשיש 3-4 panes עם Claude Code sessions, קשה לדעת מי עובד על מה. שני כלים פותרים את הבעיה:

הפקודה /color — צבעים ויזואליים

מגרסה v2.1.75 (מרץ 2026), הפקודה /color מאפשרת לשנות את צבע ה-prompt bar בכל session:

צביעת Sessions

Pane 1 (payments): /color blue — פס כחול
Pane 2 (auth fix): /color red — פס אדום
Pane 3 (refactor): /color green — פס ירוק

עכשיו במבט חטוף אתה יודע: כחול = תשלומים, אדום = תיקון באג, ירוק = refactoring. לא צריך לקרוא את מה ש-Claude כותב כדי לדעת באיזה session אתה.

Session Naming עם -n

מגרסה v2.1.76 (מרץ 2026), הפלאג -n מאפשר לתת שם תיאורי לכל session:

שילוב Naming + Color + Worktree

claude -w feature-payments -n "Stripe Sprint 42"
ואז בתוך ה-session: /color blue

עכשיו יש לך: worktree מבודד, branch בשם cc/feature-payments, session בשם "Stripe Sprint 42", ופס כחול. כשאתה סוקר את ה-panes ב-tmux, הכל ברור מיד.

טיפ: קונבנציית צבעים

הגדירו קונבנציה אישית או צוותית לצבעים. למשל: כחול = features חדשים, אדום = bugfixes, ירוק = refactoring/cleanup, צהוב = experiments. כשכולם בצוות משתמשים באותה קונבנציה, ניטור הופך למהיר הרבה יותר.

Remote Control — ניטור מהטלפון

מפברואר 2026, ה-Remote Control feature מאפשר לנטר ולכוון Claude Code sessions מכל דפדפן — כולל מהטלפון. זה אומר שאתה יכול להפעיל 3 worktrees ב-tmux על השרת, ולנטר את ההתקדמות מהטלפון בזמן שאתה בפגישה. אם session נתקע — אתה יכול לתת לו הנחיה מהטלפון בלי לפתוח SSH.

השילוב של tmux + worktrees + /color + Remote Control הוא ה-workflow הכי מתקדם לניהול מולטי-session: Sessions רצים מבודדים, ממשיכים ברקע, נראים טוב, וניתנים לניטור מכל מכשיר.

עשה עכשיו 2 דקות

באחד מה-sessions הפעילים שלך, הקלד /color ובחר צבע. ראה איך ה-prompt bar משתנה. אם יש לך יותר מ-session אחד פתוח — צבע כל אחד בצבע שונה. זו הרגל קטן שחוסך בלבול גדול.

מתקדם 10 דקות מושג + תרגול

/batch — Worktrees בקנה מידה

אם -w הוא ה"ידני" של worktrees, /batch הוא ה"אוטומטי". זה ה-Skill הכי עוצמתי שיש ב-Claude Code — הוא לוקח משימה גדולה, שובר אותה ליחידות עצמאיות, יוצר worktree לכל יחידה, מפעיל agent בכל אחד, וכל agent פותח PR בסוף. הוצג בפברואר 2026 (v2.1.63).

איך /batch עובד צעד אחר צעד

תהליך /batch מאחורי הקלעים

שלב 1: ניתוח — Claude סורק את ה-codebase ומבין את המבנה
שלב 2: פיצול — Claude יוצר תוכנית עבודה עם יחידות עצמאיות (עד 30)
שלב 3: Worktrees — לכל יחידה נוצר worktree ייעודי (דרך EnterWorktree)
שלב 4: Agents — agent אחד רץ בכל worktree ומבצע את המשימה
שלב 5: Tests — כל agent מריץ tests בתוך ה-worktree שלו
שלב 6: PRs — כל agent פותח Pull Request עם השינויים שלו
שלב 7: Review — אתה בודק ומאשר את ה-PRs

Use Cases שבהם /batch באמת זורח

Use Case תיאור יחידות צפויות
Large Refactors "Rename all instances of oldUserName to userName across 200 files" 10-20 יחידות (לפי תיקיות)
Code Migrations "Upgrade all React class components to functional components with hooks" 1 יחידה per component
Bulk Fixes "Add error handling to all API endpoints" 1 יחידה per endpoint
Test Coverage "Write unit tests for all untested utility functions" 1 יחידה per function file
Documentation "Add JSDoc comments to all exported functions" 1 יחידה per module

העלות של /batch

בואו נהיה ישירים: /batch הוא יקר. כל agent הוא session עצמאי שצורך tokens. המתמטיקה:

$15-60

עלות משוערת של /batch מלא (תלוי במודל, גודל כל unit, ומספר ה-units). 30 agents כפול $0.50-2.00 לכל agent. אבל אם משימת refactoring ידנית לוקחת 4-8 שעות ($200-400 בזמן מפתח) — ה-ROI מצוין. הכלל: אם המשימה תיקח לך יותר משעתיים ידנית, /batch כמעט תמיד שווה את זה. חשוב: בדוק תמחור עדכני — המחירים משתנים.

מגבלות /batch

מסגרת החלטה: "Batch Decision Matrix"

כמה קבצים? פחות מ-10 → עשה ידנית. 10-50 → שקול /batch. מעל 50 → /batch כמעט בוודאות.
עצמאות? כל שינוי עצמאי לחלוטין → /batch מושלם. תלויות מורכבות → אל תשתמש ב-/batch.
עלות ידנית? פחות משעה → עשה ידנית. מעל שעתיים → /batch. מעל 4 שעות → /batch בלי לחשוב פעמיים.

דוגמה מעשית: /batch על פרויקט אמיתי

דוגמאות מייצגות: Migration מ-JavaScript ל-TypeScript

המשימה: "Convert all 25 JavaScript API route handlers to TypeScript with full type safety"

מה /batch עושה:
1. סורק את src/routes/ ומוצא 25 קבצי .js
2. יוצר תוכנית: 25 יחידות, כל אחת = קובץ route אחד
3. יוצר 25 worktrees (כל אחד ב-.claude/worktrees/batch-route-X/)
4. 25 agents רצים במקביל. כל אחד:
  — משנה שם מ-.js ל-.ts
  — מוסיף type annotations
  — מתקן imports
  — מריץ tsc --noEmit לוודא שאין שגיאות
  — פותח PR
5. אחרי 15-20 דקות: 25 PRs מוכנים

העלות: ~$25 (25 agents כפול ~$1 לכל אחד) — משוער בהתבסס על תעריפים נוכחיים
הזמן שנחסך: migration ידנית של 25 קבצים = 4-6 שעות. /batch = 20 דקות + 30 דקות review = 50 דקות.

טיפ: התחל קטן

הריצה הראשונה של /batch עם 30 units היא מתכון לתסכול. התחל עם 5-10 units על משימה פשוטה (למשל "add logging to these 5 services"). למד את ה-workflow, הבן את ה-output, ורק אז הגדל ל-30.

עשה עכשיו 5 דקות

ב-session של Claude Code, הקלד /batch ותן משימה פשוטה: "Add a TODO comment at the top of every JavaScript file in the src/ directory". Claude יציג את תוכנית הפיצול ויבקש אישור. קרא את התוכנית לפני שאתה מאשר — זו ההזדמנות לראות איך /batch חושב. אם אין לך פרויקט JS — תאר פרויקט דמיוני ותראה את הניתוח.

בינוני 10 דקות תרגול

Workflows מעשיים למולטי-Session

עכשיו שיש לכם את כל הכלים — worktrees, -w, tmux, /batch — בואו נראה workflows מעשיים שאפשר ליישם מחר בבוקר.

כל workflow בנוי על אותו עיקרון: פרד את העבודה ליחידות עצמאיות, תן לכל יחידה worktree משלה, ואחד בסוף. ההבדל בין ה-workflows הוא סוג ההפרדה: לפי תפקיד (frontend/backend), לפי גישה (ניסוי A/B), לפי שלב (פיתוח/review), או לפי משימה (sprint tasks).

Workflow 1: Feature + Tests

דוגמאות מייצגות: Feature + Tests במקביל

Session 1 (worktree: feature-checkout)
"Implement the checkout flow: cart summary, address form, payment method selection, order confirmation"

Session 2 (worktree: tests-checkout)
"Write comprehensive tests for the checkout flow: unit tests for each component, integration tests for the full flow, edge cases for payment failures"

הסנכרון: שני ה-sessions עובדים על אותו branch base. כשמסיימים — merge שניהם ל-shared branch. ה-tests מכסים את ה-feature עוד לפני שהוא סיים להיכתב.

Workflow 2: Frontend + Backend

דוגמאות מייצגות: Frontend + Backend במקביל

Session 1 (worktree: worktree-api)
"Build the REST API for user management: CRUD endpoints, validation, authentication middleware"

Session 2 (worktree: worktree-ui)
"Build the user management UI: list page, edit form, profile page. Use TypeScript interfaces for API types"

הסנכרון: שתפו type definitions (TypeScript interfaces) בתיקייה משותפת. ה-frontend יכול לעבוד עם mock data עד שה-API מוכן. כשמסיימים — merge ל-development branch ובדקו אינטגרציה.

Workflow 3: Experiment with Multiple Approaches

דוגמאות מייצגות: ניסוי עם 3 גישות

Session 1 (worktree: approach-redis)
"Implement the caching layer using Redis"

Session 2 (worktree: approach-memcached)
"Implement the caching layer using Memcached"

Session 3 (worktree: approach-local)
"Implement the caching layer using in-memory LRU cache"

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

עשה עכשיו 2 דקות

לפני שממשיכים, רשום לעצמך: איזה feature בפרויקט הנוכחי שלך אפשר לפצל ל-2 חלקים עצמאיים? למשל: frontend + backend, feature + tests, או API + documentation. רשום את שני החלקים ואת ה-worktree names שהיית נותן להם. תשתמש בזה בתרגיל בהמשך.

Workflow 4: Review Pipeline

דוגמאות מייצגות: Code Review + Security + Performance

Session 1 (worktree: feature-work)
"Implement the new notification system"

Session 2 (worktree: review-security)
"Review the notification system for security vulnerabilities: injection, XSS, authentication bypass"

Session 3 (worktree: review-perf)
"Analyze the notification system for performance: database queries, N+1 problems, memory leaks"

התהליך: Session 1 מפתח. Sessions 2 ו-3 מנתחים את אותו branch. הם מייצרים דוחות עם ממצאים ותיקונים מוצעים. אתה מיישם את התיקונים לפני שפותחים PR.

מסגרת החלטה: איזה Workflow מתאים?

האם יש שני חלקים עצמאיים? → Feature + Tests / Frontend + Backend
האם יש כמה פתרונות אפשריים? → Experiment with Multiple Approaches
האם צריך בדיקת איכות? → Review Pipeline
האם יש 10+ שינויים חוזרניים? → /batch
האם זה שינוי בודד? → לא צריך worktree. פשוט תעבוד על main.

Workflow 5: Sprint Planning עם Worktrees

דוגמאות מייצגות: יום ספרינט עם 5 worktrees

בתחילת כל ספרינט (או תחילת שבוע עבודה), אפשר להגדיר worktrees מראש לכל משימה:

claude -w sprint-42-user-profile -n "Profile UX" — משימה 1: שיפור דף פרופיל
claude -w sprint-42-search-perf -n "Search Perf" — משימה 2: אופטימיזציית חיפוש
claude -w sprint-42-email-templates -n "Emails" — משימה 3: תבניות אימייל
claude -w sprint-42-bugfix-cart -n "Cart Bug" — משימה 4: באג בעגלת קניות
claude -w sprint-42-docs-api -n "API Docs" — משימה 5: תיעוד API

כל worktree מוכן ומחכה. במהלך הספרינט, כל מפתח (או Claude Code session) לוקח worktree ומתחיל לעבוד. כשמשימה מסתיימת — PR, review, merge, ניקוי. ועוברים למשימה הבאה.

עלות מול תועלת — חישוב ROI של עבודה מקבילית

הנה טבלה שמסכמת את ה-trade-offs:

Workflow עלות tokens (משוערת) זמן נחסך ROI
session בודד (בלי worktrees) $1-3 בסיס (0) —
2 sessions מקביליים $2-6 30-45 דקות מעולה: $3-6 חוסכים $25-50 בזמן מפתח
3-4 sessions מקביליים $4-12 1-2 שעות מעולה: $12 חוסכים $50-100
/batch עם 10 units $5-20 2-4 שעות טוב: תלוי בגודל המשימה
/batch עם 30 units $15-60 4-8 שעות טוב: רק למשימות גדולות

הכלל הפשוט: אם המשימה ידנית לוקחת יותר מפי 5 מעלות ה-tokens, עבודה מקבילית שווה את זה. שעת עבודה של מפתח ישראלי = 150-300 ש"ח. Session של Claude Code = 5-20 ש"ח. המתמטיקה ברורה.

חשוב גם לזכור: העלות האמיתית של עבודה סדרתית היא לא רק הזמן — זה גם ה-context switching. כל פעם שאתה עובר בין משימות, אתה מאבד 15-20 דקות של התמקדות. עם worktrees, אין context switching — כל session ממוקד במשימה שלו מתחילתה ועד סופה. זה חוסך לא רק זמן, אלא גם אנרגיה מנטלית.

עשה עכשיו 15 דקות

בחר אחד מחמשת ה-workflows ויישם אותו על הפרויקט שלך. הנה הצעה למי שלא בטוח: Workflow 3 — ניסוי עם 2 גישות. בחר בעיה קטנה בפרויקט שלך (למשל: מימוש פונקציית sorting). צור שני worktrees עם שתי גישות שונות. תן ל-Claude לממש כל גישה. השווה את התוצאות ובחר את הטובה.

בינוני 8 דקות מושג

טעויות נפוצות ואיך להימנע מהן

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

# הטעות מה קורה הפתרון
1 עריכת אותו קובץ בשני worktrees Merge conflict בלתי נמנע כשמנסים למזג לפני שפותחים worktrees, תכנן אילו קבצים כל session יערוך. הימנע מחפיפה
2 שכחת worktrees פתוחים Disk מתמלא בשקט. פתאום אין מקום שגרת ניקוי שבועית: git worktree list + remove
3 מחיקת branch לפני push Commits אבודים. עבודה שנעלמה כלל ברזל: תמיד push לפני delete
4 הרצת /batch על משימות תלויות Agents מייצרים קוד סותר. PRs לא ניתנים למיזוג וודא 100% עצמאות בין units. אם יש ספק — אל תשתמש ב-/batch
5 Merge מקומי במקום PR Worktrees אחרים רואים את השינוי ומתבלבלים תמיד merge דרך GitHub/GitLab PR, לא git merge מקומי
6 יותר מדי sessions במקביל לא מצליחים לעקוב. PRs נערמים. Review backlog הגבל ל-3-5 sessions. יותר רק עם /batch (שם ה-review הוא אחרי)
7 שכחת sparse checkout למונורפו כל worktree = GB שלמים. Disk נגמר במהירות הגדר worktree.sparsePaths ב-settings.json
אזהרה: הטעות הכי יקרה

הטעות שעולה הכי הרבה כסף: להריץ /batch עם 30 units ולגלות אחרי 15 דקות שהיחידות לא באמת עצמאיות. אתה משלם על 30 sessions שמייצרים קוד שלא ניתן למזג. תמיד בדוק את תוכנית הפיצול של /batch לפני שמאשר. כמה דקות של בדיקה חוסכות עשרות דולרים ושעה של review מיותר.

Troubleshooting מהיר

בעיה פתרון
"fatal: branch already checked out" ה-branch כבר פתוח ב-worktree אחר. השתמש בשם אחר או מחק את ה-worktree הקודם
Worktree לא נמחק ("in use") סגור קודם את ה-Claude Code session שרץ בו, ואז הרץ git worktree remove
ההגדרות לא נטענות ב-worktree וודא שאתה בגרסה v2.1.63+. בגרסאות ישנות יותר, שיתוף הגדרות לא נתמך
Disk מלא אחרי /batch git worktree list + git worktree remove לכל worktree שלא צריך + git worktree prune
מתחיל 8 דקות תרגול

ניקוי וניהול Worktrees

Worktrees צורכים disk space. כל worktree הוא כמעט עותק מלא של הפרויקט (מינוס תיקיית .git שמשותפת). פרויקט של 500MB עם 5 worktrees = 2.5GB+. חייבים לנקות.

פקודות ניקוי

פקודה מה עושה מתי
git worktree list מציג את כל ה-worktrees הפעילים, עם הנתיב וה-branch כדי לראות מה פתוח
git worktree remove <path> מוחק worktree ומשחרר את ה-branch אחרי merge של ה-branch
git worktree prune מנקה entries של worktrees שהתיקייה שלהם נמחקה אחרי מחיקה ידנית של תיקייה

הזרימה הנכונה לניקוי

Cleanup Flow

1. git worktree list — ראה מה פתוח
2. בדוק: האם ה-branch של ה-worktree כבר merged?
3. אם כן: git worktree remove .claude/worktrees/feature-name
4. אם לא: האם עדיין צריך אותו? אם כן — השאר. אם לא — merge או מחק
5. git worktree prune — נקה entries מיותמים
6. git branch -d cc/feature-name — מחק את ה-branch אם לא צריך אותו יותר

מתי לנקות

מסגרת החלטה: ניקוי Worktrees

ה-branch עבר merge? → נקה מיד. אין סיבה להשאיר.
ה-branch לא עבר merge, אבל לא עבדת עליו שבוע? → Push לרמוט ונקה. אפשר לשחזר מ-remote.
ה-branch פעיל ואתה עובד עליו היום? → השאר. לא לנקות worktrees פעילים.
הניסוי נכשל? → נקה מיד. אל תשאיר worktrees של ניסויים כושלים.

סקריפט ניקוי אוטומטי

אם אתה משתמש ב-worktrees באופן קבוע, כדאי ליצור סקריפט שמנקה אוטומטית worktrees שכבר עברו merge. הנה סקריפט פשוט:

סקריפט Cleanup (שמור כ-cleanup-worktrees.sh)

#!/bin/bash
# Cleanup merged worktrees
echo "Active worktrees:"
git worktree list
echo ""

# Find worktrees with merged branches
for wt in $(git worktree list --porcelain | grep "^worktree" | awk '{print $2}'); do
  branch=$(git -C "$wt" branch --show-current 2>/dev/null)
  if [ -n "$branch" ] && git branch --merged main | grep -q "$branch"; then
    echo "MERGED: $wt (branch: $branch) — safe to remove"
  fi
done

# Prune stale entries
git worktree prune
echo "Pruned stale worktree entries."

הסקריפט מציג את כל ה-worktrees הפעילים, מזהה את אלה שה-branch שלהם כבר merged ל-main, ומנקה entries מיותמים. אתה מחליט מה למחוק.

טיפ: Hook לניקוי אוטומטי

אפשר לשלב את סקריפט הניקוי כ-Hook ב-Claude Code. הגדר Hook מסוג SessionEnd שמריץ את הסקריפט — ככה כל פעם שסוגרים session, worktrees ישנים מנוקים אוטומטית. חברו את מה שלמדתם בפרק 1 (Hooks) למה שלמדתם פה.

אזהרה: Disk Space

כל worktree הוא כמעט עותק מלא של הפרויקט. 10 worktrees = 10x ב-disk (מינוס .git שמשותף). בפרויקטים גדולים, worktrees ישנים יכולים לאכול עשרות GB. שגרת ניקוי שבועית היא חובה — לא אופציה.

מה קורה אם מחקת worktree בטעות

אל פאניקה. מחיקת worktree לא מוחקת את ה-branch. ה-branch עדיין קיים ב-Git. מה שנמחק זה רק ה-working directory. אתה תמיד יכול:

הבעיה האמיתית היא מחיקת branch (git branch -D) לפני שדחפת. זו פעולה הרסנית שיכולה לאבד commits. הכלל: תמיד push לפני delete.

עשה עכשיו 3 דקות

הרץ git worktree list ובדוק אם נשארו worktrees מהתרגילים הקודמים בפרק. אם כן, נקה אותם: git worktree remove .claude/worktrees/test-worktree (ואת כל שאר ה-worktrees שיצרת לתרגול). סיים עם git worktree prune.

בינוני-מתקדם 35 דקות תרגול

תרגילים מעשיים

תרגיל 1: הקמת Parallel Development Environment

תרגיל: בנה סביבת עבודה מקבילית מלאה
  1. צור פרויקט Git חדש (או השתמש בקיים) עם לפחות 3 קבצים
  2. התקן tmux אם עדיין לא מותקן
  3. צור tmux session בשם "parallel-dev" עם 3 panes
  4. בכל pane הרץ claude -w עם שם שונה: feature-a, feature-b, feature-c
  5. בכל session בקש מ-Claude לבצע שינוי שונה (למשל: הוספת פונקציה, תיקון באג, שינוי README)
  6. צבע כל session עם /color אחר
  7. ודא ששלושת ה-sessions עובדים במקביל בלי התנגשות
  8. נקה את כל ה-worktrees בסיום

התוצאה: סביבת עבודה מקבילית מלאה עם ניטור ויזואלי.

תרגיל 2: ניסוי A/B עם Worktrees

תרגיל: השווה שתי גישות לבעיה אחת
  1. בחר בעיה קטנה בפרויקט שלך (או צור בעיה מלאכותית: "implement a function that sorts an array of objects by multiple keys")
  2. צור שני worktrees: claude -w approach-iterative ו-claude -w approach-recursive
  3. בכל worktree, בקש מ-Claude לממש את הפתרון בגישה שונה
  4. בכל worktree, בקש מ-Claude לכתוב benchmark test
  5. השווה: ביצועים, קריאות הקוד, מורכבות (Big-O), אורך הקוד
  6. בחר גישה מועדפת, merge אותה, ומחק את שאר ה-worktrees

התוצאה: החלטה מושכלת מבוססת נתונים על הגישה הטובה.

תרגיל 3: /batch על משימה אמיתית

תרגיל: השתמש ב-/batch לשינוי רחב היקף
  1. בחר פרויקט עם לפחות 5 קבצים דומים (למשל: 5 route handlers, 5 React components, 5 test files)
  2. הגדר משימה חוזרנית שצריכה לקרות לכל קובץ (למשל: "add error handling", "add TypeScript types", "add JSDoc comments")
  3. הרץ /batch עם תיאור המשימה
  4. קרא את תוכנית הפיצול של Claude — וודא שהיחידות הגיוניות
  5. אשר את ההרצה
  6. כשה-PRs מוכנים — בדוק כל אחד. סמן מה טוב ומה צריך תיקון
  7. Merge את ה-PRs הטובים, תקן ידנית את השאר

התוצאה: ניסיון מעשי עם /batch, כולל review של PRs מרובים.

תרגיל 4: Sparse Checkout למונורפו

תרגיל: הגדר sparse checkout
  1. צור מבנה מונורפו פשוט: packages/frontend/, packages/backend/, packages/shared/, config/
  2. הוסף כמה קבצים בכל תיקייה (אפילו קבצי דמה)
  3. הגדר worktree.sparsePaths ב-settings.json: ["packages/frontend/", "packages/shared/"]
  4. צור worktree: claude -w frontend-feature
  5. בדוק: האם רק packages/frontend/ ו-packages/shared/ קיימים ב-worktree?
  6. בקש מ-Claude לערוך קובץ ב-packages/frontend/ — צריך לעבוד
  7. נקה הכל בסיום

התוצאה: הבנה מעשית של sparse checkout וחיסכון ב-disk.

תרגיל בונוס: סקריפט ניקוי Worktrees

תרגיל: כתוב סקריפט ניקוי אוטומטי
  1. צור קובץ scripts/cleanup-worktrees.sh בפרויקט שלך
  2. הסקריפט צריך: להריץ git worktree list, לזהות worktrees שה-branch שלהם כבר merged, ולהציע למחוק אותם
  3. הוסף שאלת אישור ("?Delete X? [y/N]") לפני כל מחיקה
  4. הוסף git worktree prune בסוף
  5. בדוק שהסקריפט עובד על ה-worktrees מהתרגילים הקודמים
  6. בונוס: הגדר Hook מסוג SessionEnd שמריץ את הסקריפט אוטומטית

התוצאה: סקריפט ניקוי שאפשר להריץ בסוף כל יום עבודה.

שגרת עבודה עם Worktrees

שגרת עבודה — Worktrees (בנוסף לשגרות מפרקים 1-5)
תדירות משימה זמן
יומי בדיקה: כמה worktrees פתוחים? יש כאלה שסיימו ואפשר לנקות? 2 דקות
יומי push שינויים מ-worktrees פעילים לרמוט — כדי שלא תאבד עבודה 1 דקה
שבועי ניקוי worktrees ישנים: git worktree list, remove merged, prune stale 5 דקות
שבועי בדיקת disk usage: כמה מקום ה-worktrees תופסים? הגיוני? 2 דקות
חודשי סקירת workflows: האם Parallel Development משתלם? כמה זמן/כסף חסכתי? 10 דקות
חודשי עדכון sparse paths אם מבנה המונורפו השתנה 5 דקות
טעות נפוצה: עריכת אותו קובץ בשני Worktrees

הטעות: לפתוח שני worktrees שעובדים על אותם קבצים (למשל config.ts או index.ts). למה מפתה: כי שני ה-features "עצמאיים" אבל יש להם shared dependencies. מה לעשות במקום: לפני שפותחים worktrees, תכנן אילו קבצים כל session יערוך. אם שני sessions צריכים את אותו קובץ — עשה merge ידני אחרי שהראשון מסיים, לפני שהשני מתחיל.

טעות נפוצה: הרצת /batch על משימות תלויות

הטעות: להריץ /batch עם 30 units ולגלות אחרי 15 דקות שהיחידות לא באמת עצמאיות. למה מפתה: כי /batch נראה כמו "קסם" — 30 agents עובדים במקביל, מה יכול להשתבש? מה לעשות במקום: תמיד בדוק את תוכנית הפיצול לפני שמאשר. אם יחידה 5 תלויה בתוצאה של יחידה 3, הן לא יכולות לרוץ במקביל. כמה דקות של בדיקה חוסכות עשרות דולרים ושעה של review מיותר.

טעות נפוצה: שכחת Worktrees פתוחים

הטעות: ליצור worktrees "לניסוי" ולשכוח אותם. שבועיים אחרי, ה-disk מלא ואתה לא מבין למה. למה מפתה: כי worktrees כל כך קלים ליצירה (פקודה אחת) שלא מרגישים את העלות. מה לעשות במקום: שגרת ניקוי שבועית: git worktree list כל יום שישי, remove worktrees שהסתיימו, prune entries מיותמים. בפרויקט של 1GB, 10 worktrees שכוחים = 10GB מיותרים.

אם אתם עושים רק דבר אחד מהפרק הזה

אם אתם עושים רק דבר אחד מהפרק הזה 10 דקות

הריצו שני sessions של Claude Code במקביל עם -w. לא צריך tmux. לא צריך /batch. לא צריך sparse checkout. פשוט פתחו שני טרמינלים, הריצו claude -w feature-a באחד ו-claude -w feature-b בשני, ותנו לשניהם לעבוד. ברגע שתראו את הקסם הזה — שני agents עובדים על הפרויקט שלכם בו-זמנית, בלי התנגשות — לא תחזרו לעבודה סדרתית.

בדוק את עצמך — 5 שאלות

בדוק את עצמך — 4 מתוך 5 = עברת
  1. למה worktrees עדיפים על git stash + branch switch כשעובדים עם Claude Code? (רמז: חשוב על context של ה-session ועל עבודה מקבילית)
  2. מה היתרון של sparse checkout מעבר לחיסכון ב-disk? (רמז: חשוב על מה Claude Code "רואה" כשסורק את ה-worktree)
  3. למה חשוב לבדוק את תוכנית הפיצול של /batch לפני שמאשרים? (רמז: מה קורה כשיחידות הן לא באמת עצמאיות)
  4. מה ההבדל בין -w (flag) לבין EnterWorktree (tool), ומתי משתמשים בכל אחד? (רמז: מי המפעיל — המשתמש או Claude)
  5. איך שיתוף הגדרות (v2.1.63) משפיע על ה-workflow של worktrees? (רמז: חשוב על מה קורה עם Hooks, Plugins ו-CLAUDE.md)
מילון מונחים — פרק 6
מונח באנגלית תרגום/הסבר בעברית
Git Worktree עותק עבודה — תיקייה נפרדת שמקושרת לאותו repository, עם branch משלה
-w / --worktree פלאג של Claude Code שיוצר worktree, branch ו-session בפקודה אחת
Parallel Development פיתוח מקבילי — עבודה על כמה features בו-זמנית, כל אחד ב-worktree נפרד
Sparse Checkout בחירה דלילה — טעינת חלק מהקבצים בלבד, במקום כל הפרויקט
sparsePaths הגדרה ב-settings.json שמציינת אילו תיקיות לטעון ב-sparse checkout
EnterWorktree כלי פנימי — מאפשר ל-Claude ליצור ולהיכנס ל-worktree באופן פרוגרמטי
ExitWorktree כלי פנימי — מאפשר ל-Claude לצאת מ-worktree ולחזור לתיקייה המקורית
tmux מכפל טרמינל — כלי שמאפשר לנהל כמה sessions בחלון טרמינל אחד
Pane חלונית — אזור בודד בתוך tmux שבו רץ טרמינל עצמאי
/batch Skill מובנה שמפצל משימה גדולה ל-30 יחידות, כל אחת ב-worktree עם agent
/color פקודה שמשנה את צבע ה-prompt bar — לזיהוי ויזואלי בין sessions
-n (session naming) פלאג לתת שם תיאורי ל-session — מופיע בכותרת וב-Remote Control
cc/ prefix תחילית — branches שנוצרים דרך -w מקבלים prefix של cc/
Detach ניתוק — ב-tmux, ניתוק מה-session בלי לסגור אותו (הוא ממשיך לרוץ)
Merge Conflict התנגשות מיזוג — כשעורכים אותו קובץ בשני worktrees ומנסים למזג
Remote Control ניטור וכיוון של Claude Code sessions מדפדפן/טלפון מרחוק (פברואר 2026)
מתחיל 3 דקות תרגול

צ'קליסט סיכום וצעד הבא

צ'קליסט — סיכום פרק 6

סיכום הפרק

Worktrees הם מכפיל הכוח של Claude Code. במקום לעבוד סדרתית — feature, switch, bugfix, switch back — אתם פותחים "יקומים מקבילים" שכל אחד מהם רץ בנפרד. התובנה המרכזית: צוואר הבקבוק של פיתוח עם AI הוא לא מהירות ה-AI, אלא כמה דברים אתם יכולים להריץ במקביל. עם -w לעבודה ידנית, /batch לאוטומציה מלאה, sparse checkout למונורפוס, ו-tmux לניטור — יש לכם toolkit שלם לפיתוח מקבילי. כל מה שהגדרתם בפרקים הקודמים (Hooks, Agents, Skills, Plugins) עובד אוטומטית בכל worktree. בפרק הבא נעבור ל-Memory and Persistence — ונבין בדיוק איך שיתוף הזיכרון בין worktrees עובד מתחת למכסה המנוע.