עידן יצחקיתחילה נדבר על שיגרת עבודה בגיט ולאחר נראה פקודות של גיט ומה הן עושות.
מה זה גיט?
בקצרה, זה מקום שמחזיק את הקוד שלכם, יודע לעקוב אחרי שינויים בקבצים, לשמור היסטוריה של שינויים, להצביע על קונפליקטים (שינויים באותו קובץ ממקורות שונים) ועוד הרבה.
כל זה על מנת שנוכל לפתח ביחד כצוות במינימום של הפרעה אחד לשני.
נתחיל בשיטת עבודה:
כאשר יוצרים REPO מקבלים בצורה אוטומטית ענף (branch) בשם master/main תלוי בגיט. זה הענף שתמיד יחזיק את הקוד לאחר שעבר בדיקות והוא תקין לחלוטין. זה הענף שבונים ומעבירים לבדיקות QA או TEST או PROD בסופו של יום.
לכן לענף הזה רק ראש הצוות או המוביל לפרויקט מורשה לשלב אליו, במידה שרוצים להיות בטוחים שלא ישולבו לשם בטעות ענפים אחרים, אפשר להפעיל חוקיות (policy) שתמנע שילוב של ענפים ללא PR (pull request) , בנוסף אפשר לשים חוקיות חסימה שרק משתמש אחד יוכל לשלב לענף הראשי.
המוביל בפרויקט ייצור ענף נוסף בשם DEV, זה הענף שעליו כל הצוות יעבוד וגם שם יש לשים חוקיות שניתן לשלב אליו רק על ידי PR ולא ישירות בדחיפה (PUSH).
תחילת עבודה של מפתח בפרויקט:
כמו שאמרנו, מפתחים לא מתעסקים עם הענף הראשי אלא עם DEV בלבד. תחילת עבודה של המפתח לאחר שמשך את הפרויקט אליו, מעבר לענף DEV ומשיכה של העדכונים (PULL) על מנת להיות הכי מעודכנים שאפשר.
יצירה של ענף חדש:
git branch feature/header-component
שימו לב, נהוג שכל פיתוח חדש יהיה תחת ספריה בשם feature וכל טיפול בבאג יהיה תחת השם bug
git branch bug/color-fix-in-header
דבר נוסף, יש לתת לענפים שמות שמרמזים על מטרת הענף ובמה שהוא מטפל.
במידה שתצטרכו מאוחר יותר לחזור לענף הזה כדאי לבדוק איזה שינויים הוא עשה, יהיה יותר קל למצוא אותו מתוך רשימת הענפים הקיימת.
על מנת שהעבודה תהיה קלה ונכונה ככול האפשר יש להקפיד על מספר כללים.
- יוצאים רק מ-DEV וחוזרים ב-PR ל-DEV
- רצוי מאוד לא לצאת מענף לעוד ענף. הדבר יוצר קשר בין הענפים והענף השני יכיל את השינויים של הענף הראשון, כך שבמידה שיש בעית קוד בענף הראשון, לא ניתן לשלב גם את הענף השני.
- לא מבצעים בדיקת קוד (code review) במידה שהענף נמצא ב-conflict, במידה שהוא יאושר ורק לאחר מיכן המפתח יתקן את הקונפליקט יתכן והוא לא ביצע זאת נכון ויש פגיע/שבירה בקוד וזה ישולב ל-DEV. המשמעות היא ש-DEV לא תקין וכל מפתח שימשוך אותו לא יוכל להמשיך לפתח.
- יש ליצור PR רק לאחר וסיימתם את הפיתוח ולא באמצע, פתיחה של PR הוא טריגר לתחילה של בדיקת קוד. זה יצור עבודה כפולה במידה והפיתוח לא הסתיים ומוביל הפרויקט כבר מתחיל לבדוק את הקוד
- בזמן commit יש לרשום הערה קצרה ורצוי שהיא תהיה ברורה וממצה לגבי מה שבוצע בענף.
- בעיות קוד ב-PR יש לרשום רק ב-PR ולא במיילים או הודעות או בעל פה, כך דברים לא נשכחים ולא הולכים לאיבוד. בנוסף זה יוצר התכתבות בין הבודק לנבדק לגבי שינויים ב-PR
- כל הערה יש לסגור, יש מספר סטטוסים שאפשר לבחור, כאשר active אומר שההערה פעילה ולא טופלה על ידי פותח ה-PR.
- יש לקבוע בתחילת הפרויקט מי משלב את ה-PR, זה יכול להיות הבודק, לאחר שהקוד אושר וזה יכול להיות פותח ה-PR לאחר שהקוד אושר.
- לאחר פתיחת ה-PR, על המפתח לחזור ל-DEV, למשוך את העדכונים החדשים (PULL) ורק אז לצאת לענף חדש
- בכל בדיקת PR על הבודק לעבור לענף ולבדוק שאכן הוא מתפקד כראוי ללא שגיאות ולא רק לעבור על הקוד ב-PR.
מספר פקודות לעבודה עם GIT
git init
זו פקודה לאיתחול גיט, היא יוצרת ספריה ניסתרת שמשמשת את גיט למעקב אחרי שינויים, איסוף נתונים על הפרויקט ועוד. הפקודה נידרשת כדאי להכין את הסיפריה ל-REPO.
במידה שנוסיף קבצים לסיפריה ונריץ את הפקודה
git status
אנחנו נראה שגיט נמצא על ענף מאסטר, ובאדום את רשימת הקבצים שהוספנו תחת הכותרת
untracked files.
זאת אומרת, שגיט רואה אותם אבל הם עדיין לא חלק מהפרויקט ולכן הוא גם לא עוקב אחרי השינויים שמבוצעים בהם, אלא מבחינתו, כל הקובץ/ הקבצים חדשים.
הקבצים נמצאים בתחנה הראשונה, התחנה המקומית.
git clone <url>
העתקה של repo קיים לתוך הספריה. יש כמובן להחליף את <url> בכתובת מלאה
git pull
משיכה ועדכון של שינויים ממקום האיחסון המרוחק בשרת (REPO) אל הספריה המקומית במחשב.
שימו לב, המשיכה מבוצעת רק עבור הענף עליו אתם נמצאים ולא כלל הענפים בפרויקט.
git add . git add <file>
כאשר רוצים להוסיף קבצים לפרויקט, ניתן לעשות את זה על ידי הפקודה הראשונה, זה יוסיף את כל הקבצים בפרויקט או על ידי הפקודה השניה, הפקודה השניה תוסיף קובץ אחד ספציפי.
כמובן שיש להחליף את <file> בשם קובץ מלא כולל הסיומת שלו.
זו התחנה השניה מתוך 3, התחנה שבה נמצאים כל התוצרים שאנחנו מעוניינים לעלות לשרת ומאושרים על ידינו.
בתחנה זו אנו אומרים לגיט מי מהקבצים הם חלק מהפרויקט שאנחנו מתכוונים לעלות ושיש לעקוב אחריהם. אבל הם עדיין במחשב המקומי ולא עלו לשרת.
git commit -m "my first commit"
שמירה של השינויים שבוצעו, יש לצרף הערה קצרה על מה שבוצע.
git push
העלאה של הקומיטים על הענף לאיחסון המרוחק, זו התחנה השלישית והאחרונה.
בשלב הזה, כל מפתח אחר בצוות יוכל להתחבר ל-REPO ולראות את הענף שלכם, וכמובן גם למשוך את כל הענף עם השינויים שלכם אליו למחשב.
git log
נותן רשימה של כל היסטורית השינויים על הענף שבו אתם נמצאים
git branch
כמו הפקודה הראשונה שראינו רק בלי שם כלשהו בהמשך, זה נותן לנו רשימה של כל הענפים הידועים המקומיים בפרויקט על המחשב המקומי שלכם.
שימו לב, לא תיראו ענפים חדשים שנוצרו בגיט (בשרת) עד שלא תמשכו אותם.
git checkout feature/header-component
מעבר לענף אחר, זה יגרום לשינוי הקוד בפרויקט בהתאם למה שקיים על אותו ענף
git merge bug/color-fix-in-header
פקודה זו תפעיל תהליך של שילוב הקוד בענף שכתבנו אל הענף שעליו אנחנו נמצאים. במידה שיש קונפליקטים אז הם יעלו בשלב הזה.
קונפליקטים הם שינויים באותו קובץ באותו מקום על ידי שתי ענפים שונים. כאשר GIT לא יודע איזה שינוי לקחת ולכן הוא מאותת לנו על זה ונותן לנו להחליט מה התצורה הסופית של אותו קובץ.
אם נריץ את שתי הפקודות האחרונות אחת אחרי השניה אנחנו נהיה על ענף feature/header-component
ונשלב אליו את הענף bug/color-fix-in-header. כך שהענף יכיל את הקוד שלו ועוד שינויים מקוד של הענף השני.
git fetch
הפקודה מושכת את כל המצביעים (הענפים) מהפרויקט המרוחק וכך אפשר להחשף לענפים חדשים שמפתח אחר העלה.
אלו הפקודות הבסיסיות לתפקוד בסביבת גיט בין אם עובדים לבד או בצוות. יש כמובן עוד פקודות שאפשר ללמוד ולקרוא עליהם.
