Git لتطوير الألعاب

متعة هائلة مع Git لتطوير الألعاب Git لتطوير الألعاب 14 مارس، 2012 لقد استخدمت على مر السنين عدة أنظمة مختلفة للتحكم في الإصدارات لإنتاج الأفلام والألعاب: CVS وPerforce، وحتى بعض الأدوات الداخلية. لطالما بدت لي كأنها شرور ضرورية لكنها غير عملية – لا غنى عنها لتتبع العمل في المشاريع الكبيرة، لكنها أيضًا مصدر مستمر للارتباك واختناقات العمل وعدم المرونة في الإنتاج. ظهر Git لأول مرة على راداري قبل حوالي ستة أشهر. بدا قويًا ومرنًا بشكل مذهل. كان مطورو “ماسيفلي فن” (Massively Fun) يستخدمونه بالفعل لتطوير الكود عندما انضممت إلى الفريق. كنت حريصًا على معرفة ما إذا كان بإمكاننا جعله يعمل أيضًا لإنتاج المحتوى الفني. تحكي هذه التدوينة قصة ما حدث. الخلفية: ما هو Git؟ Git هو نظام تحكم في الإصدارات موزَّع. سيكون معظم العاملين في مجال تطوير الألعاب على دراية مسبقة بنظام واحد على الأقل من أنظمة التحكم في الإصدارات مثل Subversion أو Perforce. ومثل هذه الأنظمة الأخرى، يسمح لنا Git بتتبع العديد من الإصدارات المختلفة لجميع الملفات التي تدخل في المشروع. لكن Subversion وPerforce هما نظامان مركزيان – حيث يتم حفظ جميع الملفات أو استخراجها من مستودع موجود على خادم مركزي. يختلف Git عن ذلك. فهو لا يعتمد على خادم مركزي. يحصل كل مستخدم على نسخة كاملة من المستودع بأكمله، بما في ذلك كامل سجله ومراجعاته. لهذا التصميم عدد من الآثار المهمة، ومعظمها إيجابي. لكن ما يجعل Git يبرز في عيني أكثر من غيره هو كيف يجعل عمليات التفرع (branch) والدمج (merge) شبه تافهة. يمكنك إنشاء فرع للعمل على فكرة تجريبية، وفرع آخر لإصلاح مشكلة غير ذات صلة، وثالث لميزة جديدة. يمكنك التنقل بسرعة بين هذه الفروع المختلفة، ويمكنك دمجها معًا عند الحاجة. إنها ميزة مفيدة بشكل لا يصدق. عقبات في الطريق رغم نقاط قوته العديدة، فإن Git الجاهز للاستخدام يعاني من عيبين واضحين فيما يتعلق بإنتاج المحتوى الفني: ليس صديقًا للفنانين. واجهة Git الافتراضية هي سطر الأوامر. هناك الكثير من الأوامر والخيارات التي يجب تعلمها، بالإضافة إلى مفاهيم أساسية تختلف بدرجة كافية عن أنظمة التحكم في الإصدارات الأخرى لدرجة أنها تدعو إلى الارتباك. الوثائق متوفرة بكثرة لكنها غالبًا ما تكون صعبة الفهم. كل هذا يتضافر ليُنتِج حزمة ليست سهلة الاستخدام نوعًا ما ومخيفة إلى حد ما. لم يُبنَ لإدارة أنواع ملفات البيانات الثنائية (binary) الكبيرة التي ينشئها الفنانون. حقيقة أن كل مستودع محلي يحتوي على كامل السجل والمراجعات تعني أن كمية كبيرة من الأعمال الفنية سريعة التغيير يمكن أن تستهلك مساحة قرص كبيرة بسرعة. توصلنا إلى حلول لكلتا هاتين المشكلتين. الواجهة matters توجد عدة واجهات رسومية جيدة لـ Git. لا يزال الفنانون بحاجة إلى فهم مفاهيم Git الأساسية، لكن الواجهة الأمامية المصممة جيدًا تجعل التعلم والاستخدام أسهل بكثير. وجدنا أن SourceTree من شركة Atlassian يعمل بشكل رائع في بيئتنا القائمة على أجهزة Mac: فهو قوي وبديهي ومجاني (حاليًا) – وهو اعتبار مهم لشركة ناشئة طموحة. كما استجاب فريق SourceTree بسرعة (< 12 ساعة) لاستفسارات الدعم التي أرسلناها عبر تويتر. امتداد Git أنيق يعالج Git-media أوجه القصور في Git فيما يتعلق بملفات البيانات الثنائية الكبيرة. إنه امتداد لـ Git يسمح لك بتخزين الملفات خارج Git. لا يزال Git يتتبع إصدارات الملفات؛他只是 يخزن محتويات الملف في مكان ما خارج المستودع. كنا نخطط لتخزين ملفاتنا الثنائية الكبيرة في سحابة Amazon S3. ليس بهذه السرعة استخدام SourceTree مع Git-media يطرح مع ذلك مشكلة غير متوقعة: نقل الملفات بين مستودعاتنا وAmazon S3 يتطلب منا تنفيذ أمر صدفة؛ أي: $ git media sync سير عمل يلزم الفنانين بمغادرة الراحة النسبية لتطبيق رسومي لكتابة أوامر الصدفة ليس صديقًا للفنانين. يوفر SourceTree طريقة لتنفيذ هذا الأمر كإجراء مخصص، لكن ذلك لم يكن كافيًا. سيضطر الفنانون لا يزالون إلى تذكر القيام بذلك في الأوقات المناسبة. عاجلاً أم آجلاً سينسون وسيفني شخص ما وقتًا ثمينًا في محاولة معرفة ما حدث خطأ وإصلاحه. كيف يمكننا جعل SourceTree وgit-media يعملان معًا بتناغم؟ Git Wrap كتبنا نصًا مغلفًا (wrapper script) عامًا ينفذ اختياريًا بعض الأوامر الأخرى قبل و/أو بعد أمر git نفسه. قمنا بإعداده لاستدعاء ‘git media sync’ تلقائيًا قبل أو بعد الأوامر التي تتفاعل مع مستودع بعيد، حسب الاقتضاء. قمنا بتكوين SourceTree لاستدعاء النص المغلف بدلاً من Git الجاهز. الكود المصدري للنص المغلف متاح هنا على Github . المغامرة مستمرة أود أن أقول لكم أن هذه كانت نهاية القصة، وأن SourceTree وgit-media عملا معًا بسلاسة وعشنا جميعًا في سعادة وهناء thereafter. لقد عملا في الواقع، حتى نقطة معينة. للأسف، لم يكن ذلك كافيًا. يقوم SourceTree عادةً بعمل جيد في معاينة ملفات الصور. هذا أمر بالغ الأهمية للفنانين عند Commit أو دمج التغييرات على مثل هذه الملفات. لكن استخدام git-media عطّل قدرة SourceTree على معاينة هذه الملفات لأن ذلك يعني أننا لم نعد نخزن الصور في Git؛ كنا نخزن فقط معلومات الإصدار حول الصور. لم نستطع إيجاد طريقة مقبولة للتغلب على ذلك؛ كانت هذه نقطة فاصلة. حتى وقت كتابة هذه السطور، نحاول مرة أخرى باستخدام ميزة submodule في Git. تخزين أصولنا الفنية في submodule هو طريقة أخرى لتقليل حجم مستودع المشروع الرئيسي. يفهم SourceTree ويدعم submodules بشكل جيد إلى حد ما، وتظل قدرته على معاينة الصور سليمة. لدى Submodules بعض الخصائص الفردية، لكن لا يبدو أن أيًا منها معطل بشكل كبير لسير عمل الفنانين لدينا. ترقبوا هذا المكان للحصول على التحديثات؛ سنخبركم كيف ستنتهي الأمور. تعليقات المدونة مدعومة من Disqus