ניהול גרסאות

מתוך ויקיפדיה, האנציקלופדיה החופשית
קפיצה אל: ניווט, חיפוש

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