Git Workflow for Pros: دليل Git الجيد

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

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

هذه ليست مقدمة لاستخدام Git. هناك أدلة ووثائق رائعة لهذا هناك بالفعل. ستستفيد من دليل سير عمل Git هذا إذا كان لديك بالفعل خبرة ضمن فريق تطوير التطبيق وواجهت عقبات في سير العمل ، وانفجارات تكاملية ، وأذواق git-tastrophes - قد تلقي هذه الأنماط بعض الضوء على كيفية تجنب هذه المواقف في المستقبل.

تعاون

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

فرع الاندماج

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

يعد نمط سير العمل هذا نقطة انطلاق مفيدة عندما تكون مخاطر تكامل الفروع المتعددة عالية بما يكفي لضمان اختبار المساهمات المجمعة ككل.

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

كن على علم بأن المساهمات في فرع التكامل تحتاج إلى أن يتم دمجها في مرحلة الإصدار التالية قبل أن يتم دمج ميزة رئيسية أخرى في فرع التكامل - وإلا فإنك تخلط الميزات في مراحل مختلفة من الإكمال. سيؤدي ذلك إلى إعاقة قدرتك على إطلاق ما هو جاهز.

فروع الموضوع

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

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

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

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

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

شوكة

تزدهر المشاريع مفتوحة المصدر باستخدام هذه الميزة التي تم إنشاؤها بواسطة Github. تعمل الشوكة على تمكين مسؤولي صيانة المستودع من خلال بوابة مطبقة للدفع مباشرة إلى فرع مستودع الأصل ، ولكن الأهم من ذلك أنها تسهل التعاون. واهو!

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

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

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

تأكد من أنك تستخدم أداة تسهل طلبات التقسيم والسحب للاستفادة من هذا النمط. لا تقتصر هذه الأدوات على Github: الخيارات الشائعة الأخرى هي Bitbucket و GitlLab. ولكن هناك عدد غير قليل من خدمات استضافة سير عمل Git الأخرى التي ستحتوي على هذه الميزات (أو ما شابه ذلك). اختر الخدمة الأفضل بالنسبة لك.

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

استنساخ

تتمثل الإستراتيجية الشائعة للاستعانة بمصادر خارجية في الحصول على "مقاعد" مساهمة في مشروع يمكن ملؤه بواسطة مطوري برامج متعددين. الأمر متروك لشركة الاستعانة بمصادر خارجية لإدارة خط أنابيب الموارد الخاص بهم لتقديم ساعات متعاقد عليها ، والمشكلات التي يواجهونها هي كيفية الانضمام إلى مجموعة مطوريهم وتدريبهم وصيانتهم لمشاريع كل عميل.

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

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

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

إدارة الإفراج

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

فروع البيئة

قد يتم دعم عملية تطوير البرامج الخاصة بك من خلال عدة بيئات للمساعدة في ضمان الجودة قبل نشرها في الإنتاج. تحاكي فروع البيئة مراحل هذه العملية: تتوافق كل مرحلة مع فرع ، وتتدفق المساهمات عبرها في خط أنابيب.

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

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

لا تستخدم هذا النمط دون التفكير في الفوائد طويلة المدى للأنماط الأخرى أولاً.

الافراج عن الفروع

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

يتم إعطاء مجموعة من الالتزامات "الجاهزة للإنتاج" إصلاحات طفيفة على فرع التحرير. استخدم فرع التكامل لدمج الميزات واختبارها قبل نقل شجرة الالتزام إلى فرع التحرير. قصر مسؤولية فرع التحرير على كونه فحصًا نهائيًا قبل النشر إلى تطبيق الإنتاج.

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

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

استخدم اصطلاح تسمية رقم الإصدار لاسم فرع الإصدار لتوضيح إصدار المستودع الذي تم نشره في الإنتاج.

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

السماح لفرع تحرير واحد فقط بالتواجد في وقت معين يضمن أنك ستتجنب العبء المتمثل في الاحتفاظ بفروع تحرير متعددة متزامنة مع بعضها البعض.

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

الإصدارات ذات الطابع الزمني

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

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

يجب أن تتضمن علامة الطابع الزمني طابعًا زمنيًا فعليًا وتسمية للإشارة إلى أنها تمثل عملية نشر ، على سبيل المثال: deployed-201402121345 .

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

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

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

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

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

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

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

فرع الإصدار

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

سيكون للمستودع الذي يستخدم فروع الإصدار فرع واحد لكل إصدار ثانوي من التطبيق. يتم شرح الإصدارات الرئيسية والثانوية والتصحيحية في وثائق الإصدار الدلالي. تتبع فروع الإصدارات عادةً اصطلاح تسمية لتضمين كلمة "ثابت" وإسقاط رقم التصحيح من إصدار التطبيق: على سبيل المثال 2-3-stable لجعل الغرض والموثوقية واضحين للمستخدمين النهائيين.

يمكن تطبيق علامات Git وصولاً إلى رقم إصدار التصحيح للتطبيق ، لكن فروع الإصدار ليست دقيقة. سيشير فرع الإصدار دائمًا إلى الالتزام الأكثر ثباتًا لإصدار ثانوي مدعوم.

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

لا تستخدم فروع الإصدار إلا إذا كنت تدعم أكثر من إصدار واحد من المستودع الخاص بك.

ملخص

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

يمكن أن يساعد النمط الموجود في هذا الدليل في تسليحك ببعض التبصر في تكييف نظام التحكم في الإصدار الموزع لديك للعمل من أجلك. إذا كنت ترغب في القراءة عن مهام سير عمل Git ، فتأكد من مراجعة Gitflow و Github Flow والأهم من ذلك وثائق git-scm المذهلة!