כותבים קוד יותר טוב - גיבוי וניהול גרסאות

הקדמה

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

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

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

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

חוק מרפי

"כל דבר שיכול להשתבש, אכן ישתבש", אמר אדוארד מרפי. ובמקור: Anything that can go wrong, will go wrong.
ואני יכול להוסיף מניסיון, שזה כנראה יקרה בזמן הכי גרוע מבחינתכם.

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

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


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

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

הפתרון לזה הוא גיבוי. ואם לא תעשו את זה נכון, הוא לא יהיה שווה כלום.

גיבוי של כל המחשב

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

מה זה גיבוי

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

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

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

מה לגבות

כמה שיותר דברים כמובן.

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

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

איפה לגבות

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

אל תחשבו רק על כונני SSD החדישים לטובת הגיבויים. נכון ל-2025 כונן HDD (זה עם הדיסקים המסתובבים) עולה רבע מהאפשרות של SSD (המבוסס על זכרונות FLASH) באותו הגודל. ואם אתם צריכים לגבות הרבה מידע, מעל 4TB למשל, אז אין לכם יותר מדי ברירה, אלא להשתמש בכונני HDD, או להיפרד מסכומים מאוד גדולים לטובת שרתים יעודיים לגיבויים.

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

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

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

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

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

יש גם את שרתי הענן, כמו Google drive, AWS, Microsoft 365, DropBox ודומיהם, אבל הם לא זולים. אם יש לכם כמה דברים מאוד חשובים, גם זו אפשרות שיכולה לספק מענה.

בדקו את הגיבויים

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

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

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

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

שכפול הדיסק - RAID1

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

RAID אלה ראשי תיבות של Redundant Array of Independent Disks - מערך יתיר של דיסקים עצמאיים, או לפעמים מוזכר גם כ-Redundant Array of Inexpensive Disks - מערך יתיר של דיסקים זולים.

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

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

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

יש רמות RAID נוספות, המפזרות את הנתונים על פני יותר מ-2 דיסקים, למשל ב-RAID5 צריך לפחות 3 דיסקים. 2 מהם שומרים 50% מהנתונים כל אחד והשלישי שומר חתימת HASH שבעזרתה אפשר לשחזר את הנתונים של שני הדיסקים הראשיים אם אחד מהם מפסיק לעבוד. כמו במקרה הקודם, אפשר להשתמש ביותר מ-3 דיסקים למערך כזה. במקרה זה תקבלו יותר מקום לאחסון נתונים. מכיוון שכל הדיסקים במערך זהים, גודל המערך יהיה כגודל הדיסק כפול (כמות הדיסקים פחות 1).

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

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

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

האם RAID זמין במחשב שלכם

בעבר הרחוק טכנולוגיה זו היתה בשימוש רק בשרתים יקרים ודרשה בקר RAID יקר ומיוחד, כך גם הדיסקים שנועדו למערכים כאלה היו מיוחדים, עם ממשק SCSI (זה ממשק, לא ה-DJ).

עם הזמן הממשק של הדיסקים הביתיים השתפר ונהיה אמין מספיק לשימוש גם בשרתים (SATA). משם הגיעה הפרשנות ל-RAID כ-Redundant Array of Inexpensive Disks, מערך של דיסקים זולים, בהשוואה לדיסקים SCSI שהיו פי כמה וכמה יותר יקרים.

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

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

למה להגדיר RAID

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

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

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

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

איך זה עובד אצלי

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

בבית המחשב שלי משמש כשרת ביתי עם SSD למערכת הפעלה (לינוקס) ושני כונני HDD במערך של RAID1 לנתונים. כל העבודה שלי מאוחסנת על ה-RAID. יש גיבוי יומי של כל הדברים החשובים לתיקיית Backup, שגם היא על ה-RAID. גם המחשבים של הילדים (חלונות) מגבים את הנתונים שלהם לתיקיית Backup על המחשב הזה. הגיבויים מסודרים כך שלכל מחשב יש תת-תיקיה משלו.

בעבודה יש לי MicroServer של HP, שיש בו RAID1 של שני SSD, עליהם מותקנת מערכת הפעלה (לינוקס), ועוד RAID1 של שני HDD לנתונים. הגיבויים של כל המחשבים במשרד נשמרים בתיקיות מיועדות לכל מחשב בתיקיית ה-Backup, כמו בבית. המחשב שלי ניגש לתיקיות העבודה על השרת דרך NFS - Network File System. אלה אותן התיקיות עליהן אני עובד בבית, רק שזה העתק של התוכן בשרת של המשרד.

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


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

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

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

ניהול גרסאות

סעיף זה קשור גם לגיבוי של הקוד, גם לתיעוד שלו וגם לעבודת צוות.

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

מה זה מערכת ניהול קוד / ניהול גרסאות

ישנן מערכות מיוחדות שנועדו לעזור למפתחים לעקוב אחר השינויים שהם מבצעים בקוד ולנהל גרסאות. מערכות אלה לרוב מכונות כ-SCM - Source Code Management או VCS - Version Control Systems.

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

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

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

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

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

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

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

מרכזי או מבוזר

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

תחשבו על ספריה. לקחתם ספר (עשיתם check-out לקובץ), רשמו אתכם במערכת והספר הזה אצלכם עד שתחזירו אותו (תעשו check-in). אם מישהו אחר בא לספריה ורוצה לקחת את אותו הספר, הספרנית תגיד שהיא מצטערת, הספר הזה כרגע אצל מישהו אחר, תבוא מאוחר יותר.

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

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

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

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

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

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

לא יודע מה קורה היום בחברות גדולות, אבל בתקופתי היו חברות שהעדיפו מערכות עם בסיס מרכזי, והיו כאלה שהשתמשו במערכת מבוזרת (ואז היינו רבים מי יקבל את הסינג'ור של להיות אינטגרטור של גרסה).
בתחום של החובבים נראה שכולם משתמשים ב-GitHub, גם בגלל שהוא מאוד נוח לעבודה כמפתח, וגם בגלל שהוא מאוד נוח לשיתוף של הקוד עם אחרים, ניהול גרסאות, ניהול תלונות ובקשות… וכל זה בחינם!

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

מה עושים אם לא רוצים שמישהו יראה את הקוד שלכם? סטארטאפ או חברה קטנה למשל? נראה ש-GitHub מאפשרים לנהל פרוייקטים פרטיים גם בחשבון החינמי (משום מה אני זוכר שחינמי אפשר רק פרוייקטים פומביים). יש גם חשבונות עם יותר שכלולים שעולים החל מ-$4 לחודש לאדם.

אבל אם ממש ממש לא רוצים שהקוד יהיה בשרת של מישהו אחר, אפשר להקים שרת GIT על כל מחשב שתרצו. זהו פרוייקט open-source והוא חינמי וזמין לכל מערכות ההפעלה. זה יכול להיות שרת שזמין 24/7 מרחוק כדי שכל מפתח יוכל להפקיד את השינויים שלו מתי שירצה. אפשר לעבוד גם Offline, על הלפטופים של כל מפתח בנפרד, להיפגש יום אחד בשבוע כדי לדחוף את כל השינויים לאחד מהם, לפתור את ההתנגשויות אם יש ולסנכרן את כל המחשבים עם הגרסה העדכנית ביותר כדי שכל אחד יוכל לחזור הביתה כדי להמשיך לעבוד על הקוד האחרון.

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

לא חייבים GIT, יש מערכות אחרות, גם הן חינמיות. יש מערכות עתיקות יותר כמו Mercurial (מבוזרת), Subversion (מרכזית), ו-SVN (מרכזית). יש גם את האתר SourceForge שדומה במהותו ל-GitHub. פשוט GIT ו-GitHub אלה מערכות פופולריות הרבה יותר בימינו.

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

ה-GIT עצמו הוא תוכנה שמופעלת בשורות פקודה (command line) מטבעו, אבל יש לו תוספי GUI שהופכים את העבודה להרבה יותר נוחה. אם אתם עובדים עם VSCode, תוכלו להשתמש ברוב האפשרויות של GIT ישירות מתוך הממשק של VSCode עצמו.

פרוייקטים שלי שהם Open Source גם מנוהלים ב-GIT ומועלים ל-GitHub כדי שיהיו זמינים לכולם. תוכל להציץ בספריית ה-EBF שהעלתי לשם. גם חברות גדולות, כמו SparkFun ו-Adafruit מנהלים את הקוד שלהם ב-GitHub.

Commit early, commit often

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

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


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