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

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

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

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

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

עכשיו כשסיימנו עם ההקדמה, הנה 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

6. אקסטרות

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

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

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

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

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

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

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

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

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

מאי אלוני

מפתחת פולסטאק בעלת נסיון בפיתוח אפליקציות ווב ב-Node.js, React ו-Angular. כיום מפתחת באקאנד.