אם פתחתם פרויקט קוד בפעם הראשונה וראיתם רשימה של git commands, קל להרגיש ש־Git הוא עולם של פקודות מסתוריות. בפועל, ביום עבודה רגיל אתם צריכים להבין היטב שלושה רעיונות: commit, branch ו־merge. אלה לא מושגים תיאורטיים; הם הדרך לשמור התקדמות, לעבוד על שינוי בלי לשבור את הקוד הקיים, ולהחזיר את השינוי למסלול המרכזי.
המדריך הזה נכתב בגישה מעשית: מה מכינים מראש, אילו פקודות מריצים, מה רואים במסך, איפה נתקעים, ואיך יוצאים מזה בלי למחוק עבודה בטעות. אם אתם ממש בתחילת הדרך עם סביבת פיתוח, כדאי גם לעבור על צעדים ראשונים לפני שמתחילים לעבוד עם פרויקטים אמיתיים.
מה צריך להכין לפני שמריצים פקודות Git
כדי לעבוד בנוחות, צריך התקנה של Git וטרמינל. בלינוקס וב־macOS עובדים לרוב עם bash או מעטפת דומה. ב־Windows אפשר לעבוד עם PowerShell, אבל בדוגמאות כאן נשתמש בפקודות עבור Linux/macOS ב־bash.
כדאי לוודא ש־Git מותקן:
git --versionהפקודה מציגה את גרסת Git המותקנת. הפלט יהיה דומה ל־git version .... אם מתקבלת הודעה שהפקודה לא נמצאה, צריך להתקין Git לפני שממשיכים. אפשר למצוא את ההוראות בשם “Git documentation” באתר הרשמי של Git, בלי צורך להיכנס כרגע לפרטים מתקדמים.
בנוסף, בפרויקט אמיתי חשוב להגדיר שם ואימייל ל־Git. במדריך הזה נשתמש בהגדרה מקומית לכל מאגר, כדי לא לשנות הגדרות כלליות במחשב שלכם.
המודל המנטלי: working tree, staging area ו־commit
לפני הפקודות, חשוב להבין מה Git רואה:
- Working tree — הקבצים בתיקיית הפרויקט כפי שהם עכשיו.
- Staging area — רשימת השינויים שאתם מתכוונים להכניס ל־commit הבא.
- Commit — צילום מסודר של השינויים, עם הודעה שמסבירה מה השתנה.
הרעיון המרכזי: לא כל שינוי בקובץ נכנס אוטומטית להיסטוריה. קודם מוסיפים אותו עם git add, ואז שומרים אותו כ־commit עם git commit.
דוגמה ראשונה: יצירת מאגר, קובץ ראשון ו־commit
הדוגמה הבאה מיועדת ל־Linux/macOS ב־bash. היא יוצרת תיקייה זמנית, מאתחלת בה מאגר Git, יוצרת קובץ, ומבצעת commit ראשון. אפשר להריץ אותה כמו שהיא.
#!/usr/bin/env bash
set -e
PROJECT_DIR="$(mktemp -d)"
cd "$PROJECT_DIR"
git init
git config user.name "Example Developer"
git config user.email "[email protected]"
printf "hello git\n" > notes.txt
git status --short
git add notes.txt
git commit -m "Add notes file"
git log --oneline --decorate -1
echo "Project created at: $PROJECT_DIR"מה קורה כאן? git init יוצר מאגר חדש. שתי פקודות git config מגדירות זהות מקומית למאגר בלבד. הפקודה printf יוצרת קובץ בשם notes.txt. לאחר מכן git status --short יציג בדרך כלל ?? notes.txt, כלומר Git רואה קובץ חדש אך הוא עדיין לא ב־staging. אחרי git add ו־git commit, git log --oneline יציג שורה אחת עם מזהה commit קצר וההודעה Add notes file.
איך כותבים הודעת commit שימושית
הודעת commit לא נועדה להרשים. היא נועדה לעזור לכם ולמי שקורא את ההיסטוריה להבין מה קרה. הודעה כמו fix או changes לא עוזרת אחרי יומיים. הודעה כמו Add notes file כבר אומרת משהו ברור.
כלל פשוט:
- התחילו בפועל:
Add,Fix,Update,Remove. - כתבו מה השתנה, לא איך הרגשתם לגבי השינוי.
- אל תכניסו כמה נושאים לא קשורים לאותו commit.
לדוגמה, אם שיניתם קובץ הגדרות וגם תיקנתם טעות כתיב במסמך, בדרך כלל עדיף לבצע שני commits נפרדים. כך קל יותר להבין, לבטל או להעביר שינויים בהמשך.
git commands בסיסיים ליום עבודה רגיל
אלה הפקודות שתשתמשו בהן שוב ושוב. לא צריך לשנן הכול ביום אחד, אבל כדאי להבין מה כל אחת עושה.
| פקודה | מתי משתמשים בה | מה היא עושה |
|---|---|---|
git status |
לפני ואחרי כל פעולה חשובה | מציגה מה השתנה ומה מוכן ל־commit |
git add file |
אחרי שינוי בקובץ | מכניסה שינוי ל־staging area |
git commit -m "message" |
כשיש שינוי שלם לשמירה | יוצרת נקודת היסטוריה חדשה |
git branch |
כשרוצים לראות ענפים | מציגה את רשימת הענפים במאגר |
git switch -c name |
כשמתחילים שינוי חדש | יוצרת branch חדש ועוברת אליו |
git merge name |
כשמחזירים שינוי לענף הראשי | משלבת את הענף הנבחר בענף הנוכחי |
שימו לב להרגל חשוב: לפני commit, לפני מעבר branch ולפני merge, הריצו git status. זו הפקודה שמונעת הרבה טעויות קטנות.
Branch: לעבוד על שינוי בלי להרוס את הענף הראשי
branch הוא קו עבודה נפרד. במקום לשנות ישירות את הענף הראשי, יוצרים ענף חדש עבור משימה מסוימת: תיקון באג, הוספת קובץ, שינוי הודעה, ניסוי קטן. אם השינוי מצליח, ממזגים אותו חזרה. אם לא, אפשר לעזוב את הענף בלי לזהם את ההיסטוריה הראשית.
במאגר חדש, הענף הראשי נקרא לעיתים main ולעיתים master, תלוי בהגדרות Git ובסביבה. בדוגמאות הבאות ניצור במפורש ענף בשם main כדי למנוע בלבול.
דוגמה שנייה: יצירת branch ומיזוג פשוט
הדוגמה הבאה יוצרת מאגר, עושה commit ראשון, פותחת branch בשם add-title, משנה קובץ, ואז ממזגת את השינוי חזרה ל־main.
#!/usr/bin/env bash
set -e
PROJECT_DIR="$(mktemp -d)"
cd "$PROJECT_DIR"
git init
git switch -c main
git config user.name "Example Developer"
git config user.email "[email protected]"
printf "Shopping list\n" > list.txt
git add list.txt
git commit -m "Add list file"
git switch -c add-title
printf "Shopping list\n- bread\n" > list.txt
git add list.txt
git commit -m "Add bread item"
git switch main
git merge add-title
cat list.txt
git log --oneline --decorate --all
echo "Project created at: $PROJECT_DIR"הפלט של cat list.txt יהיה:
Shopping list
- breadה־merge בדוגמה זו פשוט, כי הענף main לא השתנה מאז שיצרנו את add-title. במצב כזה Git יכול לבצע מיזוג מהיר יחסית. ב־git log --oneline --decorate --all תראו את ה־commits ואת שמות הענפים לידם.
Merge: מה באמת קורה כשמשלבים ענפים
git merge לוקח את השינויים מענף אחר ומנסה לשלב אותם בענף הנוכחי. לכן סדר הפעולות חשוב:
- עוברים לענף שאליו רוצים להכניס את השינוי, למשל
main. - מריצים
git merge branch-name. - בודקים שהקוד תקין.
- מוחקים ענף עבודה אם כבר לא צריך אותו, למשל עם
git branch -d branch-name.
טעות נפוצה היא להריץ merge מתוך הענף הלא נכון. אם אתם נמצאים ב־feature ומריצים git merge main, אתם מכניסים את השינויים מ־main אל feature, לא להפך. זה יכול להיות שימושי לפעמים, אבל זה לא “להחזיר את הפיצ’ר ל־main”.
דוגמה שלישית: יצירת conflict ופתרון שלו
קונפליקט קורה כששני ענפים שינו את אותו אזור בקובץ, ו־Git לא יכול להחליט לבד איזו גרסה נכונה. הדוגמה הבאה יוצרת קונפליקט מכוון, מציגה אותו, ואז פותרת אותו בצורה בטוחה.
#!/usr/bin/env bash
set -e
PROJECT_DIR="$(mktemp -d)"
cd "$PROJECT_DIR"
git init
git switch -c main
git config user.name "Example Developer"
git config user.email "[email protected]"
printf "message: hello\n" > app.txt
git add app.txt
git commit -m "Add app message"
git switch -c change-to-hi
printf "message: hi\n" > app.txt
git add app.txt
git commit -m "Change message to hi"
git switch main
printf "message: welcome\n" > app.txt
git add app.txt
git commit -m "Change message to welcome"
set +e
git merge change-to-hi
MERGE_EXIT_CODE="$?"
set -e
echo "Merge exit code: $MERGE_EXIT_CODE"
cat app.txt
printf "message: welcome and hi\n" > app.txt
git add app.txt
git commit -m "Resolve message conflict"
cat app.txt
git status --short
echo "Project created at: $PROJECT_DIR"במהלך ה־merge תקבלו הודעה דומה לזו:
CONFLICT (content): Merge conflict in app.txt
Automatic merge failed; fix conflicts and then commit the result.בתוך הקובץ יופיעו סימוני קונפליקט כמו <<<<<<<, ======= ו־>>>>>>>. בדוגמה אנחנו פותרים את הקונפליקט על ידי כתיבה מחדש של הקובץ עם השורה message: welcome and hi, מוסיפים אותו עם git add, ואז מבצעים commit שמסיים את המיזוג. בסוף git status --short לא אמור להציג כלום, כלומר אין שינויים פתוחים.
שגרת עבודה מומלצת למשימה קטנה
כך נראית עבודה יומיומית מסודרת עם Git:
- בודקים מצב:
git status. - עוברים לענף הראשי:
git switch main. - יוצרים ענף חדש:
git switch -c fix-message. - משנים קבצים.
- בודקים מה השתנה:
git diff. - מוסיפים רק את מה שרוצים:
git add file-name. - יוצרים commit:
git commit -m "Fix message text". - חוזרים ל־main:
git switch main. - ממזגים:
git merge fix-message.
אם אתם לומדים במקביל שפת תכנות כמו פייתון, אותה שגרה תעזור גם בפרויקטים קטנים: תרגיל אחד, branch אחד, commit ברור אחד או יותר. אפשר לשלב את זה עם מדריכי פייתון כדי להתרגל לשמור התקדמות בצורה נקייה.
טעויות נפוצות והודעות שגיאה אמיתיות
fatal: not a git repository (or any of the parent directories): .git
המשמעות: אתם מריצים פקודת Git בתיקייה שאינה מאגר Git. אולי אתם בתיקייה הלא נכונה, או שלא הרצתם git init.
איך מתקנים: הריצו pwd כדי לראות איפה אתם נמצאים, עברו לתיקיית הפרויקט עם cd, ואז הריצו git status. אם זה פרויקט חדש, הפעילו git init פעם אחת בלבד בשורש הפרויקט.
error: pathspec 'main' did not match any file(s) known to git
המשמעות: ביקשתם לעבור לענף בשם main, אבל Git לא מכיר ענף כזה במאגר הנוכחי.
איך מתקנים: הריצו git branch כדי לראות אילו ענפים קיימים. אם הענף הראשי נקרא master, עברו אליו עם git switch master. אם זה מאגר חדש ללא commit ראשון, צרו קודם commit או צרו ענף עם git switch -c main.
error: Your local changes to the following files would be overwritten by checkout:
המשמעות: יש לכם שינויים פתוחים, ו־Git מונע מעבר branch שעלול לדרוס אותם.
איך מתקנים: יש שלוש אפשרויות בטוחות. אם השינוי מוכן, בצעו git add ואז git commit. אם הוא זמני, אפשר להשתמש ב־git stash. אם השינוי לא חשוב, בדקו היטב ואז אפשר לבטל אותו עם פקודות שחזור מתאימות. אל תריצו פקודות מחיקה בלי להבין מה הן מוחקות.
CONFLICT (content): Merge conflict in file-name
המשמעות: Git מצא שינוי מתנגש באותו אזור בקובץ.
איך מתקנים: פותחים את הקובץ, מחפשים את סימוני הקונפליקט, משאירים את הגרסה הנכונה, מוחקים את הסימונים, ואז מריצים git add file-name ו־git commit. אם הסתבכתם, הריצו git status; Git בדרך כלל כותב שם מה הצעד הבא.
מתי לא לעשות commit
לא כל מצב מתאים ל־commit. למשל:
- כשהקוד לא רץ בכלל בגלל חצי שינוי שלא סיימתם.
- כשנכנסו לקבצים נתונים מקומיים שלא שייכים לפרויקט.
- כששיניתם עשרה דברים לא קשורים ורק חלק מהם באמת צריך להישמר.
- כשאתם לא יודעים להסביר במשפט אחד מה השינוי עושה.
מצד שני, אל תחכו יותר מדי. commit טוב לא חייב להיות ענק. להפך: commits קטנים וברורים מקלים על בדיקה, חזרה לאחור והבנה של התהליך.
שאלות שקוראים באמת שואלים
האם חייבים branch לכל שינוי?
לא תמיד. בפרויקט אישי קטן אפשר לפעמים לעבוד ישירות על הענף הראשי. אבל ברגע שיש יותר מקובץ אחד, יותר מניסוי אחד, או סיכוי שתצטרכו לחזור אחורה, branch הופך את העבודה להרבה יותר רגועה.
מה ההבדל בין git add . לבין git add file?
git add . מוסיף הרבה שינויים בבת אחת מהתיקייה הנוכחית ומטה. זה נוח, אבל עלול להכניס בטעות קבצים שלא התכוונתם לשמור. למתחילים עדיף להתחיל עם git add file, לבדוק git status, ורק אחר כך לבצע commit.
האם merge מוחק את ה־branch?
לא. git merge משלב שינויים, אבל הענף נשאר קיים. אם סיימתם איתו, אפשר למחוק אותו עם git branch -d branch-name. אם Git מסרב למחוק, הוא כנראה חושב שהענף עדיין לא מוזג במלואו.
סיכום מעשי
Git נהיה פשוט יותר כשמפסיקים לחשוב עליו כרשימת פקודות ומתחילים לחשוב עליו כזרימת עבודה: בודקים מצב, יוצרים branch, משנים קוד, מוסיפים ל־staging, עושים commit, ואז מבצעים merge. שלוש הפקודות שחוזרות הכי הרבה הן git status, git add ו־git commit; סביבן בונים את השגרה.
בפעם הבאה שאתם פותחים משימה קטנה, נסו לעבוד מסודר: branch חדש, commit עם הודעה ברורה, merge חזרה לענף הראשי. אחרי כמה חזרות, Git מפסיק להרגיש כמו מכשול והופך לכלי עבודה רגיל. ואם אתם עדיין מחברים את סביבת הפיתוח הבסיסית שלכם, חזרה קצרה אל צעדים ראשונים יכולה לחסוך לא מעט בלבול לפני שמתחילים לצבור היסטוריה בפרויקט אמיתי.
