Git לפיתוח משחקים

14 במרץ, 2012 לאורך השנים השתמשתי במספר מערכות בקרת גרסאות שונות להפקת סרטים ומשחקים: CVS , Perforce , ואפילו כמה כלים פנימיים שפותחו בארגון. תמיד נתפסו בעיניי כרע הכרחי מסורבל – אמנם חיוניות למעקב אחר עבודה בפרויקט גדול, אך גם מקור מתמיד לבלבול, לצווארי בקבוק ולחוסר גמישות בהפקה. גיט (Git) צץ לראשונה על מסך הרדאר שלי לפני כשישה חודשים. היא נראתה עוצמתית וגמישה להפליא. המפתחים ב-Massively Fun כבר השתמשו בה לפיתוח קוד כאשר הצטרפתי לצוות. הייתי סקרן לראות אם נוכל להתאים אותה גם להפקת אמנות (Art Production). פוסט זה מספר את סיפור מה שקרה לאחר מכן. רקע: מהו Git?

Git היא מערכת בקרת גרסאות מבוזרת . רוב העוסקים בפיתוח משחקים כבר מכירים לפחות מערכת בקרת גרסאות אחת אחרת כמו Subversion או Perforce . בדומה למערכות הללו, Git מאפשרת לנו לעקוב אחר הגרסאות הרבות והשונות של כל הקבצים הנכנסים לפרויקט. עם זאת, Subversion ו-Perforce הן מערכות מרכזיות – כל הקבצים נשמרים (Check-in) או נשלפים (Check-out) ממאגר (Repository) הממוקם בשרת מרכזי. Git שונה בכך שהיא אינה תלויה בשרת מרכזי. כל משתמש מקבל עותק מלא ומקיף של כל המאגר, כולל כל ההיסטוריה והגרסאות שלו. למבנה זה יש מספר השלכות חשובות , שרובן חיוביות. אך מה שבולט ביותר בעיניי ב-Git הוא האופן שבו היא הופכת פעולות של הסתעפות (Branch) ומיזוג (Merge) כמעט לפעוטות. ניתן ליצור הסתעפות כדי לעבוד על רעיון ניסיוני, אחרת כדי לתקן בעיה לא קשורה, ועוד אחת עבור תכונה חדשה. ניתן לנוע במהירות בין הסתעפויות שונות אלו, ולמזג אותן בחזרה יחד לפי הצורך. זוהי תכונה שימושית להפליא. מכשולים למרות יתרונותיה הרבים, לגיט “כפי שהיא” (Off-the-shelf) יש שני פגמים ברורים בכל הנוגע להפקת אמנות: היא אינה ידידותית לאמנים. ממשק ברירת המחדל של Git הוא שורת הפקודה (Command Line). ישנם פקודות ואפשרויות רבות ללמידה, יחד עם מושגים בסיסיים השונים דיים ממערכות בקרת גרסאות אחרות כדי לבלבל. התיעוד אמנם בשפע, אך לעיתים קרובות קשה להבנה. כל אלו מצטרפים יחד לחבילה שאינה נגישה במיוחד ומעט מאיימת. היא לא נבנתה לנהל קבצים בינאריים גדולים מהסוג שאמנים יוצרים. העובדה שכל מאגר מקומי מכיל את כל ההיסטוריה והגרסאות פירושה שכמות גדולה של יצירות אמנות המשתנות במהירות יכולה לבלות נפח אחסון רב בזמן קצר. מצאנו פתרונות לשתי הבעיות הללו. הממשק חשוב קיימים מספר ממשקים גרפיים טובים ל-Git. אמנים עדיין צריכים להבין מושגי יסוד של Git, אך חזית (Front-end) מתוכננת היטב מקלה משמעותית על הלימוד והשימוש. גילינו ש-SourceTree של Atlassian עבד מצוין בסביבת העבודה מבוססת ה-Mac שלנו: הוא עוצמתי, אינטואיטיבי וחינמי (נכון לעכשיו) – שיקול חשוב עבור סטארטאפ זריז. צוות SourceTree גם הגיב במהירות (< 12 שעות) לפנייות התמיכה שלנו בטוויטר. הרחבת Git מתוחכמת Git-media מטפלת בחסרונות של Git ביחס לקבצים בינאריים גדולים. זוהי הרחבה ל-Git המאפשרת לכם לאחסן קבצים מחוץ ל-Git.

Git עדיין עוקבת אחר גרסאות הקבצים; היא פשוט מאחסנת את תוכן הקבצים במקום כלשהו מחוץ למאגר. תכננו לאחסן את הקבצים הבינאריים הגדולים שלנו בענן S3 של אמזון. לא כל כך מהר השימוש ב-SourceTree יחד עם Git-media מציב עם זאת מכשול נסתר (Gotcha): העברת קבצים בין המאגרים שלנו לבין Amazon S3 דורשת מאיתנו להריץ פקודת מעטפת (Shell Command); כלומר, $ git media sync תהליך עבודה (Workflow) המחייב אמנים לעזוב את הנוחות היחסית של יישום גרפי כדי להקליד פקודות מעטפת אינו ידידותי לאמנים. SourceTree אמנם מספק דרך להריץ פקודה זו כפעולה מותאמת אישית, אך זה לא היה מספיק טוב. האמנים עדיין היו צריכים לזכור לבצע זאת בזמנים המתאימים. מוקדם או מאחר הם היו שוכחים, ומישהו היה מבזבז זמן יקר בניסיון להבין מה השתבש ולתקן זאת. כיצד נוכל לגרום ל-SourceTree ול-git-media לעבוד יחד בהרמוניה?

הבחירה שלנו: Unity Asset Store — אמנות מוכנה, כלים ותבניות שנופלים ישר לתוך פרויקט ה-Unity שלך.

Git Wrap כתבנו סקריפט מעטפת (Wrapper Script) גנרי שמריץ באופן אופציונלי פקודות אחרות לפני ו/או אחרי פקודת ה-git עצמה. הגדרנו אותו כך שיפעיל אוטומטית את ‘git media sync’ לפני או אחרי פקודות המתקשרות עם מאגר מרוחק, לפי הצורך. הגדרנו את SourceTree כך שיפעיל את המעטפת במקום את גרסת ה-Git המגיעה כברירת מחדל. קוד המקור של המעטפת זמין כאן ב-Github . ההרפתקה נמשכת הייתי רוצה לספר לכם שזה היה סוף הסיפור, ש-SourceTree ו-git-media עבדו יחדיו בצורה חלקה וכולנו חיינו באושר ועושר עד עצם היום הזה. הם אכן עבדו, עד נקודה מסוימת. למרבה הצער, זה לא היה מספיק טוב.

SourceTree בדרך כלל עושה עבודה טובה בתצוגה מקדימה של קבצי תמונה. זה קריטי עבור אמנים כאשר הם שומרים (Committing) או ממזגים שינויים בקבצים כאלה. אך השימוש ב-git-media שבר את היכולת של SourceTree להציג תצוגה מקדימה של קבצים אלו, משום שמשמעות הדבר הייתה שאנו לא מאחסנים עוד את התמונות בתוך Git; אנו מאחסנים רק מידע גרסה אודות התמונות. לא הצלחנו למצוא דרך מקובלת לעקוף זאת; זה היה גורם מכריע שלא אפשר להמשיך כך. נכון לכתיבת שורות אלו, אנו מנסים גישה חדשה תוך שימוש בתכונת ה-submodule של Git. אחסון נכסי האמנות שלנו ב-submodule היא דרך נוספת למזער את הגודל של מאגר הפרויקט הראשי.

SourceTree מבין ותומך ב-submodules בצורה טובה למדי, ויכולתו להציג תצוגה מקדימה של תמונות נשארת שלמה. ל-Submodules אכן יש כמה מוזרויות, אך אין בהן דבר שנראה כמשובש מדי עבור תהליך העבודה של האמנים שלנו. המשיכו לעקוב אחר עדכונים在此 מרחב זה; נעדכן אתכם כיצד הדברים יתפתחו. תגובות בלוג מופעלות על ידי Disqus