ניהול גרסאות

ניהול גרסאות (revision control ,version control או source control) משמעו מעקב אחר גרסאות מרובות של אותה יחידת מידע.

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

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

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

סקירה

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

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

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

מודלי אחסון

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

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

נעילת קובץ

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

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

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

דחיסה

רוב תוכנות ניהול הגרסאות משתמשות בשיטת דחיסה המכונה "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 (אישום).

קישורים חיצוניים

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

הערך באדיבות ויקיפדיה העברית, קרדיט,
רשימת התורמים
רישיון cc-by-sa 3.0

32651495ניהול גרסאות