مقدمة للتحكم في الإصدار و Git

مألوف مع محرر مستندات Google؟ حسنًا ، إذا كنت كذلك ، فمن الآمن أن نفترض أنك على دراية بعلامة التبويب "محفوظات الإصدار" الصغيرة التي تسمح للكتاب والأشخاص المعنيين بفحص جميع التغييرات التي تم إجراؤها في المستند وتتبعها. في أي وقت. أداة يدوية ، أليس كذلك؟

تخيل الآن بدلاً من ورقة مليئة بالفقرات ، هناك ملفات مليئة بمئات أسطر الرموز. وعلى عكس المستند الفردي ، هناك الكثير من الملفات المختلفة ، يتم تحديثها باستمرار.

في سيناريو مثل هذا ، حيث يوجد آلاف سطر من الأكواد قيد التشغيل والنتيجة النهائية ، أي أن تطبيق الهاتف المحمول هو ما يعتمد عليه مستقبل الشركة ، يصبح من الأكثر أهمية أن يكون لديك برنامج يحتفظ بعلامة تبويب لجميع التغييرات صنع في ملفات التعليمات البرمجية.

هذا هو المكان الذي يظهر فيه برنامج التحكم في الإصدار في الصورة.

لماذا يعد التحكم في الإصدار مهمًا في تطوير البرامج

كما يوحي الاسم ، يتيح برنامج التحكم في الإصدار لمطوري تطبيقات الأجهزة المحمولة تتبع الإصدارات المختلفة لدورة تطوير البرامج وإجراء تغييرات فيها. هذه القدرة على تتبع جميع التغييرات التي تحدث في الكود ثم خيار التراجع عن التغييرات هو ما يجعل التحكم في الإصدار جزءًا مهمًا من عملية شركة تطوير تطبيقات الأجهزة المحمولة والتي تتضمن مطورين متعددين.

الآن عندما يتعلق الأمر بالتحكم في الإصدار ، هناك عدد من البرامج المتاحة في السوق في الوقت الحاضر. دعونا نلقي نظرة على بعضها -

البرامج المتوفرة للتحكم في الإصدار

على الرغم من أنه في استطلاع GitLab الخاص به ، وجد قائد البرامج الموزعة أن 98٪ من المستخدمين يستخدمون أدوات Git مفتوحة المصدر وأكثر من 92٪ من المطورين يستخدمون Git كلغة تحكم في الإصدار في عملية تطوير التطبيق ، هناك عدد الأسباب التي قد تدفع المطورين إلى البحث عن بديل Git. يمكن أن تختلف بعض هذه الأسباب من - هيكل تسعير GitHub وحقيقة أن Github تم إطلاقه على كل من iOS و Android ، أو النفور من Octocat ، أو مستوى الراحة البسيط مع لغة التحكم في الإصدار التي ليست Git.

مهما كان السبب ، فإليك بديل Git للتحكم في الإصدار -

الآن حتى في حالة وجود عدد من البدائل المتاحة للتحكم في الإصدار وفي Appinventiv ، لدينا خبرة مباشرة في العمل على الكثير منها ، نظرًا لاختلاف متطلبات العملاء ، فنحن بالفعل متحيزون تجاه Git. دعني أخبرك لماذا.

لماذا يستخدم Appinventiv Git للتحكم في الإصدار

1. لسرعة البرق

من بين جميع برامج التحكم في الإصدارات الموجودة في السوق ، فإن السرعة التي يعمل بها سجل Git وعناصر الالتزام لا يمكن مقارنتها مع أي برامج أخرى. وعندما يعمل فريق المطورين لديك على نظام أساسي ، يصبح من الضروري للغاية أن يكون البرنامج سريعًا.

2. للقدرة على العمل دون اتصال

عندما تعمل على برنامج يعتمد على الإنترنت ، فقد يكون ذلك محفوفًا بالمخاطر عندما تكون في حالة تنقل وتفقد الاتصال بالمستودع المركزي. لكن هذا ليس هو الحال مع Git. باستخدام Git ، يمكنك تنفيذ جميع المهام تقريبًا على جهازك المحلي - الالتزام أو تصفح محفوظات المشروع أو إنشاء فرع أو الدمج.

3. للتراجع عن الإغاثة

يأتي Git مع أمر "تراجع" يتيح لك تصحيح الالتزام بالكامل وإعادته. في الواقع ، يمنحك حتى خيار استعادة الالتزام "المحذوف" من خلال خيار Reflog.

4. للنسخ الاحتياطي

عندما يعمل الفريق على Git ، فإن كل نسخة يمتلكها الفريق على أجهزتهم تأتي بنسخة احتياطية قابلة للاستخدام. بالإضافة إلى ذلك ، فإن كل إجراء Git تقريبًا يضيف البيانات فقط ولا يحذفها.

5. لعمل إلتزامات مفيدة

عندما يلتزم فريق المطورين لدينا بمجموعة من التغييرات غير ذات الصلة - أخذ بعض الميزات من A ، وإجراء بعض الأخطاء في أخرى - قد يكون من الصعب جدًا على أعضاء الفريق الآخرين فهم ما حدث وقد يكون من الصعب عليهم التراجع الميزات أ إذا كانت تسبب مشاكل.

يحل Git هذه الفوضى عن طريق إنشاء الالتزام الدقيق. من خلال مفهوم "منطقة التدريج" ، يمكن للمرء بسهولة معرفة التغييرات التي سيتم تضمينها في الالتزام التالي ، حتى عندما تكون مهتمًا بالنظر إلى الأسطر الفردية.

لذلك كانت هذه هي الأسباب الخمسة الرئيسية لاستخدام Git هنا في Appinventiv. الآن وقد نظرنا في السبب ، حان الوقت لإلقاء نظرة على كيف. كيف ندمج Git في عملية التحكم في الإصدار.

دعنا نصل إلى ذلك الآن.

عملية التحكم في الإصدار عند استخدام Git

إنشاء المستودع

الهدف من Git هو إدارة مجموعة من الملفات ، المعروفة أيضًا باسم Project. للقيام بذلك ، يحفظ Git جميع المعلومات في بنية البيانات المعروفة باسم المستودع. يتكون المستودع من رموز مصدر التطبيق والموارد ومجموعات البيانات. في الأساس ، يحتوي على كل ما يعرّف مشروع التطبيق.

الآن ، هناك طريقتان للحصول على مستودع على Git. يمكنك إما استخدام دليل محلي وتحويله إلى مستودع Git باستخدام سطر الأوامر أو يمكنك نسخ مستودع Git الذي تم تحميله بالفعل إلى مستودعك.

عند إنشاء مستودع ، عادة ما تحصل على خيارين - عام وخاص. المستودع العام هو المستودع الذي يمكن للمطورين الآخرين مشاهدته باستخدام Git والمستودع الخاص ، من ناحية أخرى ، هو المستودع الذي لا يمكن عرضه إلا من قبل عدد قليل من الأشخاص.

المتفرعة

بجانب إنشاء المستودع متفرّع. في شركة مثل Appinventiv ، حيث يعمل أكثر من 15 إلى 20 مطورًا في مشروع واحد في أي وقت ، فليس من غير المألوف أن يشارك المطورون نفس كود المصدر ويعملون عليه. ما يحدث هو أنه نظرًا لأن بعض المطورين مشغولون في إصلاح المشكلات ، فقد يقوم آخرون بتنفيذ بعض الميزات.

في مثل هذه الحالة ، نحتاج إلى نظام يجعل من السهل التعامل مع إصدارات الكود المختلفة في نفس مصدر الشفرة.

هذا هو المكان الذي يأتي فيه Gitflow في الصورة. Gitflow هو إطار عمل يستخدم للتفرع بشكل منهجي وفعال.

قبل المضي قدمًا في كيفية عمل عملية التفريع على Gitflow ، دعني أوضح المفهوم بمثال.

افترض أن هناك 5 مطورين في فريقك ويعملون على تطوير تطبيق Instagram like. الآن يتم الإشارة إلى ميزات التطبيق الفردية مثل التغذية والإشعارات على أنها الوحدة 1 والوحدة 2 وما إلى ذلك. الآن هذه الوحدات المختلفة هي فروع تطوير ، والتي بعد العمل يتم دمجها مع الفرع الأصلي أو الرئيسي.

في اللحظة التي يضيف فيها المطور فرعًا ، يقوم بإنشاء خط تطوير مستقل ، والذي يعزل عملهم عن عمل أعضاء فريقهم. ثم يتم دمج الفروع المختلفة في الفرع الأصلي.

التفريع هو الطريقة التي تسمح لأعضاء الفريق بتحديد جميع التغييرات التي يجب أن يتوقعوها والتي تجعل التراجع سهلاً.

في مشاريعنا عادة ما نحتفظ بهذه الفروع -

• الفرع الرئيسي
• فرع التطوير
• فرع الميزات
• فرع التحرير
• الإصلاحات العاجلة وإصلاحات الأخطاء

ارتكب

تُعرف التغييرات التي يقوم بها المطور في الملف الفردي بالتزام. تتم إضافة التغييرات أو الالتزام في المستودع المحلي وليس في الخادم. بعد ذلك ، يتبع مطورونا عادة كتابة رسالة الالتزام ، حيث يتم نشر وصف الالتزام (التغييرات التي تم إجراؤها في الملف) ، بحيث يعرف المطورون الآخرون أيضًا تفاصيل التغييرات التي تم إجراؤها في الملف.

يدفع

عند الالتزام في مستودع Git المحلي ، فإن ما يحدث بعد ذلك هو إرسال التغييرات بعد ذلك إلى الخادم ، وهو ما يُعرف باسم Push .

من السهل إلى حد ما دفع محفوظات الالتزام إلى الخادم عندما تكون أنت الوحيد الذي يعمل على ملف ، ولكن في حالة وجود مطورين آخرين يشاركون في العملية أيضًا ، فسيتعين عليك سحب التغييرات قبل أن تتمكن من دفع مجموعتك من الالتزام بـ Git.

بعد ذلك ، سننظر في ما تم إنجازه في خطوة Pull Change.

طلب سحب

عندما يعمل أكثر من مطور واحد على نفس الملف ، فإن ما يحدث هو أن بعض الالتزام قد يتم دفعه على الخادم من قبل المطور الآخر قبل دفعه. وعندما يحدث ذلك ، يحدث الصراع (المزيد حول ذلك لاحقًا).

لتجنب تحميل نفس التعليمات البرمجية مرتين على الخادم ، يقوم المطورون أولاً بسحب التغييرات من المستودع والتأكد من اختلاف الرموز. الآن ، بشكل عام ، عندما يعمل مطوران أو أكثر على نفس الملف ويدفعون الالتزام على الخادم ، يأتي خيار "الدمج".

دعنا نتحدث عن الدمج بعد ذلك.

دمج

الدمج هو الخطوة التي يقوم فيها المطورون بتجميع جميع الفروع أولاً مع بعضها البعض ثم مع الفرع الرئيسي أو الفرع الرئيسي.

في كل مرة يدخل تسليم أمر دفع ، يحصلون على خيار دمج ، والذي يسألهم بعد ذلك عن الفرع الذي يرغبون في دمج الالتزام به.

الآن في مرحلة الدمج ، حدوث التعارض شائع جدًا. يحدث التعارض عادةً عندما يتم تغيير الفرعين اللذين تخطط لدمجهما في نفس الجزء في نفس الملف. ما يحدث هنا هو أن Git غير قادر على معرفة الإصدار الذي يجب استخدامه.

عندما تأتي مشكلة التعارض هذه ، تقدم Git حلين - تلقائي ويدوي.

كما يذهب الاسم ، أحدهما هو المكان الذي يكتشف فيه Git المشكلة بنفسه وفي الأخير ، يتعين على المطورين القيام بذلك يدويًا. في Appinventiv ، نركز على الحل اليدوي للنزاع حيث يقضي حتى على الفرص الدقيقة لحدوث الأخطاء.

بينما نستخدم Git للتحكم في الإصدار من عملية تطوير التطبيق لدينا ، فإن ما يحدث في نفس الوقت هو تتبع المشكلات.

نظرًا لأننا من أكبر المتابعين لـ Agile والثقة Agile لعملية تطوير تطبيقات الأجهزة المحمولة الخاصة بنا ، فإننا نتفهم أهمية التعامل مع عمليات التطوير المتعددة في نفس الوقت. وبفضل ميزة تتبع المشكلات ، يصبح من الأسهل كثيرًا على المختبرين أن يراقبوا في الوقت الحقيقي الكود المكتوب والمدفوع على خادم Git.

نحن نستخدم لوحة ZenHub لمراقبة سير العمل في كل مستودع. تسمح لنا اللوحة بتتبع أولوية التغيير المقترح وأيضًا مساعدة المطورين على تحديث تعليقاتهم على السبورة في الوقت الفعلي.