7 טיפים מנצחים לעבודה עם גיט (Git)

מה זה גיט
שיתוף ב facebook
שיתוף ב linkedin
שיתוף ב whatsapp

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

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

תוכן עניינים


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

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

גיט לעומת גיטהאב (Git vs GitHub)

  • גיט (Git): מערכת לניהול גרסאות ומעקב אחר היסטוריה.
  • גיטהאב (GitHub): האתר שכולם מכירים בו הקוד שלכם מופיע. התצוגה היא תוצר לוואי של פעולות של ניהול גרסאות (גיט).


עכשיו כשסיימנו עם ההקדמה, הנה 7 טיפים שלי למקסום העבודה עם גיט:

1. כל ההתחלות קשות (עד שמתרגלים)

האינסטינקט הראשוני של כל מפתחת או מפתח שמתחילים להתעסק בגיט הוא להעלות קבצים בצורה של “זריקה”.

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


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

*ריפוזיטורי (repository) – אפשר לחשוב על זה סוג של קונטיינר המכיל את ההיסטוריה של פרויקט מסויים. כל פרויקט יכול להכיל קבצים ותיקיות.

2. חזרה למקורות

באחת מהכשרות הפיתוח שעברתי, החליטו שהמבוא לא יהיה שפת C או Java, אלא יהיה bash.

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

הפקודה הזאת אומרת: “תן לי נתיב שאתה רוצה ללכת אליו ואני אעבור אליו”. ובצורה זו ניתן את נתיב הדסקטופ אחרי ה-cd.

ככה יוצרים תיקייה:

 mkdir folder-name

ויש עוד אינספור פקודות שימושיות שכדאי לדעת בשביל לחסוך את הקליקים בעכבר.

למה ואיך זה קשור לגיט? כי גם פקודות בגיט אפשר (ורצוי) לכתוב בטרמינל.

3. גיט היא מערכת שמתעדת היסטוריית קוד פר בראנץ’ (Branch)

הזכרתי את זה על קצה המזלג כשדיברתי על ריפוזיטורי, אבל חשוב לי לחדד את המסר עוד טיפה.

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

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

איך דוחפים קומיט מההתחלה:

git add .

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

“git commit -m “commit description

אומר “צפוי להיות שינוי שמכיל את התיאור שתרצו”, עדיף שהתיאור יהיה ברור.

git push

זו ההעלאה הרשמית של הקומיט לריפוזטורי.


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

למה זה טוב, ומהי המשמעות הגדולה של הקומיט הזה?

מכירים את זה שיש עדכון תוכנה למערכת הפעלה ואיכשהו העדכון דפק משהו במחשב אבל במחשב יש נקודת שיחזור? אז כזה. למקרה שמשהו הפתיע אתכם, למשל – המשכתם לפתח לוקאלית ואיכשהו נדפק משהו במהלך הפיתוח – יש לכם לאן לחזור.

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

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

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

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

שניהם עובדים על אותו בראנץ’ מאסטר (הבראנץ’ הדיפולטיבי של גיט). איך זה עובד?

יש אופציה בגיטהאב להוסיף collaborators לפרויקט לפי שם המשתמש בגיטהאב (או מייל). הצד שהצטרף לפרויקט מקבל הזמנה במייל שבו הוא צריך לאשר את ההצטרפות לפרויקט.

כדי שלכל מי שהצטרף לפרויקט יהיה את הקוד, הפעולה שהוא צריך לעשות היא משיכת הקוד. כן, גם פה github מנסה לשכנע אתכם להוריד זיפ. 

בעיני, אם קראתם עד פה כבר עברתם את הפסקה על bash – שורה בטרמינל ואתם מושכים את הקוד. כותבים בטרמינל pull, מספקים את הנתיב של הריפוזיטורי והקוד אצלכם.

כמה אופציות אפשריות

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

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

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

– קונפליקט שאתם צריכים לפתור בין חברי הצוות: קונפליקט שקורה כשאתם וחבר צוות משנים את אותו הקובץ ואת אותן השורות. אז גיט נכנס לדילמה ושואל – איזה מהשינויים לקחת: שלכם? של החבר?

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

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


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

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




אני תמיד מבצעת בדיקה אקסטרה (למקרה שסביבת העבודה פספסה) ומריצה חיפוש על כל הקבצים בפרוייקט בשביל לראות שלא קיימת שם המילה “HEAD” – שזו מילת המפתח שגיט מוסיף כשיש קונפליקט.

*הערה חשובה: אי אפשר להתעלם מקונפליקטים. זאת אומרת, אם גיט זיהה קונפליקט, הוא לא יתן את האפשרות לדחוף שינויים נוספים לגרסה עד אשר הקונפליקט יפתר.

5. לכל גרסה יש את הקסם שלה (עובדים על בראנצ’ים)

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

אתחיל בלומר שאין חובה לעבוד עם בראנצ’ים. אם אתם מפתחים פרויקט עצמאי אתם יכולים לעבוד בלי בראנצ’ים, אבל אם תאמצו עבודה באמצעותם, אתם רק תרוויחו.

אז מה זה בראנץ’ בעצם? 

אפשר להתייחס לבראנץ’ כמו אל עדכוני גרסה במכשיר הנייד שלכם. כל תקופה מסויימת יוצאים מס’ עדכונים.

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


בתעשייה הבראנץ’ נקרא prod. הגרסה שעובדים עלייה עד שחרור הגרסה (סוף ספרינט) היא גרסת dev, כאשר המטרה היא לא לעשות נזק לגרסה שבאוויר (prod).

מחוץ לגרסאות הטוטאליות שמחזיקות את הפרויקט בתנועה (בפיתוח) והגרסה שבאוויר, יש חברות שאימצו גרסה שלפיה כל פיצ’ר שיכול לעמוד ברשות עצמו, יזכה בבראנץ’ משל עצמו. 

למה כדאי לעשות את זה?

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

יכול להיות מצב שחברה תרצה פיצ’ר של מפתח אחד בגרסה הקרובה, אבל פיצ’ר של מפתח אחר רק בגרסה העתידית. והפיצול הזה לפיצ’רים מאפשר מרחב תמרון. 

איך יוצרים בראנץ’ חדש:

git checkout -b branch-name1

איך לעבור מבראנץ’ לבראנץ’:

git checkout branch-name2

בהנחה שקיים בראנץ’:

branch-name1

אז עכשיו עברנו ל:

branch-name2

פקודה נוספת ומאוד שימושית שמאפשרת למשוך שינוי מבראנץ’ לבראנץ‘*:

git pull origin branch-name1
*אם אנחנו בבראנץ’ 2 ורוצים למשוך את השינויים מהבראנץ’ הראשון לשני.

6. אקסטרות

  • git status – אם נכנס שינוי ואתם צריכים למשוך את אותו שינוי, פקודה זו נותנת תמונת מצב על הגרסה.
  • gitignore – בעקרון, כשמוסיפים קבצים לתיקייה וגיט נמצא בשליטה על אותה תיקייה, הוא מוסיף את כל הקבצים בתיקיה. זאת למעט קבצים שגיט חושד בהם כבעיתיים, או קבצים שאתם הגדרתם לא לדחוף לריפוזטורי. 

איך עושים את זה?

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

ולכן צריך לוודא שהיא נמצאת ב-.gitignore

ואם לא, זה זמן טוב לראות איך זה עובד ולהוסיף בעצמכם.

7. סורס טרי, סמארט גיט ושות’

הרבה פעמים עודדו אותי לפתח מטרמינלים שחורים, גם הרבה אחרי bash ולכן אני יכולה לספור על יד אחת את הפעמים שאני עובדת עם ממשקי UI שדרכם אפשר לבצע קומיטים בלחיצת כפתור, לדחוף קוד וכו’. 

ובכל זאת מתי אני כן מסתכלת על ממשק?

  • אם אני רוצה להבין מאיזה בראנץ’ יצאה הגרסה הנוכחית.
  • אם היו הרבה מאוד קומיטים (מצב שאני מנסה להמנע ממנו) ואני רוצה לתת שם הולם לקומיט אז נוח לי לראות את כל השינויים בממשק באופן מרוכז.


המאמר עזר לך? כאן משתפים >>

שיתוף ב facebook
שיתוף ב linkedin
שיתוף ב whatsapp

מומלצים מהערוץ שלנו:

רוצה להישאר בלופ?

טיפים לפיתוח קריירה, מדריכים ועדכונים שהייטקיסטים אוהבים – אצלך במייל!

*מבטיחים לא לחפור:)