ياسر طبيله
كيف تستخدم نظام التحكم بالإصدارات Git بفاعلية؟ كان برنامجك يعمل بالأمس، لكن لا يعمل اليوم؟ مُسح كود برنامجك؟ ظهرَ خطأ برمجيٌّ فجأة؛ ولا تعلم متى وكيف ولماذا؟ هل تعرّضت إلى أيّ مما سبق؟ نعم؟ لا؟ هذا المقال لك في كلا الحالتين؛ فالوقاية خيرٌ من العلاج !!
ربما تكون لديك معرفةٌ بالأوامر الأساسية في نظام التحكّم بالإصدارات؛ Git، مثل: git add وgit commit وgit push؛ لكن هناك أوامر وطرائق أُخرى مهمة أيضًا. وبمجرد تعرُّفك إياها يُصبح استخدامك لـ Git أكثر فاعلية على المدى الطويل.
في هذا المقال سنشرحُ بعضًا من هذه الأوامر والتقنيات التي ستمكِّنك من استخدام Git بأفضل شكل مُمكن.
سيرُ العملِ في Git
حين وجودِ مجموعةٍ من المطورين يعملون في مشروع واحد، يصبح من الضروري استخدام سير عمل مُناسب لـلجميع في Git. وسنغطّي آتيًا سيرَ عملٍ واحد وهو فعال جدًّا في المشاريع الكبيرة التي تتضمن عدّة مطورين.
عُيّنتَ مديرًا تقنيًا لمشروعٍ ما، وقد طُلِب منك التخطيط لبناءِ موقع إلكتروني على غرار موقع Facebook. يتكون فريقك من ثلاثة مطورين:
- أليس؛ لديها خبرة سنة واحدة في البرمجة.
- بوب؛ لديه خبرة سنة واحدة في البرمجة.
- جون؛ لديه خبرة ممتازة لثلات سنوات في البرمجة.
- أنت مُديرًا تقنيًّا للمشروع.
عملية التطوير في Git
(الفرع الرئيس –Master branch)
1- يجب أن يحتوي دائما على نسخة من البرنامج الذي تتم كتابته أو تطويره.
2- من غير المسموح لأيّ أحد – حتى قائد الفريق- إضافة أو تعديل أيّ كود برمجي في الفرع الرئيس؛ لأنه يحوي النسخة النهائية من الكود فقط.
3- يتم كتابة الكود البرمجي وتعديله في أفرعٍ أُخرى.
(فرع التحرير –Release branch)
1- أولُ شيء يجب القيام به في بداية أيّ مشروع برمجي هو إنشاء فرعِ تحريرٍ للمشروع. يتم إنشاء فرع التحرير من الفرع الرئيس.
2- تُضاف جميع الأكواد البرمجية المتعلقة بهذا المشروع إلى فرع التحرير؛ ففرع التحرير هو مجرد فرع عادي مع البادئة release/.
3- فلنطلق على فرع التحرير لهذا المشروع اسم: release/fb.
4- من المحتمل أن يكون هنالك العديد من المشاريع التي تستخدم نفس الكود البرمجي الأساسي. لذلك يُفضل إنشاء فرع تحرير مُنفصل لكل مشروع؛ فلنفرض، على سبيل المثال، وجودمشروعٍ آخر يعمل على التوازي مع هذا المشروع، عندها يُمكن إطلاق فرع تحرير مُنفصل خاص به وتسميته: release/messenger.
5- يجب أن يكون هناك فرع تحرير منفصل لكل مشروع؛ كي لا يحدث أيّ تعارض بين هذه المشاريع؛ بسبب إمكانية وجود أكثر من مشروع يستخدم نفس الكود البرمجي الأساسي.
(فرع الخاصية –Feature branch)
1- يتم إنشاء فرع خاصية منفصل لكلّ سِمَة مبنية في التطبيق؛ لأنّ هذا يَضمَنُ إمكانيةَ بناء السّمات بشكل مستقل.
2- فرع الخاصية مثل أيّ فرع آخر ولكن مع البادئة feature/.
3- الآن أنت، بصفتك القائد التقنيّ، طلبتَ من أليس إنشاءَ شاشةِ تسجيل دخول إلى الموقع. ولإنجاز ذلك يتوجّب عليها إنشاء فرع خاصية جديد وتسميته: feature/login. ستقوم أليس بكتابة برنامج الجزء الخاصّ بهذه السمة في هذا الفرع فقط.
4- يتم إنشاء فرع الخاصية بشكل عام من فرع التحرير.
5- يُكلَّفُ بوب ببناء صفحة “طلب صداقة”. ولإنجاز هذه المهمة سيقوم بوب بإنشاء فرع خاصية جديد اسمه: feature/friendrequest.
6- أمّا مهمة جون فهي بناء صفحة الأخبار. لذلك؛ أنشأ جون فرع خاصية آخر باسم: feature/newsfeed.
7- تمت كتابة كل جزء من أجزاء الكود البرمجي في فرع مُخصص له من قبل أعضاء الفريق. حتى الآن، كل شيء على ما يرام.
8- لنفترض الآن أن أليس أنهت مهمتها، وكان الكود الخاص بتسجيل الدخول جاهزًا. تحتاج الآن إلى إرساله من فرع الخاصية feature/login إلى فرع التحرير release/fb، يتم ذلك من خلال ما يُسمى (طلب السحب -Pull request).
(طلب السحب –Pull request)
بداية وقبل الخوض في غمارِ أيّ تفصيل؛ يجب ألّا تخلطَ بين طلب السحب وبين الأمر git pull؛ إذ إن أحدهما مُختلفٌ عن الآخر.
لا يستطيع المطور رفع الكود مباشرة إلى فرع التحرير؛ إذْ يحتاج المدير التقني إلى مراجعته أولاً؛ ويتم ذلك من خلال طلب السحب.
تستطيع أليس عملَ طلب سحب على موقع Github من خلال الخطوات الآتية والخاصة بموقع Github فقطْ.
إلى جوار اسم الفرع يوجد خيار يسمى (طلب سحب جديد-New pull request). بالنقر على هذا الخيار تُفتَح شاشة جديدة مبينة أدناه:
ترى في الصورة أعلاه:
- في خانة (فرع المقارنة -compare branch)؛ يجب وضعُ فرعِ الخاصية الذي قامت أليس بكتابته سابقًا؛ أي feature/login.
- في خانة (الفرع الأساسي -base branch)؛ يجب وضع فرع التحرير؛ أي release/fb.
بمجرد الانتهاء من ذلك، تحتاج أليس إلى إدخال عنوان لطلب السحب توصيفٍ له ثم النقر على (إنشاء طلب سحب – Create Pull Request).
تحتاج أليس أيضًا إلى اختيار شخص لمُراجعة طلب السحب الذي قامت به. وبما أنك المدير التقني، ستقوم بالمراجعة النهائية والكشف عن أيّ أخطاء.
عندها يقوم المدير التقني بمراجعة طلب السحب ودمج الكود في فرع الخاصية مع الكود في فرع التحرير.
أخيرًا قمت بدمجِ الكود الموجود في فرع الخاصية (feature/login) مع فرع التحرير (release/fb) وها هي أليس سعيدة لإتمامها عملها وخلوه من أيّ أخطاء.
(التعارُضات البرمجية –Code Conflicts)
1- انتهى بوب أيضًا من كتابة الكود المُكلَّف به، ثم أنشأ طلب سحب من فرع الخاصية (feature/friendrequest) إلى فرع التحرير (release/fb).
2- ، تبدأ بعض التعارُضات البرمجية بالظهور؛ نظرًا لأن فرع التحرير يحتوي بالفعل على الكود الخاص بتسجيل الدخول. يقعُ على عاتق )المراجع- references) حلُّ هذه التعارُضات البرمجية ودمج أجزاء الكود بعضها مع بعض.
في هذه الحالة، وبما أنك المدير التقني، أنت المسؤول عن حل هذه التعارُضات البرمجية ودمج أجزاء الكود البرمجي.
3- الآن، أكمل جون الكود الخاص به ويريد إضافته إلى فرع التحرير. وبما أن جون جيد جدًّا في التعامل مع التعارُضات البرمجية، فإنه يقوم بنسخ جميع الأوامر البرمجية، التي أُضيفَت مؤخّرًا إلى فرع التحرير (release/fb)، إلى فرع الخاصية الخاص به feature/newsfeed (إما من خلال الأمر git pull أو الأمر git merge).
بعدها يقوم جون بحلّ أيّ تعارُضات برمجية موجودة. الآن، يحوي فرع الخاصية (feature/newsfeed) كافة الأوامر البرمجية الموجودة في فرع التحرير (release/fb) أيضًا.
4- أخيرًا، يقوم جون بإنشاء طلب سحب؛ ولكن هذه المرة لا توجد أيّ تعارُضات برمجية في طلب السحب؛ نظرًا لأن جون قام بحلها بالفعل.
هنالك طريقتان لحل التعارُضات البرمجية إذن:
- الطريقة الأولى: أن يحلّ الشخصُ المُراجع لطلب السحب هذه التعارضات البرمجية.
- الطريقة الثانية: أن يدمُج المطورُ آخر الأوامر البرمجية التي أُضيفَت إلى فرع التحرير في فرع الخاصية الخاص به وحل أيّ تعارُضات برمجية قد تظهر.
في المشاريع الكبيرة، يُمكن للمطورين المبتدئين استخدام الطريقة الأولى، ومن ثَمّ الانتقال تدريجيًا إلى الطريقة الثانية؛ لأنّها المفضلة للاستخدام.
الفرع الرئيس مجددًا
بمجرد اكتمال المشروع، يُدمَج الكود الموجود في فرع التحرير مع مثيله في الفرع الرئيس. ثم يُرسل الإنتاج. وبالتالي، فإن كلّاً من الكود النهائي المُعتمد للإنتاج والكود في الفرع الرئيس متشابهان ومتزامنان دومًا. هذا يضمن أيضًا توفّر الكود النهائي المُحدث في الفرع الرئيس لأي مشروع مستقبلي بحيث يكون جاهزًا لإعادة الاستخدام.
لمزيد من المعلومات عن طلبات السحب، يُمكنك قراءة هذا المقال: (Creating a pull request).
تهانينا؛ فأنت تعرف الآن كيفية سير العمل في Git. بالرغم من أنه لدى Git بعض المفاهيم المُفيدة الأُخرى مثل: (تعديل الارتباطات- amending commits)، وإعادة التحديد (rebasing) ؛ يبقى سير العمل في Git مهمٌّ جدًّا لنجاح المشاريع الكبيرة.
أمّا بالنسبة للمشروعات الصغيرة، يمكن أن يبدو سير العمل هذا وكأنه عبء ثقيل؛ لذلك يمكن استخدام بدائل أُخرى فيها.
- ترجمة: ياسر طبيله.
- مراجعة: نور عبدو.
