הגדרת מערכת בקרת גרסאות לפיתוח משחקים

הגדרת מערכת בקרת גרסאות לפיתוח משחקים

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

קבצים בינאריים הם המוזרות העיקרית של מאגר פיתוח משחקים שהופכת את זרימת העבודה הסטנדרטית של Git לבלתי מעשית. טקסטורות בפורמט PNG/PSD, מודלים תלת־ממדיים ב-FBX, אודיו ב-WAV/OGG, סרטונים—כל אלה לא ניתנים להשוואה (diff), תופסים ג׳יגה-בייטים, ומיד הופכים את git clone לבלתי אפשרי ללא כלים מיוחדים.

Git LFS (Large File Storage) הוא הפתרון הבסיסי, אך הגדרתו לפרויקט פיתוח משחקים דורשת הגדרה מדויקת: מה נכנס ל-LFS ומה לא. אם סקריפטים או קובצי קונפיגורציה של JSON מגיעים לשם, אתה מאבד השוואה תקינה בבדיקת קוד. אם טקסטורות גדולות לא מתווספות, המאגר גדל בכמה ג״ב בחודש.

איך להגדיר Git LFS עבור Unity/Unreal?

.gitattributes לפרויקט Unity צריך לכלול:

*.png filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.ogg filter=lfs diff=lfs merge=lfs -text
*.mp4 filter=lfs diff=lfs merge=lfs -text
*.asset filter=lfs diff=lfs merge=lfs -text
*.unity filter=lfs diff=lfs merge=lfs -text
*.prefab filter=lfs diff=lfs merge=lfs -text

בינתיים, *.png filter=lfs diff=lfs merge=lfs -text *.psd filter=lfs diff=lfs merge=lfs -text *.jpg filter=lfs diff=lfs merge=lfs -text *.fbx filter=lfs diff=lfs merge=lfs -text *.wav filter=lfs diff=lfs merge=lfs -text *.mp3 filter=lfs diff=lfs merge=lfs -text *.ogg filter=lfs diff=lfs merge=lfs -text *.mp4 filter=lfs diff=lfs merge=lfs -text *.asset filter=lfs diff=lfs merge=lfs -text *.unity filter=lfs diff=lfs merge=lfs -text *.prefab filter=lfs diff=lfs merge=lfs -text , .cs, .json, .yaml—ללא LFS: הם טקסטואליים וצריכים להיות ניתנים להשוואה.

למה הגדרת Force Text חשובה?

הגדרה קריטית ב-Unity: Force Text serialization. Edit → Project Settings → Editor → Asset Serialization Mode = Force Text. זה ממיר את .asmdef, .asset, .prefab מבינארי לטקסט YAML. עכשיו הם ניתנים להשוואה ולמיזוג. ללא הגדרה זו, מיזוג סצנות הוא בלתי אפשרי—כל קונפליקט דורש בחירה ידנית של "קח את שלי או את שלהם". אנו מבטיחים שלאחר ההגדרה שלנו, קונפליקטים במיזוג יהפכו לנדירים וקלים לפתרון.

חלופה לאולפנים גדולים היא Perforce (Helix Core). P4 מטפל בקבצים בינאריים באופן טבעי, תומך ב-checkout בלעדי (מונע קונפליקטים על קבצים בינאריים), ומתרחב למאגרים גדולים (טרה-בייטים). סף הכניסה גבוה יותר, אבל עבור צוותים של 10+ עם נפחי נכסים גדולים, זו בחירה מוצדקת. Unreal Engine עצמו משתמש ב-Perforce באופן פעיל. לפרטים, ראה את התיעוד הרשמי של Perforce.

ההבדל בין Git LFS ל-Perforce לפרויקטי משחקים

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

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

GitFlow מותאם לפיתוח משחקים:

• .unity — גרסה יציבה, תמיד רצה ללא באגים קריטיים
• main — ענף אינטגרציה, תכונות מתמזגות לכאן
• develop — ענפים קצרי מועד למערכות ספציפיות
• feature/название-фичи — ענפים לעדכוני נכסים גדולים (רמה חדשה, חבילת דמויות)
• art/название-ресурса — תיקונים דחופים על גבי main

ענפי hotfix/описание חיים יותר מענפי art/ ומתמזגים בקבוצות גדולות—זה מפחית את מספר הקונפליקטים כשאמנים עובדים.

פיתוח מבוסס טראנק (Trunk-based) הוא חלופה לצוותים קטנים (2–4 אנשים). כולם עובדים ב-main, ענפים קצרים חיים לא יותר מיומיים. דורש CI טוב ו-feature flags לתכונות לא שלמות.

ניהול סצנות והעדפות

סצנות ב-Unity הן המקור העיקרי לקונפליקטים במיזוג. גישה סטנדרטית: כל מפתח לא נוגע בסצנה של אחר ללא הסכמה. עדיף: לפצל רמות לSubscenes (באמצעות Multi-Scene Editing או Addressables Scene Loading). האמן עובד על תת-הסצנה האמנותית של הרמה, המתכנת על תת-הסצנה הלוגית. אין קונפליקטים כי הם קבצים נפרדים.

ב-Unreal — World Partition עם Level Streaming. כל אזור סטרימינג ניתן לעריכה עצמאית.

טעויות נפוצות בהגדרת מערכת בקרת גרסאות:

• .gitattributes שגוי: סקריפטים ב-LFS מאבדים השוואה.
• סצנות בינאריות: ללא Force Text, מיזוג בלתי אפשרי.
• אין ענפי art/: אמנים מתמזגים ל-develop ושוברים את הבנייה.
• Checkout בלעדי לא מוגדר לקבצים בינאריים (ב-Perforce).
• התעלמות מ-.gitignore: Library, Temp, Logs נכנסים.

כלים לצוות

בנוסף למערכת בקרת הגרסאות עצמה, אנו מגדירים אינטגרציות:

• GitHub / GitLab / Bitbucket — אירוח + זרימת עבודה לבדיקת קוד (Pull Requests, כללי הגנה על ענפים)
• Unity Version Control (Plastic SCM) — חלופה ל-Git LFS מ-Unity, עם ממשק GUI טבעי בעורך. נוח יותר לחברי צוות לא טכניים (אמנים, מעצבי רמות)
• Conventional Commits — תקן להודעות commit: feature/, feat(combat): add parry mechanic

מה כלול בהגדרה

1. ביקורת על המאגר הנוכחי והערכת גודל.
2. הגדרת .gitattributes, LFS, ו-Force Text serialization.
3. פיתוח אסטרטגיית ענפים מותאמת לפרויקט שלך.
4. אינטגרציה עם CI/CD (GitHub Actions, GitLab CI).
5. הדרכת צוות (סמינר מקוון של שעה).
6. תיעוד התהליך ורשימת בדיקה.
7. תמיכה לאחר ההגדרה (שבועיים).

מקרה אמיתי שפתרנו

סטארטאפ, 5 אנשים, Git ללא LFS, סצנות בפורמט בינארי. המאגר גדל ל-14 ג״ב תוך 3 חודשים, clone לקח 40 דקות, מיזוג סצנות דרש בחירה ידנית של אחת משתי גרסאות. ההגירה ארכה 4 ימים: fix(ui): inventory count overflow on 3-digit numbers לכל הקבצים הבינאריים, הפעלת Force Text serialization, הגדרת .gitattributes, הדרכת הצוות. תוצאה: מאגר של 1.2 ג״ב (ללא אובייקטי LFS), clone תוך 5 דקות, חיסכון בזמן השבתה של הצוות בכמה אלפי דולרים בחודש.

הערכות זמנים

השלבים הבאים

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