מדריך לעבודה עם SVN – בסיס

הסבר בסיסי על עבודה עם מדריך גרסאות
subversion logo

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

בגדול, SVN הוא ראשית כל מנהל גרסאות. מה זה מנהל גרסאות? היום מדובר בסטנדרט בפיתוח, אבל אני אסביר בכל זאת. מנהל גרסאות מאפשר לנו גמישות בכתיבת הקוד לאורך שלבים בחיי התוכנה. מנהל הגרסאות בעצם תומך בכתיבת הקוד. למשל, בואו נעמיד פנים שאני כותב ב-PHP תוכנה מסוימת שמדפיסה… ובכן, hello world.

$var = 'Hello World';
print $var;

אני אכניס את הקובץ הזה למנהל הגרסאות. מנהל הגרסאות יזכור את הקובץ ואת הקוד שיש בו. נניח שחל שינוי מסוים בהגדרות התוכנה ועכשיו רוצים שאני אכניס סימן קריאה ל-Hello World:

$var = 'Hello World!';
print $var;

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

בוא ונראה שימוש פשוט ב-SVN:

קומיטים לגרסה אחת של SVN
קומיטים לגרסה אחת של SVN

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

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

דוגמה של שני ענפים ב-SVN. פיצול, עבודה בשני הענפים במקביל ואז מיזוג.
דוגמה של שני ענפים ב-SVN. פיצול, עבודה בשני הענפים במקביל ואז מיזוג.

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

למדנו כאן כמה מונחים חדשים:

ענף – (באנגלית branch) – שם של גרסה. יש לנו תמיד את הגרסה המרכזית של המוצר. במקרה של SVN זה נקרא מסורתית trunk, אבל אפשר לקרוא לה בכל שם. אני יכול בכל רגע נתון להוציא מהגרסה שלי ענף. למשל, אם יש לי גרסה עובדת ויציבה, אני יכול להוציא ענף שבו אפתח בנחת פיצ'ר חדש. הענף הוא עותק של הגרסה המרכזית שרלוונטי לרגע שבו הוצאתי אותו. שני הענפים נחשבים כשונים ואפשר להכניס לתוכם קוד באופן נפרד.

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

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

תהליך בסיסי של SVN עובד ככה: יצירת ענף מרכזי ששמו הוא trunk, יציאה לענף develop, הכנסת קוד אליו כ-commit מספר פעמים ואז, כשאני מרוצה מהתוצאה, מיזוג הענף שלי חזרה לתוך ה-trunk והפצה ללקוחות (או העלאה לשרת במקרה של אתר אינטרנט). כולם מרוצים ושמחים, לא?

זהו, שלא – אבל על כך במאמר הבא. בו אסביר על קונפליקטים.

פוסטים נוספים שכדאי לקרוא

בינה מלאכותית

Safeguards על מודל שפה גדול (LLM)

פוסט בשילוב עם פודקאסט וסרטון על ההגנות שאפשר להציב על LLM בסביבת פרודקשן

גלילה לראש העמוד