2 שלב הבסיס

Git Essentials with Claude Code — גיט: הסוד של כל מפתח

בפרק הזה תלמדו את Git — מערכת ניהול הגרסאות שעומדת מאחורי כל פרויקט תוכנה בעולם. החדשות הטובות? Claude Code מטפל ב-90% מהעבודה בשבילכם. אתם צריכים להבין את הרעיון ולדעת 10 פקודות. זה הכל.

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

בפרק 1 הבנתם מה זה Vibe Coding, בחרתם את הפרויקט הראשון שלכם, וכתבתם Project Brief של 3-5 משפטים שמתאר מה לבנות, למי, ולמה. בפרק הזה נגדיר את התשתית שכל פרויקט שתבנו ישב עליה — Git ו-GitHub, מערכת ניהול הגרסאות שמאפשרת לגבות, לחזור אחורה, ולפרוס לאינטרנט. בפרק 3 תיקחו את ה-Project Brief ואת תשתית ה-Git ותבנו את האתר הראשון — מאפס ל-URL חי.

מילון מושגים — Git Essentials
מושג באנגלית מה זה בעברית אנלוגיה פשוטה
Git מערכת ניהול גרסאות כמו "היסטוריית גרסאות" ב-Google Docs, אבל לכל סוגי הקבצים
Repository (Repo) מאגר קוד תיקיית פרויקט ש-Git עוקב אחריה
Commit שמירה / תיעוד שינוי כמו "שמור בשם" עם תיאור של מה שינית
Branch ענף גרסה מקבילה של הקוד — עובדים עליה בלי לסכן את המקור
Remote מאגר מרוחק העותק של הפרויקט שלך באינטרנט (GitHub)
Push דחיפה / העלאה שליחת השינויים שלך מהמחשב ל-GitHub
Pull משיכה / הורדה הורדת שינויים מ-GitHub למחשב שלך
Merge מיזוג חיבור שני ענפים לאחד
Clone שכפול הורדת עותק מלא של repo מ-GitHub למחשב
.gitignore קובץ התעלמות רשימת קבצים ש-Git צריך להתעלם מהם (סודות, תלויות)
Staging Area אזור ההכנה קבצים שסימנת ל-commit הבא (אבל עוד לא שמרת)
Checkpoint נקודת שמירה אוטומטית שמירה שנוצרת ב-Claude Code בכל פרומפט שאתה שולח
מתחיל 15 דקות חינם מושג

למה Git חשוב ל-Vibe Coders

93.9%

מהמפתחים בעולם משתמשים ב-Git כמערכת ניהול הגרסאות שלהם (סקר Stack Overflow / RhodeCode, 2025). זו לא בחירה — זו ברירת המחדל של התעשייה כולה. כ-Vibe Coder, ללמוד Git זה כמו ללמוד לנהוג: פעם אחת, ומשם — זה מלווה אותך בכל פרויקט.

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

תחשוב על Git כמו "שמור בשם" (Save As) אבל הרבה יותר חכם. בלי Git, אתה עובד כמו שרוב האנשים עובדים עם מסמכי Word: שומרים קבצים כמו presentation_v2_final_FINAL_REALLY_FINAL.docx, ובמפתח רגע של פאניקה מוחקים את הגרסה הלא-נכונה. עם Git, כל גרסה נשמרת אוטומטית עם תיאור ברור, תאריך מדויק, ואפשרות לחזור אליה בלחיצת כפתור.

בלי Git — תרחיש הסיוט

בואו נתאר מה קורה כש-Vibe Coder עובד בלי Git:

עם Git — מה משתנה

90%

מפעולות ה-Git ש-Claude Code עושה בשבילך אוטומטית. אתה צריך להבין את הרעיון ולהגיד לו מה לעשות — הוא מריץ את הפקודות, כותב את הודעות ה-commit, ומטפל בכל הפרטים הטכניים.

האנלוגיה הכי טובה: Git הוא כמו היסטוריית גרסאות ב-Google Docs. אתה יכול לראות כל שינוי, מי עשה אותו, ולשחזר כל גרסה קודמת. אבל בניגוד ל-Google Docs, Git עובד על כל סוג של קובץ (HTML, CSS, JavaScript, Python, תמונות, ועוד), על כל גודל של פרויקט (מאתר חד-דפי ועד מערכת עם אלפי קבצים), ועם כלים שמאפשרים לפרוס את הקוד ישירות לאינטרנט — מה ש-Google Docs לא יכול לעשות.

למה כל פלטפורמת Deploy דורשת Git?

Vercel, Netlify, Cloudflare Pages, Railway, Render — כל פלטפורמות ה-Deploy המודרניות עובדות באותו עיקרון: אתה מחבר את ה-Git repository שלך, וכל פעם שאתה עושה git push, הפלטפורמה בונה ומפרסמת את הגרסה החדשה אוטומטית. זה נקרא Continuous Deployment — פריסה רציפה.

בלי Git, אין Deploy אוטומטי — ובלי Deploy אוטומטי, אתה חוזר לשיטה הישנה של העלאת קבצים ידנית עם FTP. אם מישהו אי פעם סיפר לך על הזמנים הישנים של "להעלות קבצים לשרת," תדע שזה היה סיוט: שכחת קובץ? האתר שבור. העלית גרסה ישנה בטעות? האתר שבור. שינית משהו בשרת ולא במחשב? שכחת מה שינית. Git פתר את כל הבעיות האלה — ובפרק הזה נוודא שאתה יודע להשתמש בו.

הדבר הכי חשוב לזכור מהסעיף הזה

אתה לא צריך להיות מומחה ב-Git. אתה לא צריך לזכור פקודות. אתה צריך להבין את הרעיון: Git שומר כל שינוי, מאפשר חזרה אחורה, ומחבר את הפרויקט שלך ל-Deploy. Claude Code מטפל בכל השאר. עשר פקודות והבנה בסיסית — זה הכל.

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

Git מאפס: המושגים הבסיסיים

לפני שנריץ פקודות, בואו נבין את הרעיונות. ברגע שתבינו את חמשת המושגים הבאים, כל השאר — הפקודות, הכלים, ה-Deploy — פשוט יסתדר. בלי ההבנה הזו, גם עם Claude Code, תרגישו אבודים.

Repository (Repo) — מאגר קוד

Repository (בקיצור: repo) הוא פשוט תיקיית פרויקט ש-Git עוקב אחריה. כל פרויקט שתבנו בקורס הזה יהיה repo נפרד. כשאתה אומר ל-Claude Code "create a new project," הוא יוצר תיקייה ומפעיל בתוכה Git — וזה ה-repo שלך.

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

Commit — שמירה עם תיאור

Commit הוא "תמונת מצב" (snapshot) של הקוד שלך ברגע מסוים. כל commit כולל שלושה דברים: מה שינית (אילו קבצים, אילו שורות), מתי שינית (תאריך ושעה), ותיאור קצר של השינוי שכתבת בעצמך (או ש-Claude כתב בשבילך).

הנה דוגמאות להודעות commit טובות:

שימו לב לתבנית: פועל (Add, Fix, Update, Remove) + תיאור קצר של מה שינית. זה מספיק. אתם לא כותבים חיבור — אתם כותבים תזכורת עתידית לעצמכם.

כל commit הוא נקודת שמירה שאפשר לחזור אליה. ככל שתעשו יותר commits, יהיו לכם יותר נקודות שמירה — ויותר אפשרויות לשחזור אם משהו ישתבש. commit כל 15-30 דקות עבודה זה קצב סביר.

Branch — ענף

Branch הוא גרסה מקבילה של הקוד שלך. דמיינו עץ: הגזע (main branch) הוא הקוד היציב שלכם — הגרסה שעובדת ומופיעה באתר החי. ענפים (feature branches) גדלים מהגזע — כל אחד מכיל שינוי או פיצ'ר חדש. כשהפיצ'ר מוכן ובדוק, ממזגים (merge) את הענף חזרה לגזע.

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

Remote — מאגר מרוחק (GitHub)

ה-Remote הוא העותק של הפרויקט שלך באינטרנט. בפועל, זה ה-repository שלך ב-GitHub. המחשב שלך מכיל עותק מקומי (local), ו-GitHub מכיל עותק מרוחק (remote). שני העותקים מסונכרנים באמצעות הפקודות push (העלאה) ו-pull (הורדה).

למה צריך remote? שלוש סיבות: (1) גיבוי — אם המחשב נהרס, הקוד בטוח ב-GitHub; (2) Deploy — הפלטפורמות מתחברות ל-GitHub ופורסות אוטומטית; (3) ניידות — אתה יכול לעבוד מכל מכשיר שמחובר ל-GitHub.

Push / Pull — דחיפה ומשיכה

Push = שולח את השינויים שלך מהמחשב ל-GitHub. כל ה-commits שעשית מקומית "עולים" ל-remote. Pull = מוריד שינויים מ-GitHub למחשב. שימושי כשעבדת ממכשיר אחר, או כשמישהו אחר עשה שינויים.

הזרימה היומיומית: אתה עובד על הקוד → עושה commit (שמירה מקומית) → עושה push (העלאה ל-GitHub). אם אתה עובר למחשב אחר, אתה עושה pull קודם כדי לקבל את הגרסה האחרונה, ואז ממשיך לעבוד.

המודל המנטלי: שלושה "אזורים" שכל שינוי עובר דרכם

ב-Git יש שלושה אזורים שכל שינוי עובר דרכם. זה נשמע מסובך, אבל זה ממש פשוט:

אזור שם באנגלית מה קורה שם אנלוגיה
1. אזור העבודה Working Directory הקבצים שאתה עורך עכשיו שולחן העבודה שלך — כאן אתה עובד
2. אזור ההכנה Staging Area קבצים שסימנת ל-commit הבא קופסה שאתה ממלא — מה ייכנס לשמירה הבאה
3. המאגר Repository ההיסטוריה השמורה — כל ה-commits הארכיון — כל השמירות שלך מסודרות לפי תאריך

הזרימה: אתה עורך קבצים (Working Directory) → מסמן אותם לשמירה עם git add (Staging Area) → שומר עם git commit (Repository) → שולח ל-GitHub עם git push (Remote). ארבעה צעדים — זה הכל.

למה יש Staging Area ולא שומרים ישירות? כי לפעמים שינית 5 קבצים אבל רוצה לשמור רק 3 מהם ב-commit הנוכחי. ה-Staging Area מאפשר לך לבחור מה נכנס ומה לא. בפועל, כ-Vibe Coder, רוב הזמן תעשה git add . (הנקודה = "הכל") — אבל טוב לדעת שיש אפשרות לבחור.

המודל המנטלי שלך — שמור את זה

תחשוב על Git כמו מכונת זמן לקוד שלך — אתה יכול לחזור לכל רגע בעבר. כל commit הוא "תחנה" במכונת הזמן, כל branch הוא "מציאות מקבילה" שבה אתה יכול לנסות דברים בלי לסכן את ההווה, ו-GitHub הוא "הכספת" שמחזיקה את מכונת הזמן שלך מגובה בענן.

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

פתח terminal (או VS Code terminal) והריץ git --version כדי לוודא ש-Git מותקן על המחשב שלך. אם אתה רואה מספר גרסה (למשל, git version 2.43.0) — מעולה, Git מותקן ואפשר להמשיך. אם לא, פתח Claude Code והקלד: "Help me install git on my computer" — הוא יזהה את מערכת ההפעלה שלך ויתקין.

מתחיל 20 דקות חינם הקמה

הקמת חשבון GitHub

GitHub הוא האתר שמאחסן את ה-repositories שלך באינטרנט. חשוב להבין את ההבדל: Git הוא הכלי שרץ על המחשב שלך ומנהל את הגרסאות; GitHub הוא האתר שמאחסן את הקוד בענן ומספק ממשק ויזואלי לצפייה בפרויקטים. יש אלטרנטיבות כמו GitLab ו-Bitbucket, אבל GitHub הוא הדומיננטי בהפרש עצום — יותר מ-150 מיליון מפתחים (נכון ל-2025, והמספר ממשיך לגדול), וכל פלטפורמות ה-Deploy תומכות בו באופן מלא.

יצירת חשבון — צעד אחר צעד

1

הירשם ל-GitHub

גש ל-github.com ולחץ על "Sign up". בחר שם משתמש (username) — זה יהיה חלק מכתובות ה-repos שלך (למשל, github.com/your-username/my-project). בחר שם שמייצג אותך — מקצועי, קצר, וקל לזכור. השתמש באימייל אמיתי — תצטרך אותו לאימות דו-שלבי (2FA) ולשחזור סיסמה.

2

הגדר את הפרופיל

לכו ל-Settings → Profile. הוסיפו שם מלא, תמונת פרופיל, ו-bio (תיאור קצר). גם אם אתם Vibe Coders ולא מפתחים "קלאסיים," הפרופיל הזה חשוב. מי שיראה את הפרויקטים שלכם — לקוחות, שותפים פוטנציאליים, מעסיקים — יראה גם את הפרופיל. bio קצר כמו "Building web products with Claude Code | Marketing professional" מספיק בהחלט.

3

הגדר SSH key לאימות

SSH key הוא מפתח הצפנה שמאפשר למחשב שלך לתקשר עם GitHub בצורה מאובטחת — בלי להקליד שם משתמש וסיסמה כל פעם שאתה עושה push או pull. זה כמו מפתח דיגיטלי שמזהה את המחשב שלך. ההגדרה נעשית פעם אחת — ומשם זה עובד אוטומטית.

הדרך הקלה ביותר להגדיר: פתח Claude Code והקלד "Help me set up SSH key for GitHub". Claude יריץ את ssh-keygen ליצירת מפתח, יציג לך את המפתח הציבורי, ויגיד לך בדיוק מה להדביק ב-GitHub (Settings → SSH and GPG keys → New SSH key). בסוף, הוא יריץ ssh -T git@github.com כדי לוודא שהחיבור עובד.

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

צור חשבון GitHub אם עדיין אין לך, והגדר SSH key עם Claude Code. הנה בדיוק מה לעשות:

שלב 1: גש ל-github.com וצור חשבון (או התחבר אם יש לך)
שלב 2: פתח Claude Code והקלד:
"Help me set up SSH key for GitHub and test the connection"
שלב 3: Claude יראה לך את המפתח הציבורי. העתק אותו.
שלב 4: ב-GitHub, לך ל-Settings → SSH and GPG keys → New SSH key. הדבק את המפתח ושמור.
שלב 5: חזור ל-Claude Code — הוא יריץ ssh -T git@github.com. אם אתה רואה "Hi username! You've been authenticated" — הצלחת.

GitHub Free Tier — מה מקבלים בחינם

חדשות טובות: ה-Free tier של GitHub מספיק לחלוטין לכל מה שנעשה בקורס הזה — ולרוב גם הרבה מעבר:

תכונה Free Tier הערה
Repos פרטיים ללא הגבלה כל הפרויקטים שלך יכולים להיות פרטיים
Repos ציבוריים ללא הגבלה טוב לפורטפוליו ולפרויקטים שרוצים לשתף
GitHub Packages (אחסון חבילות) 500MB ל-repos עצמם יש מגבלה רכה של כ-5GB — מספיק בהחלט לכל פרויקט
GitHub Actions (CI/CD) 2,000 דקות בחודש לבדיקות אוטומטיות ו-Deploy
GitHub Pages אתרים סטטיים חינם אפשרות נוספת ל-hosting פשוט
Collaborators ללא הגבלה אפשר להזמין שותפים לכל repo

בשורה התחתונה: לא צריך לשלם. GitHub Free מספיק ל-99% מה-Vibe Coders.

טיפ — פרטיות אימייל

השתמש באימייל אמיתי ל-GitHub — תצטרך אותו לאימות ולשחזור. אבל אם אתה רוצה פרטיות, GitHub מאפשר להסתיר את האימייל מ-commits: לך ל-Settings → Emails → סמן "Keep my email address private" ו-"Block command line pushes that expose my email". ככה ה-commits שלך ישתמשו באימייל אנונימי של GitHub במקום באימייל האמיתי שלך.

טיפ — GitHub vs Git: עוד פעם, ברור

Git = כלי שרץ על המחשב שלך. GitHub = אתר שמאחסן את הקוד בענן. אתה יכול להשתמש ב-Git בלי GitHub (רק מקומית), אבל אתה לא יכול להשתמש ב-GitHub בלי Git (כי ככה מעלים ומורידים קוד). בקורס הזה נשתמש בשניהם תמיד — Git מקומית, GitHub בענן.

מתחיל 30 דקות חינם תרגול

ה-Repository הראשון שלך: Init, Add, Commit, Push

הגענו לחלק המעשי. כאן תיצרו את ה-repository הראשון שלכם — מאפס ועד push ל-GitHub. ארבע פקודות שמכסות 80% מכל השימוש ב-Git. ארבע. לא ארבעים, לא מאה. ארבע.

ארבע הפקודות — The Core Four

1

git init — התחלת מעקב

הפקודה הזו אומרת ל-Git: "תתחיל לעקוב אחרי התיקייה הזו מעכשיו." היא יוצרת תיקיית .git מוסתרת שמכילה את כל ההיסטוריה של הפרויקט. אתה מריץ את הפקודה פעם אחת בלבד — בהתחלה של כל פרויקט חדש. אם אתה שוכח — אין בעיה. כש-Claude Code יוצר פרויקט חדש, הוא מריץ git init אוטומטית.

2

git add . — סימון לשמירה (Staging)

הנקודה (.) אומרת "כל הקבצים שהשתנו." הפקודה מעבירה את הקבצים מה-Working Directory ל-Staging Area — כלומר, "הקבצים האלה מוכנים לשמירה הבאה." אפשר גם לסמן קבצים ספציפיים: git add index.html style.css — אבל רוב הזמן, git add . (הכל) הוא מה שתשתמשו בו.

3

git commit -m "description" — שמירה עם תיאור

הפקודה הזו שומרת "תמונת מצב" של כל הקבצים שסימנתם. ה--m (message) מתייחס לתיאור — משפט קצר שמסביר מה שינית ולמה. תמיד כתבו message ברור ותיאורי: "Add contact page with form" ולא "stuff" או "changes". ה-message הזה הוא מה שיעזור לכם (או ל-Claude) להבין את ההיסטוריה בעתיד.

4

git push — העלאה ל-GitHub

שולח את כל ה-commits המקומיים ל-GitHub. אחרי push, הקוד שלכם מגובה בענן, אפשר לגשת אליו מכל מכשיר, וכל מי שמחובר ל-repo יכול לראות את השינויים. אם חיברתם Vercel — האתר החי מתעדכן אוטומטית תוך שניות מה-push.

דוגמה מלאה — מה קורה כשאומרים ל-Claude "Create a new project"

כשאתה אומר ל-Claude Code:
"Create a new project called hello-world, initialize git, create an index.html with a hello world page, and push it to a new GitHub repo"

הנה בדיוק מה שקורה מאחורי הקלעים — שבע פקודות ש-Claude מריץ בשבילך:

1. mkdir hello-world && cd hello-world — יוצר תיקייה חדשה ונכנס אליה
2. git init — מפעיל Git בתיקייה
3. יוצר את index.html עם תוכן HTML שלם
4. git add . — מסמן את כל הקבצים לשמירה
5. git commit -m "Initial commit: hello world page" — שומר את השינויים
6. gh repo create hello-world --public --source=. — יוצר repo ב-GitHub באמצעות ה-CLI של GitHub
7. git push -u origin main — מעלה הכל ל-GitHub

שבע פקודות — ואתה כתבת משפט אחד באנגלית (או בעברית). זה Vibe Coding עם Git.

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

הגיע הזמן ליצור את ה-repo הראשון שלך. פתח Claude Code והקלד:

"Create a new project folder called hello-world in ~/projects, initialize git, create an index.html with a basic hello world page that includes my name, and push it to a new public GitHub repo"

מה לבדוק אחרי שסיים:
1. גש ל-GitHub ותוודא שה-repo hello-world נוצר ויש בו את index.html
2. לחץ על הקובץ ב-GitHub כדי לראות את התוכן
3. פתח את ~/projects/hello-world/index.html בדפדפן ותראה את הדף

מזל טוב — עשית את ה-commit וה-push הראשון שלך.

Framework: "The Save Loop" — הלופ שמנהל את החיים שלך

The Save Loop — תשנן את הזרימה הזו

זו הזרימה שתלווה אותך בכל פעם שאתה עובד עם Claude Code. כל סשן עבודה בנוי מחזרות של הלופ הזה:

שלב 1 — עשה שינויים: בקש מ-Claude לבנות, לתקן, או להוסיף פיצ'ר
שלב 2 — git add .: סמן את כל הקבצים שהשתנו
שלב 3 — git commit -m "what changed": שמור עם תיאור ברור
שלב 4 — git push: העלה ל-GitHub (גיבוי + deploy)
חזור לשלב 1.

בפועל, אתה פשוט אומר ל-Claude Code: "Save my progress and push to GitHub" — והוא מריץ את שלבים 2-4 אוטומטית. אתה רק צריך לזכור לבקש אחרי כל שינוי משמעותי.

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

חזור לפרויקט hello-world שיצרת. בקש מ-Claude Code:
"In my hello-world project, add a paragraph with today's date and the text 'This is my first Git change', then commit and push"

אחרי שהוא מסיים, לך ל-GitHub ולחץ על "commits" (ליד מספר ה-commits בדף ה-repo). תראה שני commits:
1. "Initial commit: hello world page" — הראשון
2. משהו כמו "Add paragraph with date" — השני

זו ההיסטוריה שלך. כל commit הוא נקודה שאפשר לחזור אליה.

טיפ — תדירות commits

עשה commit אחרי כל שינוי משמעותי. סיימת דף חדש? commit. תיקנת באג? commit. שינית עיצוב? commit. הוספת טופס? commit. ככל שה-commits שלך קטנים ותכופים יותר, כך קל יותר לשחזר אם משהו נשבר. הכלל: commit אחד לכל "יחידת עבודה" אחת. אל תחכה לסוף היום עם 50 שינויים ב-commit אחד — זה כמו לשמור מסמך של 20 עמודים רק בסוף.

מתחיל 20 דקות חינם כלי

לתת ל-Claude Code לטפל ב-Git

הנה הסוד הגדול של Git ל-Vibe Coders: אתה לא צריך לזכור את הפקודות. Claude Code הוא ה-Git assistant שלך — מנהל Git מושלם שמקשיב לך ומריץ הכל. תגיד לו מה לעשות בעברית, באנגלית, או בכל שפה — והוא יתרגם למה שצריך.

מה אתה אומר → מה Claude עושה

הנה טבלה שתעזור לכם להבין איך Claude Code מתרגם בקשות לפקודות Git. שימו לב — אתם צריכים רק את העמודה השמאלית (מה לומר). העמודה הימנית (מה Claude מריץ) היא רק כדי שתבינו מה קורה מאחורי הקלעים:

מה אתה אומר (בשפה טבעית) מה Claude מריץ מאחורי הקלעים
"Save my progress" git add . && git commit -m "..."
"Push everything to GitHub" git push origin main
"Create a new branch for the about page" git checkout -b add-about-page
"What changed since yesterday?" git log --since=yesterday --oneline + git diff
"Something broke, go back to how it was" git restore . או git revert HEAD
"Show me the commit history" git log --oneline -20
"Merge the about page branch" git checkout main && git merge add-about-page
"What's the current status?" git status
"Create a GitHub repo for this project" gh repo create project-name --public --source=.
"תשמור ותעלה הכל ל-GitHub" git add . && git commit -m "..." && git push

שימו לב לשורה האחרונה — Claude Code מבין גם עברית. אתם יכולים לומר "תשמור ותעלה" והוא ידע בדיוק מה לעשות.

מערכת ה-Checkpoints של Claude Code

מעבר ל-Git הרגיל, ל-Claude Code יש מערכת checkpoints (נקודות שמירה) משלו שעובדת באופן נפרד ומשלים. הנה איך זה עובד:

טעות נפוצה: לסמוך רק על Checkpoints במקום Git

מה הטעות: מתחילים חושבים ש-Checkpoints של Claude Code מספיקים ושלא צריך git commit ו-push.
למה זה מפתה: כי Checkpoints עובדים אוטומטית ובלי מאמץ — ומרגיש מיותר לעשות גם commit.
מה לעשות במקום: Checkpoints הם רשת ביטחון בנוסף ל-Git, לא במקום Git. הנה למה:

Checkpoints: שייכים לסשן ספציפי, נמחקים אחרי 30 יום, לא נגישים ממכשיר אחר, לא מחוברים ל-Deploy.
Git + GitHub: שומר היסטוריה לנצח, מגובה בענן, נגיש מכל מכשיר, מחבר ל-Deploy אוטומטי.

הכלל: תמיד תעשה commit ו-push — גם אם יש checkpoints. ה-checkpoints טובים לשחזור מהיר בתוך סשן; Git טוב לכל השאר.

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

פתח את פרויקט hello-world ב-Claude Code ותנסה את השיחות הבאות, אחת אחרי השנייה:

1. "What's the git status of this project?" — ראה מה Claude מחזיר. הוא ירוץ git status ויסביר לך מה המצב.
2. "Show me the commit history" — ראה את ה-commits שלך מסודרים לפי זמן.
3. "Add a CSS file called style.css with basic styling (dark background, white text, centered content), then save and push" — ראה איך Claude יוצר את הקובץ, עושה add, commit ו-push בזרימה אחת.

שים לב לתבנית: אתה מתקשר בשפה טבעית, ו-Claude מתרגם לפקודות Git + פעולות קוד. זו כל התורה.

טיפ — תגיד ל-Claude לעשות commit

למרות ש-Claude מטפל ב-Git, הוא לא תמיד עושה commit ו-push אוטומטית — הוא מחכה שתבקש. תזכיר לו באופן קבוע. אל תתנו לשעות עבודה לעבור בלי commit. כלל טוב: אחרי כל שינוי שאתם מרוצים ממנו, אמרו "Commit and push this progress". גם אם שכחתם — Claude יוצר checkpoints בשבילכם, אבל commit + push הם הביטחון האמיתי.

מתחיל 25 דקות חינם תרגול

Branches: עבודה בטוחה על פיצ׳רים

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

למה צריך branches? תרחיש מעשי

דמיין: יש לך אתר Portfolio שעובד מצוין ומופיע באינטרנט. Vercel מפרסם אותו מה-main branch. עכשיו אתה רוצה להוסיף דף "צור קשר" חדש עם טופס. ההוספה הזו דורשת שינויים ב-HTML, CSS, ואולי JavaScript. התהליך יקח כמה שעות.

בלי branches: אתה עורך ישירות על main. באמצע העבודה, הטופס חצי-מוכן, העיצוב שבור, ויש שגיאות JavaScript. אם אתה עושה push — האתר החי שלך שבור. אם לא עושה push — אין גיבוי ואין deploy.

עם branches: אתה יוצר branch בשם add-contact-page. עובד עליו שעתיים, שוברים ומתקנים, מנסים עיצובים שונים. כל הזמן הזה, main — והאתר החי — עובדים מצוין ולא נפגעים. כשהדף מוכן ובדוק, ממזגים את ה-branch ל-main, עושים push, ו-Vercel מעדכן את האתר החי. ואם הניסוי נכשל לגמרי? מוחקים את ה-branch — main נשאר בדיוק כמו שהיה.

Framework: "The Branch Strategy for Vibe Coders"

אסטרטגיית Branches — 4 צעדים

1. main = האתר החי. תמיד עובד. תמיד נקי. אף פעם לא עובדים עליו ישירות על דברים חדשים.

2. feature branch = עבודה על פיצ'ר חדש. שמות ברורים: add-contact-page, fix-mobile-nav, update-hero-section.

3. merge = כשהפיצ'ר מוכן ובדוק, ממזגים ל-main. הדף החדש נכנס לאתר החי.

4. delete branch = מוחקים את ה-feature branch. כבר לא צריך אותו — השינויים שלו נמצאים ב-main.

Branches עם Claude Code — בפועל

ככל שמדובר ב-branches, הנה כל מה שתצטרכו לדעת לגבי השיחות עם Claude:

מה אתה רוצה לעשות מה אתה אומר ל-Claude Code
ליצור branch חדש ולעבור אליו "Create a branch called add-contact-page and switch to it"
לעבוד על ה-branch "Build a contact page with a form on this branch"
לבדוק באיזה branch אני "What branch am I on?"
לחזור ל-main "Switch back to the main branch"
למזג branch ל-main "Merge add-contact-page into main and push"
למחוק branch שכבר מוזג "Delete the add-contact-page branch"
לראות את כל ה-branches "List all branches"
עשה עכשיו 15 דקות

הניסוי הזה יראה לך את הקסם של branches. בפרויקט hello-world, הריצו את הרצף הבא:

שלב 1: "Create a branch called test-feature and switch to it"
שלב 2: "Create a file called hello.txt with the text 'This file exists only on the test-feature branch'"
שלב 3: "Commit this"
שלב 4: "Switch back to the main branch"
שלב 5: תבדקו — האם hello.txt קיים? הוא לא. הקובץ נעלם.
שלב 6: "Switch to the test-feature branch"
שלב 7: תבדקו שוב — hello.txt חזר. קסם!

מה שקרה: כל branch הוא מציאות נפרדת. הקובץ קיים ב-test-feature אבל לא ב-main. כשתמזגו — הוא יופיע בשניהם.

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

עכשיו מזג את ה-branch ונקה:
"Switch to main, merge test-feature into main, push, and then delete the test-feature branch"

בדוק ש-hello.txt עכשיו קיים גם ב-main. ובדוק ב-GitHub שה-push הצליח. מעולה — עשית merge מושלם.

טיפ — שמות Branches

תן שמות ברורים ותיאוריים ל-branches. שם טוב מתאר מה ה-branch עושה, לא מי עובד עליו:
טוב: add-contact-page, fix-mobile-nav-bug, update-homepage-hero
רע: test, new, branch1, changes, nadav-branch

טעות נפוצה: לעבוד ישירות על main במקום ליצור branch

מה הטעות: לעשות שינויים גדולים ישירות על ה-main branch, בלי ליצור feature branch קודם.
למה זה מפתה: כי ליצור branch מרגיש כמו "צעד מיותר" כשאתה רק רוצה לשנות משהו קטן — ותמיד מרגיש שזה יהיה "קטן."
מה לעשות במקום: תמיד צור branch לשינויים שלוקחים יותר מ-5 דקות. אם זה באמת רק שורה אחת, main בסדר. אבל "דף חדש," "עיצוב מחדש," או "פיצ'ר חדש" — תמיד branch. אמור ל-Claude: "Create a branch called [feature-name] and switch to it". זה 5 שניות שיחסכו לך שעות של כאב ראש.

מתחיל 15 דקות חינם הקמה

קובץ .gitignore: מה לא לעקוב

יש קבצים שאתה אף פעם לא רוצה שיעלו ל-GitHub. בראש הרשימה: סיסמאות, מפתחות API, וקבצי secrets. אחריהם: תיקיות ענקיות כמו node_modules שלא צריך לאחסן. קובץ .gitignore אומר ל-Git: "תתעלם מהקבצים האלה — לא לעקוב, לא לעלות, לא ל-commit."

הקבצים שחייבים להיות ב-.gitignore

קובץ / תיקייה למה להתעלם מה קורה אם עולה ל-GitHub
.env מכיל סיסמאות, מפתחות API, tokens בוטים ימצאו את המפתחות תוך דקות ויגנבו אותם
.env.local הגדרות מקומיות רגישות אותו סיכון כמו .env
node_modules/ תיקיית חבילות מ-npm (לפעמים מאות MB) ה-repo יהיה עצום ואיטי. לא צריך — npm install מתקין הכל מחדש
dist/ / build/ קבצים שנוצרים אוטומטית בזמן build מיותר — פלטפורמת ה-Deploy יוצרת אותם בעצמה
.DS_Store קובץ מערכת של macOS סתם רעש — לא רלוונטי לפרויקט
__pycache__/ קבצי cache של Python מיותר — נוצר אוטומטית כשמריצים Python
*.log קבצי לוג מידע מיותר שתופס מקום
טעות נפוצה: להעלות סיסמאות ומפתחות API ל-GitHub

מה הטעות: להעלות קבצי .env, סיסמאות, או מפתחות API ל-GitHub — אפילו ב-repo פרטי.
למה זה מפתה: כי git add . מוסיף הכל — כולל קבצים רגישים שלא שמת לב שיש. ובלי .gitignore, הכל עולה.
מה לעשות במקום: תמיד צור .gitignore עם .env בשורה הראשונה לפני ה-commit הראשון. אף פעם, אף פעם, אף פעם אל תעלה סיסמאות ל-GitHub. הנה למה:

יש בוטים אוטומטיים שסורקים את GitHub 24 שעות ביממה, 7 ימים בשבוע, ומחפשים מפתחות API חשופים. הם מסתכלים על כל commit שעולה — גם ב-repos פרטיים אם הם קיבלו גישה דרך exploit. הם ימצאו את המפתחות שלכם תוך דקות ויתחילו להשתמש בהם: יריצו API calls על החשבון שלכם (אלפי דולרים), ישלחו ספאם, או ימכרו את המפתחות ב-dark web.

אם זה קרה בטעות — 3 צעדים מיידיים:
1. שנה/בטל את המפתח מיד (rotate) — לך ל-dashboard של השירות וצור מפתח חדש
2. מחק מהיסטוריית Git — בקש מ-Claude: "Remove .env from git history"
3. הוסף .env ל-.gitignore — כדי שזה לא יקרה שוב

קובץ .env — איפה שמים סודות

הפתרון הנכון הוא קובץ .env (קיצור של environment — סביבה). שמים בו את כל הסודות — סיסמאות, מפתחות API, tokens:

OPENAI_API_KEY=sk-abc123def456...
DATABASE_URL=postgres://user:password@host:5432/mydb
STRIPE_SECRET_KEY=sk_live_abc123...

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

ומה עם Deploy? בפלטפורמת ה-Deploy (Vercel, Netlify, Cloudflare), אתה מגדיר את אותם משתנים ב-Environment Variables דרך ממשק הניהול של הפלטפורמה — לא דרך קובץ. ככה הסודות קיימים גם בסביבת ה-production, בלי שיהיו ב-GitHub.

קובץ .env.example — תבנית בלי סודות

בנוסף, מקובל ליצור קובץ .env.example שמראה איזה משתנים נדרשים בלי הערכים האמיתיים:

OPENAI_API_KEY=your_openai_key_here
DATABASE_URL=your_database_url_here
STRIPE_SECRET_KEY=your_stripe_key_here

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

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

בפרויקט hello-world, בקש מ-Claude Code:
"Create a .gitignore file with standard entries for a web project (node_modules, .env, .env.local, dist, build, .DS_Store, *.log, __pycache__), and also create a .env.example with a fake placeholder API_KEY=your_key_here"

פתח את הקובץ .gitignore שנוצר ותראה מה בתוכו. זה ה-.gitignore שתשתמש בו כבסיס בכל פרויקט מעכשיו.

טיפ — Claude Code יוצר .gitignore אוטומטית

כש-Claude Code מקים פרויקט חדש, הוא בדרך כלל יוצר .gitignore אוטומטית עם entries סטנדרטיים. אבל — תמיד תבדקו שהוא כולל .env. זו הטעות הנפוצה ביותר (שכחת .env ב-.gitignore), והיא הכי מסוכנת.

מתחיל 25 דקות חינם תרגול

שחזור מטעויות Git

"שברתי הכל" — זה המשפט הנפוץ ביותר שנשמע מ-Vibe Coders חדשים. והתגובה הנכונה היא תמיד אותו דבר: אל תיבהל. אל תמחק. אל תיגע בשום דבר. Git נבנה בדיוק בשביל הרגעים האלה. תמיד יש דרך לחזור אחורה.

הסעיף הזה הוא אולי הסעיף הכי חשוב בפרק — כי הוא ההבדל בין Vibe Coder שמאבד שעות עבודה לבין Vibe Coder שמשחזר בשנייה וממשיך הלאה.

Framework: "סולם השחזור" (The Recovery Ladder)

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

1

Level 1: /rewind ב-Claude Code — הכי קל

הקלד /rewind ב-Claude Code (או לחץ Escape פעמיים). Claude יציג לך רשימת checkpoints — בחר את הנקודה שאליה אתה רוצה לחזור. הוא יחזיר את השיחה ואת הקבצים לנקודה שבחרת. מושלם כשה-prompt האחרון הרס משהו ואתה רוצה "undo" מהיר. השתמשו ב-Level הזה 90% מהמקרים.

2

Level 2: git restore . — ביטול שינויים שלא נשמרו

הפקודה מוחקת את כל השינויים שעדיין לא עשית להם commit, ומחזירה את הקבצים לגרסת ה-commit האחרון. אם עשית שינוי גרוע אבל עוד לא שמרת (commit) — זה הפתרון. אמור ל-Claude: "Discard all uncommitted changes". שים לב: שינויים שלא נשמרו ילכו לאיבוד — אין דרך לשחזר אותם אחרי git restore ..

הערה טכנית: הפקודה המקורית הייתה git checkout . — ייתכן שתראו אותה בדוגמאות ישנות. מאז Git 2.23 (2019), הפקודה המומלצת היא git restore . כי היא ברורה וממוקדת יותר. Claude Code ישתמש בפקודה הנכונה אוטומטית — אתם פשוט תגידו "Discard changes" והוא יטפל.

3

Level 3: git revert — ביטול commit ספציפי

כבר עשית commit לשינוי הגרוע? git revert יוצר commit חדש שמבטל את השינוי, בלי למחוק היסטוריה. זה הפתרון הנכון כי ההיסטוריה נשמרת — אתה יכול לראות מה קרה ולמה ביטלת. אמור ל-Claude: "Revert the last commit". אפשר גם לבטל commit ספציפי: "Revert the commit that added the broken form".

4

Level 4: git clone — התחלה מ-GitHub (האפשרות האחרונה)

הכל מבולגן ואתה לא יכול לתקן? מחק את התיקייה המקומית לגמרי ותוריד עותק חדש מ-GitHub. לפני שמוחקים: ודא שעשית push ל-GitHub לפני שהכל התקלקל — כי clone מוריד רק מה שיש ב-GitHub. אמור ל-Claude: "Clone my hello-world repo from GitHub into a fresh folder". זו "האפשרות הגרעינית" — יעילה, אבל מפסידים שינויים שלא עשינו להם push.

Decision Framework: איזה Level לבחור?

תרשים החלטה — מה נשבר ומה הפתרון

הפרומפט האחרון שבר משהו?
→ Level 1: /rewind

עשיתי שינויים בקבצים אבל עוד לא commit?
→ Level 2: git restore . (מוחק שינויים לא-שמורים)

עשיתי commit לשינוי גרוע?
→ Level 3: git revert (יוצר commit שמבטל)

הכל מבולגן ואני רוצה להתחיל נקי?
→ Level 4: git clone (מתחיל מחדש מ-GitHub)

כלל ברזל מספר 1: לעולם אל תמחק את התיקייה לפני שוידאת שעשית push ל-GitHub.
כלל ברזל מספר 2: אל תיבהל ואל תמחק. Git שומר הכל — תמיד אפשר לחזור.

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

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

שלב 1: בפרויקט hello-world, בקש מ-Claude: "Add a paragraph that says 'THIS IS A TEST MISTAKE'"
שלב 2: בקש: "Commit this change with message 'add test paragraph'"
שלב 3: פתח את index.html — תראה את הפסקה.
שלב 4: בקש: "Revert the last commit"
שלב 5: פתח את index.html שוב — הפסקה נעלמה!
שלב 6: בקש: "Show me the git log" — תראה 3 entries: ה-commit המקורי, ה-commit שהוסיף את הפסקה, וה-revert commit שביטל.

מעולה — עכשיו אתה יודע לשחזר מטעויות. זה כוח שרוב אנשים לא מאמינים שיש להם.

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

עכשיו נתרגל Level 2 — ביטול שינויים שלא נשמרו:

שלב 1: בקש מ-Claude: "Delete the CSS file from the project" (אל תעשה commit!)
שלב 2: בדוק — הקובץ נמחק.
שלב 3: בקש: "Discard all uncommitted changes"
שלב 4: בדוק שוב — הקובץ חזר! כי לא עשינו commit למחיקה, git restore . החזיר את הקובץ.

טיפ — הטעויות הנפוצות ביותר

טעות מספר 1: פאניקה ומחיקת הכל. לעולם אל תמחק — תמיד יש דרך לשחזר עם Git.
טעות מספר 2: לא לעשות commit ו-push לפני שמנסים לתקן. תמיד שמור (commit) ותעלה (push) לפני שאתה מתחיל לשבור דברים.
טעות מספר 3: לנסות "לתקן" ידנית במקום להשתמש ב-Git. אם שברת — השתמש ב-/rewind או git revert. אל תנסה להחזיר דברים ידנית, כי אז אתה שובר עוד יותר.

בינוני 20 דקות חינם הקמה

הכנת ה-Repo ל-Deploy

Repo "מוכן ל-Deploy" (deploy-ready) אומר שכל פלטפורמה — Vercel, Netlify, Cloudflare Pages — יכולה לקחת את הקוד שלך ולהפוך אותו לאתר חי בלי בעיות. זה דורש מבנה נכון, קבצים מסודרים, ובלי סודות חשופים. הידע הזה יחסוך לך שעות של debugging בעתיד.

מבנה פרויקט סטנדרטי — מה צריך להיות ב-Repo

קובץ / תיקייה מה זה עושה חובה?
README.md מתאר את הפרויקט. GitHub מציג אותו אוטומטית כדף הבית של ה-repo מומלץ מאוד
index.html או package.json נקודת הכניסה. הפלטפורמה צריכה לדעת מאיפה להתחיל חובה
.gitignore רשימת קבצים שלא עולים ל-Git חובה
.env.example תבנית שמראה מה צריך להגדיר (בלי ערכים אמיתיים) מומלץ
src/ תיקיית קוד מקור (ב-React, Next.js, ופרויקטים גדולים) לפי סוג הפרויקט
public/ קבצים סטטיים (תמונות, פונטים, favicon) לפי סוג הפרויקט

README.md — כרטיס הביקור של הפרויקט

כל repo צריך README.md. זה הקובץ הראשון שאנשים רואים כשהם נכנסים ל-repo שלך ב-GitHub — הוא מוצג אוטומטית כדף הבית. README טוב כולל: שם הפרויקט, תיאור קצר של מה הוא עושה, הוראות התקנה (אם רלוונטי), ו-screenshot או קישור לאתר החי.

אתה לא צריך לכתוב אותו ידנית. אמור ל-Claude: "Create a README.md for this project that describes what it does, how to run it, and what technologies it uses". Claude יכתוב README מסודר עם headers, bullet points, וכל מה שצריך.

Decision Framework: האם ה-Repo מוכן ל-Deploy?

5 שאלות לפני Deploy — אם התשובה לכולן "כן," אתה מוכן

1. יש .gitignore? → כולל .env? → כולל node_modules/? → טוב.

2. אין סודות בקוד? → חפש מחרוזות כמו sk-, password=, secret=, token= בקבצים → אם מצאת — העבר ל-.env

3. יש README? → אם לא, בקש מ-Claude ליצור. אחרת ה-repo נראה "ריק" ב-GitHub.

4. יש נקודת כניסה ברורה? → index.html בשורש (לאתר סטטי) או package.json עם build script (לפרויקט React/Next.js).

5. כל ה-commits ב-GitHub? → הרץ git status — אם אין שינויים מקומיים, הכל כבר push. אם יש — commit + push.

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

נהפוך את hello-world ל-deploy-ready. בקש מ-Claude Code:

"Make my hello-world repo deploy-ready: verify the .gitignore is correct, add a README.md that describes the project, create a .env.example if there are any environment variables, and push everything to GitHub"

אחרי שסיים, לך ל-GitHub ותבדוק את ה-repo. תראו: README מוצג יפה בדף הראשי, .gitignore קיים, ואין קבצים רגישים. הפרויקט שלך מוכן ל-Deploy — נשתמש בו בפרק 3 או 8 כשנלמד על Vercel.

טיפ — מבנה נכון מההתחלה

כל פרויקט שתבנו בקורס הזה יהיה ב-GitHub repo נפרד. הכלל: git init + .gitignore + first commit לפני שמתחילים לבנות. זה חוסך כאבי ראש אחר כך. כש-Claude יוצר פרויקט חדש, הוא בדרך כלל עושה את זה אוטומטית — אבל תבדקו.

מתחיל 15 דקות חינם תרגול

Git Cheat Sheet ל-Vibe Coders

הנה 10 פקודות Git שאתה צריך להכיר. אתה לא צריך לזכור אותן — Claude Code מריץ אותן בשבילך כשאתה מתאר מה אתה רוצה. אתה כן צריך להבין מה כל אחת עושה, כדי שתדע מה לבקש ומה קורה כשביקשת.

# פקודה מה זה עושה מתי משתמשים
1 git init מתחיל לעקוב אחרי תיקייה פעם אחת — בתחילת כל פרויקט חדש
2 git add . מסמן את כל השינויים לשמירה לפני כל commit
3 git commit -m "msg" שומר "תמונת מצב" עם תיאור אחרי כל שינוי משמעותי
4 git push מעלה commits ל-GitHub אחרי commit (או כמה commits)
5 git pull מוריד שינויים מ-GitHub כשעובדים ממכשיר אחר או אחרי הפסקה
6 git status מראה מה השתנה ומה המצב כשרוצים "דוח מצב" של הפרויקט
7 git log --oneline מראה היסטוריית commits בקצרה כשרוצים לראות מה עשו ומתי
8 git branch name יוצר branch חדש כשמתחילים לעבוד על פיצ'ר חדש
9 git checkout name עובר ל-branch אחר כשרוצים לעבור בין branches
10 git merge name ממזג branch ל-branch הנוכחי כשפיצ'ר מוכן ורוצים לחבר ל-main
10 פקודות

זה כל מה שאתה צריך לדעת. לא 50, לא 100. עשר. ו-Claude Code מריץ את רובן בשבילך כשאתה מתאר מה אתה רוצה. המטרה: להבין, לא לשנן.

Framework: "The Vibe Coder's Git" — הגישה הנכונה

את 10 הפקודות האלה אתה צריך להבין. אתה לא צריך לשנן. זה כמו נהיגה: אתה צריך לדעת ש"הגה ימינה = הרכב פונה ימינה" ו"בלם = הרכב עוצר." אתה לא צריך לדעת איך עובד מנוע הבעירה הפנימית. Claude Code הוא המנוע — אתה הנהג. תגיד לו "פנה ימינה" והוא יטפל בטכניקה.

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

צור "Git Cheat Sheet" אישי — רשום את 10 הפקודות עם הסבר במילים שלך. לא העתקה מהטבלה — התיאור שלך, בשפה שלך. שמור את הקובץ במחשב כדי שתוכל לחזור אליו.

בקש מ-Claude Code:
"Create a file called git-cheatsheet.md in ~/projects with the 10 essential git commands, a one-line explanation for each, and an example of when I'd use it"

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

Git זה כמו חגורת ביטחון — אתה לא חושב עליה כל הנסיעה, אבל היא שם כשאתה צריך אותה. ומהפרק הזה והלאה, כל פרויקט שתבנו: מתחיל עם Git, מגובה ב-GitHub, ומוכן ל-Deploy.

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

תרגיל 1 — הפרויקט הראשון מאפס ל-GitHub (20 דקות)
  1. פתח Claude Code ובקש: "Create a new project called my-portfolio in ~/projects with a basic HTML page that includes my name, my profession, and 3 skills"
  2. בדוק שהפרויקט נוצר: "Show me the git status and file structure"
  3. בקש מ-Claude ליצור repo ב-GitHub: "Create a public GitHub repo for this project and push everything"
  4. לך ל-GitHub ותוודא שה-repo קיים עם הקבצים שלך — לחץ על index.html ותראה את התוכן
  5. בקש מ-Claude: "Add a .gitignore with standard web entries, a README.md, and make this deploy-ready"
  6. תעשה push סופי ותבדוק ב-GitHub שהכל מסודר
תרגיל 2 — עבודה עם Branches (15 דקות)
  1. בפרויקט my-portfolio, בקש: "Create a branch called add-about-section"
  2. על ה-branch, בקש: "Add an About Me section below the skills with 3 paragraphs about my background, experience, and goals"
  3. שמור: "Commit this with message 'Add about me section'"
  4. חזור ל-main: "Switch to main" — ותבדוק שה-About section לא קיים (כי הוא רק ב-branch)
  5. מזג: "Merge add-about-section into main and push"
  6. בדוק ב-GitHub שה-main branch מעודכן עם ה-About section
  7. נקה: "Delete the add-about-section branch"
תרגיל 3 — שחזור מטעויות (10 דקות)
  1. בפרויקט my-portfolio, בקש: "Delete everything in the body and replace with just the word 'OOPS'"
  2. שמור את הטעות: "Commit this with message 'accidentally broke everything'"
  3. שחזר: "Revert the last commit"
  4. בדוק ש-index.html חזר לקדמותו — כל התוכן שלך אמור להיות שם
  5. בדוק היסטוריית commits: "Show me the git log" — תראה את ה-commit המקורי, ה-"oops", וה-revert
  6. Push: "Push everything"
תרגיל 4 — ניהול סודות נכון (10 דקות)
  1. בפרויקט my-portfolio, בקש: "Create a .env file with these fake variables: API_KEY=fake_key_123 and SECRET_TOKEN=fake_token_456"
  2. בדוק: "Run git status — is the .env file showing up as untracked?" (אם .gitignore נכון, הוא לא אמור להופיע)
  3. אם הוא כן מופיע, תקן: "Add .env to .gitignore"
  4. בקש: "Create a .env.example that shows what variables are needed without the actual values"
  5. Push: "Commit and push the .env.example and .gitignore changes"
  6. בדוק ב-GitHub: .env.example צריך להיות שם; .env לא צריך להיות שם

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

שגרת עבודה — Git (בנוסף לשגרה מפרק 1)

שגרה יומית

מתי מה לעשות כמה זמן
בתחילת סשן עבודה git pull — ודא שיש לך את הגרסה האחרונה (חשוב במיוחד אם עובדים ממספר מכשירים) 30 שניות
אחרי כל פיצ'ר / תיקון אמור ל-Claude: "Commit and push this" — הוא יריץ git add . && git commit -m "..." && git push 1 דקה
לפני שינוי "מסוכן" commit מה שעובד עכשיו, כדי שתוכל לחזור אם השינוי נכשל 30 שניות
בסוף סשן עבודה git push — ודא שהכל מגובה ב-GitHub לפני שסוגרים 30 שניות

שגרה שבועית

מה לעשות כמה זמן
בדוק שכל הפרויקטים הפתוחים מסונכרנים עם GitHub (אין uncommitted changes) 5 דקות
נקה branches ישנים שכבר מוזגו — בקש מ-Claude: "List merged branches and delete them" 2 דקות
בדוק שאין סודות חשופים — חפש .env בקבצים ב-GitHub 2 דקות

שגרה חודשית

מה לעשות כמה זמן
עבור על ה-repos שלך ב-GitHub — ארכב (archive) repos ישנים שלא בשימוש 10 דקות
בדוק שכל ה-repos הפעילים מכילים README עדכני 10 דקות
סקור את ה-SSH keys שלך ב-GitHub — מחק keys של מכשירים שלא בשימוש 5 דקות

Decision Frameworks — מסגרות החלטה

מסגרת החלטה: Public vs Private repo

Public repo (גלוי לכולם) אם:
- זה פרויקט Portfolio / תיק עבודות שאתה רוצה שמעסיקים או לקוחות יראו
- זה פרויקט Open Source שאתה רוצה שאחרים ישתמשו בו
- זה דוגמאות קוד / templates שאתה משתף עם הקהילה
- אתה רוצה להשתמש ב-GitHub Pages (hosting חינם)

Private repo (רק אתה רואה) אם:
- זה פרויקט של לקוח (סודיות מסחרית)
- יש בפרויקט לוגיקה עסקית ייחודית שאתה לא רוצה לחשוף
- זה בשלב מוקדם ולא מוכן לעיניים זרות
- זה מכיל מידע אישי או רגיש (גם אם הסודות עצמם לא ב-repo)

כלל אצבע: אם יש ספק — תתחיל private. אפשר תמיד לשנות ל-public אחרי כך. הפוך — לשנות מ-public ל-private — לא מוחק את מה שאנשים כבר ראו או cloned.

מסגרת החלטה: מתי לעשות commit — ומתי לא

תעשה commit כשאתה:
- סיימת פיצ'ר שלם (דף חדש, טופס, קטע חדש)
- תיקנת באג ואישרת שהתיקון עובד
- עשית שינוי עיצובי משמעותי שאתה מרוצה ממנו
- הולך לצאת להפסקה, לאכול, או לסיים את היום
- עומד לנסות שינוי "מסוכן" (commit לפני, כך שיש לאן לחזור)
- הגעת לנקודה שהכל עובד — גם אם לא סיימת הכל

אל תעשה commit כשאתה:
- באמצע שינוי שעוד לא עובד (הקוד שבור)
- שינית שורה אחת שלא בדקת
- הוספת קובץ debug זמני שתמחק עוד שנייה

מסגרת החלטה: Commit messages — מה לכתוב

תבנית פשוטה: [פועל] [מה שינית]

דוגמאות טובות:
"Add contact page with form and validation"
"Fix header alignment on mobile"
"Update homepage hero text and button color"
"Remove deprecated analytics script"
"Refactor CSS into separate files per page"

דוגמאות גרועות:
"stuff" — מה stuff?
"changes" — ברור שיש שינויים, זה commit...
"fix" — תיקנת מה?
"asdfgh" — רצינו?

טיפ: Claude Code כותב הודעות commit מעולות אוטומטית. אם אתה אומר "commit this", הוא ינסח message שמתאר את מה שהשתנה. אם אתה לא מרוצה — בקש "commit this with message 'my custom message'".

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

תעשו commit ו-push אחרי כל שינוי משמעותי. פתחו Claude Code עכשיו, ודאו שיש לכם Git repo פעיל (הריצו git status), ואם יש שינויים לא-שמורים — אמרו "Commit and push everything". זה ישמור עליכם מאובדן קוד, יאפשר שחזור מטעויות, ויאפשר Deploy אוטומטי. כל השאר — branches, .gitignore, README — חשוב, אבל משני. commit + push — זה הדבר. תעשו את זה עכשיו ואחרי כל סשן בנייה מהיום.

בדוק את עצמך — Check Yourself

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

ענה על חמש השאלות הבאות. אם ענית נכון על 4 מתוך 5 — אתה מוכן להמשיך לפרק הבא. אם פחות — חזור על הסעיפים הרלוונטיים.

  1. למה Git חשוב ל-Vibe Coders, גם כשClaude Code עושה הכל?
    (רמז: גיבוי, היסטוריה, שחזור, Deploy אוטומטי — Checkpoints לבד לא מספיקים)
  2. מה ההבדל בין Working Directory, Staging Area, ו-Repository — ואיך שלושת האזורים מתחברים?
    (רמז: עורך → git add → git commit. שלושה שלבים שכל שינוי עובר דרכם)
  3. למה צריך branches, ומתי עדיף לעבוד ישירות על main?
    (רמז: branches לשינויים משמעותיים שלוקחים יותר מ-5 דקות; main לתיקונים מיידיים קטנים)
  4. מה הסכנה בהעלאת קובץ .env ל-GitHub, ואיך מונעים את זה?
    (רמז: בוטים סורקים GitHub 24/7 ומוצאים מפתחות תוך דקות; .gitignore עם .env בשורה הראשונה)
  5. מה ההבדל בין /rewind, git restore, ו-git revert — ומתי משתמשים בכל אחד?
    (רמז: /rewind = חזרה בשיחה+קבצים בתוך סשן; restore = ביטול שינויים לא-שמורים; revert = ביטול commit ששמרת)

סיכום הפרק

סיכום פרק 2 — Git Essentials

התובנה המרכזית של הפרק הזה: Git הוא מכונת הזמן של הקוד שלך, ו-Claude Code הוא הנהג. אתה לא צריך לשנן פקודות — אתה צריך להבין שלושה דברים: כל שינוי שומרים (commit), כל שמירה מעלים (push), וכל ניסוי עובד על branch נפרד. עם ההבנה הזו, שלוש המילים "commit and push" מספיקות כדי שClaude Code ינהל את כל ה-Git בשבילך. הדבר שמחבר את הכל: Git הוא הגשר בין מה שאתה בונה על המחשב לבין האתר החי באינטרנט. בלי Git אין Deploy אוטומטי, ובלי Deploy אין מוצר חי. בפרק הבא נעבור ל-Building Your First Website — ניקח את ה-Project Brief מפרק 1, נפתח Git repo חדש, ונבנה את האתר הראשון שלך מאפס ל-URL חי עם Claude Code.

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