ניהול גרסאות

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

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

יש לערוך ערך זה. ייתכן שהערך סובל מבעיות ניסוח, סגנון טעון שיפור או צורך בהגהה, או שיש לעצב אותו, או מפגמים טכניים כגון מיעוט קישורים פנימיים.
אתם מוזמנים לסייע ולערוך את הערך. אם לדעתכם אין צורך בעריכת הערך, ניתן להסיר את התבנית. ייתכן שתמצאו פירוט בדף השיחה.
הנדסת תוכנה
ערך זה שייך לקטגוריית הנדסת תוכנה
פעילויות ושלבים
דרישותניתוחאפיוןארכיטקטורהעיצובתכנותדיבוגבדיקהאימותבנייהפריסהתפעולתחזוקה
מתודולוגיות
זריזותמפל המיםתכנת ותקןCrystal ClearScrumUnified ProcessExtreme Programmingאינטגרציה רציפהDevOps
תחומים תומכים
ניהול פרויקטיםניהול תצורהתיעודהבטחת איכותProfiling
כלים
מהדרמקשרמפרשIDEניהול גרסאותאוטומציית בנייה

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

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

ההבדל בין ניהול גרסאות לבקרת גרסאות עריכה

בניהול גרסאות כל "גרסה" יכולה להכיל מספר שינויים ומסומנת ב"מספר גרסה" שהוא כמה מספרים שמופרדים ביניהם בנקודה, לדוגמה: 2.0, 2.1.1, 4.3.2.1, וכו'. במספר הגרסה יש משמעות לכל מספר:

  • המספר השמאלי ביותר הוא גרסה ראשית (Major) - הוא משתנה כאשר עושים שינוי משמעותי, לדוגמה: משנים ארכיטקטורה של מערכת.
  • המספר הבא אחריו הוא גרסה מינורית (Minor) שמשתנה כאשר מוסיפים יכולות או עושים שינויים במערכת.
  • המספר השלישי הוא מספר תיקון (Patch) שמשתנה כאשר עושים תיקון מתוכנן במערכת.
  • המספר הרביעי (אם קיים) הוא תיקון דחוף (Hot Fix) - התגלתה תקלה במערכת שפוגעת ביכולת להשתמש בה, היא תוקנה והגרסה הזו מכילה את התיקון.

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

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

סקירה עריכה

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

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

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

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

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

מודלי אחסון עריכה

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

  • מודלי אחסון ריכוזיים - באופן מסורתי, מערכות בקרת גרסאות השתמשו במודלי אחסון ריכוזיים, שבהם כל פונקציות ניהול הגרסאות בוצעו על שרת משותף. לכן, הם מכונים גם מודלי שרת-לקוח: בדרך-כלל, המשתמש המקומי מתחבר לשרת המרכזי, שאצלו נמצא העותק הראשי.
  • מודלי אחסון מבוזרים - מערכות כגון גיט(git) ומרקוריאל עובדות במודל מבוזר: כל מפתח עובד עם מקום אחסון (Repository) מקומי משלו והשינויים משולבים בין ה-Repositories בשלב נפרד. מצב פעולה זה מאפשר למפתחים לעבוד אף ללא חיבור רשת ובנוסף הוא מאפשר למפתחים יכולות ניהול גרסאות מלאות, ללא צורך בקבלת הרשאות, שמוענקות על ידי רשות מרכזית.

נעילת קובץ עריכה

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

  • נעילת קבצים – זוהי הדרך הפשוטה והפרימיטיבית ביותר. כאשר מפתח רוצה לעבוד על קובץ, הוא "שם מנעול" וירטואלי על הקובץ. בזמן הזה, ועד שאותו משתמש שומר באופן סופי את הקובץ ומשחרר את המנעול, המערכת מונעת מכל משתמש אחר לשמור שינויים לקובץ. בגישה הזו עושה שימוש, לדוגמה, מערכת Microsoft Visual SourceSafe.
  • מיזוג שינויים – מפתחים שונים יכולים לעבוד במקביל על עותקים שונים של אותו קובץ. אם מתגלה (בדרך-כלל, בזמן קבלת עדכון לעותק המקומי מהמאגר הראשי) שמישהו אחר שינה את הקובץ, ובוצעו בו גם שינויים מקומיים, נעשה ניסיון למזג את כל השינויים לעותק אחד קוהרנטי. מערכת CVS, לדוגמה, עובדת בדרך זו.

במערכת בקרת גרסאות מבוזרות אין אפשרות לבדוק נעילה על הקובץ, ולכן כולן משתמשות במיזוג (Merge) שינויים, אבל במערכות האלו קיימות מגוון אפשרויות לעקוב אחר שינויים שבוצעו על ידי משתמשים שונים, להשוות בין השינויים, ולהחליט את אלו שינויים לקבל ואיך בדיוק לבצע את המיזוג בין השינויים. המיזוג יכול להתבצע בצורה אוטומטית או ידנית. לדוגמה: מספר משתמשים ביצעו שינויים במסמך, כל השינויים חשובים אבל צריך למזג אותם בצורה חכמה, שורה שכתב משתמש א' ואחר כך שורה שכתב משתמש ב', שוב שורה שכתב משתמש א' ואז שורה שכתב משתמש ג', וכן הלאה - ניתן לבצע כזה מיזוג ואף מיזוגים מסובכים יותר.

דחיסה עריכה

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

אוצר מילים שכיח עריכה

Repository (מאגר)
  ערך מורחב – רפוזיטורי

המאגר שבו נשמרים קובצי המידע ההיסטוריים והנוכחיים - לרוב בשרת. לעיתים משתמשים במילה depot (מחסן).

Working copy (עותק עבודה)
עותק מקומי של קבצים מה-Repository, בזמן או בגרסה מסוימים. כל העבודה הנעשית על קובצי המאגר מתבצעת בעותק העבודה, ומכאן שמו.
Check-out
פעולה שיוצרת עותק עבודה מקומי מהמאגר. פעולה זו יכולה להתבצע על גרסה מבוקשת או על הגרסה האחרונה. פעולה זו קרויה גם checkout או co.
Commit (שמירת שינויים)
מתרחש כאשר העתק של שינויים שנעשו בעותק העבודה נכתבים למאגר. לעיתים קרוי submit (שליחה), install (התקנה/קיבוע), check-in או ci (רישום).
Change
מייצג שינוי מסוים במסמך תחת ניהול גרסאות. הגרעיניות של מה שנחשב לשינוי משתנה בין מערכת למערכת. קרוי גם diff (קיצור של difference - הבדל) או delta (דלתא - הפרש).
Change list
במערכות ניהול גרסאות שתומכות בטרנזקציה להחלת Commit מרובה שינויים, changelist (או change set (קבוצת שינויים)) מזהה קבוצת שינויים שנעשו כ-commit יחיד (גרסה אחת).
Update
פעולת מיזוג שינויים שנעשו במאגר על ידי אנשים אחרים בצוות, לתוך עותק העבודה המקומי. קרוי גם sync (קיצור של synchronization - סנכרון).
Branch
סט קבצים תחת ניהול גרסאות עשוי להסתעף/להתפצל בנקודה בזמן, כך שמאותו זמן ואילך, שני עותקים של קבצים אלו עשויים להוות את הבסיס ולהיות מפותחים באופן עצמאי, ללא תלות זה בזה, במהירויות שונות ובאופנים שונים. קרוי גם forked (מפוצל).
Merge
מיזוג שני סטים של שינויים, שנעשו בקובץ או בסט של קבצים, לתוך גרסה אחידה של קובץ או של סט קבצים זה. קרוי גם integration (אינטגרציה - שילוב/מיזוג). מצב זה יכול לקרות:
  • כאשר משתמש אחד, שעובד על קבצים אלו, מבצע לתוך עותק העבודה שלו עדכונים עם שינויים שנעשו על ידי אחרים ונשמרו לתוך המאגר. באופן הפוך, תהליך דומה יכול לקרות במאגר כאשר משתמש מנסה לבצע check-in לשינויים שלו.
  • לאחר הסתעפות (branched) של סט קבצים, כאשר בעיה שהייתה קיימת לפני ההסתעפות תוקנה במסעף אחד וצריכה להיות ממוזגת לתוך המסעף השני.
  • כאשר מבקשים למזג ליחידה אחת, קבצים שפוצלו (branched) ופותחו באופן עצמאי במשך תקופה.
Revision
גרסה בתוך שרשרת של שינויים. קרוי גם version (גרסה).
Tag
סימון קבוע לקבצים רבים בנקודת זמן חשובה. קבצים אלו, בנקודת זמן זו, יכולים כולם להיות מסומנים בשם בעל משמעות מובנת למשתמש. קרוי גם release (שחרור) או Label (תווית).
Import (ייבוא)
פעולת העתקה של עץ תיקיות מקומי, שאינו עותק העבודה, לתוך המאגר.
Export (ייצוא)
פעולה דומה ל-check-out, מלבד זאת שעץ התיקיות המקומי שהיא יוצרת נקי מ-Metadata של ניהול גרסאות, כזה שבו נעשה שימוש בעותק העבודה. לעיתים קרובות נעשה בזה שימוש לקראת פרסום התוכן.
Conflict (התנגשות)
קונפליקט מתרחש כאשר שני שינויים סותרים נעשו לאותו מסמך. מאחר שהתוכנה אינה נבונה דיה להחליט איזה מהשינויים הוא הנכון, המשתמש נדרש לפתור (resolve) את הקונפליקט בעצמו באופן ידני.
Resolve
התערבות המשתמש, במטרה ליישב התנגשות של שני שינויים באותו מסמך.
Annotate
הצגת תוכנו של קובץ, כשלצידו הגרסה שממנה הגיעה כל שורה. משמש, בדרך-כלל, להראות מי אחראי לחלק מסוים מהתוכן, ולכן ידוע גם כ־blame (אישום).

ראו גם עריכה

קישורים חיצוניים עריכה

  מדיה וקבצים בנושא ניהול גרסאות בוויקישיתוף