איך לנהל גרסאות?
מבוא
מה אם נמאס לי לנהל גרסאות בצורה של:
- גרסה להצגה.
- גרסה 12.7.
- גרסה סופית.
- גרסה סופית אחרונה.
- גרסה סופית אחרונה באמת.
את השאלה הזו שאל את עצמו לינוס טורבאלדס בזמן שהוא פיתח את לינוקס. וכדי לפתור את הבעיה הוא בנה את גיט. העובד בכלליות כך:
לצפייה
אוקיי, אז פרוייקט בגיט נקרא Repository, בו אנחנו בעצם שומרים גרסאות כCommits, ואפילו קיים הבונוס של שימוש בBranches - המאפשר לעבוד על דברים בצורה מבודדת מהקוד הראשי, ובשלב מאוחר יותר אם נחפוץ בכך, לשלב אותם לראשי.
המרוחק
אוקי אז אנחנו יודעים בצורה מאוד בסיסית איך גיט עובד, עכשיו, מה זה הGitHub הזה שאני תמיד שומע עליו?
במשפט, גיטהאב זהו שירות ענן שאנו יכולים לאחסן בו את הריפוזיטורי שלנו. אבל זהו לא רק גיטהאב הנותן את השירות הזה, קיימות אופציות נוספות למשל GitLab פשוט גיטהאב הוא הפופולארי ביותר. השרת אליו נסנכרן את הRepository שלנו יקרא הRemote.
גיטקראקן
יוסי - "אז אתה אומר לי שאני צריך לזכור את כל הפקודות המעצבנות האלו רק כדי לנהל גרסאות? זה לא קצת מוגזם?"
ובכן יוסי, אתה צודק! יש לנו באמת מקום מוגבל במוח וחבל להכניס אליו דברים מיותרים. ובמיוחד בשביל זה פיתחו את GitKraken הבעצם משמש כממשק משתמש ידידותי לשימוש בגיט. נלמד עליו ותוך כדי נעמיק הרבה יותר בGIT.
לצפייה
הסרטון הזה באמת מכסה כמעט כל מה שיש לדעת על גיט, מMerge, לאיך לעבוד עם Remote, לMerge Requests.
הסטנדרט
תצורת העבודה על בראנצים בגיט משתנה בין מקום למקום, אבל תראה בערך כך,
לצפייה
נסכם,
feature branch- הבראנץ בו יתבצע הפיתוח של הקוד, ובו נבדוק את השירות בצורה ראשונית. יש לנסות להקפיד שכל קומיט יתקמפל.development- בראנץ של הקוד המיועד לבדיקות אינטגרציה של השירות כחלק מכלל המערכת.staging- בראנץ שלא תמיד קיים, ומיועד לבדיקות עמוסים על השירות.master- הבראנץ הראשי של הקוד, שיהיה פרוס בפרודקשן.
בכל מעבר בין בראנצים יש לעשות Code Review.
אין תגובות:
הוסף רשומת תגובה