كيفية تسهيل سير عمل تطوير فريقك باستخدام Git Hooks

أحد المتطلبات الرئيسية للعمل لفريق أو مشروع مفتوح المصدر هو استخدام نظام التحكم في الإصدار (VCS). Git هو نظام تحكم في الإصدار موزع مجاني ومفتوح المصدر لتتبع تغييرات التعليمات البرمجية المصدر أثناء تطوير البرامج. تم إنشاؤه بواسطة Linus Torvalds في عام 2005 لتطوير نواة Linux. إنه سهل التعلم وله بصمة صغيرة مع أداء سريع للغاية.

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

ما هي جيت هوكس؟

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

كيف تحصل عليها؟

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

باستخدام الجهاز الطرفي المفضل لديك ، قم بإنشاء مستودع git جديد.

 mkdir my-new-repository && cd my-new-repository git init ls -la

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

 ls .git/hooks

بعض العينات التي يمكنك العثور عليها هي:

• pre-commit.sample : تم استدعاؤه قبل إجراء الالتزام.
• commit-msg.sample : قم بتحرير ملف الرسالة في مكانه.
• post-receive.sample : تم استدعاؤه بعد تحديث المستودع البعيد.

تحت الغطاء

الآن بعد أن عرفنا أين يمكننا إيجاد الخطافات ، دعنا نعود خطوة إلى الوراء لفهم كيفية عملها بالفعل.

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

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

عندما نلتزم بأي تغييرات في قاعدة الشفرة الخاصة بنا ، يتم تشغيل بعض هذه الخطافات ذات الصلة بالترتيب التالي:

1. pre-commit : فحص اللقطة التي على وشك الالتزام والتحقق مما يجب الالتزام به.
2. prepare-commit-msg : يتيح لك تحرير الرسالة الافتراضية قبل أن يراها مؤلف الالتزام.
3. commit-msg : تعيين رسالة الالتزام إلى قالب.
4. post-commit : يقوم بتنفيذ إجراء بعد اكتمال الالتزام مباشرةً ، ويرسل إشعارًا على سبيل المثال.

في المستودع أعلاه ، لنحاول الآن إضافة بعض البرامج النصية المخصصة قبل وبعد التنفيذ من أجل تصور كيفية عمل git hooks بالفعل.

 nano .git/hooks/pre-commit

أضف المقتطف التالي:

 #!/bin/sh echo Changes are about to be committed

تأكد من أن البرامج النصية الخاصة بنا قابلة للتنفيذ:

 chmod +x .git/hooks/pre-commit

كرر العملية المذكورة أعلاه للنص post-commit :

 nano .git/hooks/post-commit

 #!/bin/sh echo Changes have been committed

 chmod +x .git/hooks/post-commit

يمكننا الآن إضافة ملف nano index.html جديد مع مقتطف HTML صغير لأغراض العرض فقط (لا داعي لإعلام مدققي HTML بهذا الأمر).

 <h1>Hello world from our new repository!</h1>

سنضيف التغييرات في قاعدة الشفرة الخاصة بنا من خلال التدريج ثم ننفذ هذا:

 git add . git commit

بعد معالجة الالتزام بنجاح ، يمكننا أن نرى الناتج التالي للنصين المضافين أعلاه:

 Changes are about to be committed Changes have been committed

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

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

في المثال أعلاه ، اخترنا كتابة هذين النصين في bash ولكن الحقيقة هي أن git تدعم الخطافات التي يمكن كتابتها بأي لغة برمجة نصية نريدها. تعتبر Ruby أو Python أو JavaScript بدائل رائعة ، طالما قمنا بتعيين shebang الصحيح في السطر الأول من البرنامج النصي القابل للتنفيذ.

على سبيل المثال ، يمكننا إعادة كتابة الخطاف pre-commit كبرنامج نصي Node.js كما يلي:

 #!/usr/bin/env node console.log("Changes are about to be commited")

خطافات محلية وبعيدة

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

خطافات محلية

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• applypatch-msg
• pre-applypatch
• post-applypatch
• pre-rebase
• post-rewrite
• post-checkout
• post-merge
• pre-push

خطاف بعيد

• pre-receive
• update
• post-receive

خطاف تقاسم

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

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

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

 find .git/hooks -type l -exec rm {} \\; find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \\;

بدلاً من ذلك ، إذا كنت تستخدم أحدث إصدار من git (يتحدث عن 2.9 وما فوق) ، فيمكننا تكوين مسار git hooks مباشرةً إلى مجلدنا المخصص:

 git config core.hooksPath .githooks

Git Hooks أصبحت سهلة (حالة استخدام JavaScript Codebase)

هناك أدوات تساعدنا على زيادة دمج git hooks مع احتياجات قاعدة الكود الخاصة بنا. على وجه التحديد بالنسبة إلى قواعد أكواد JavaScript ، هناك Husky الذي يمكننا من خلاله تخصيص الإجراءات بسهولة على أحداث git من خلال التكوين.

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

يمكن تحقيق ذلك من خلال توسيع ضبط package.json ببساطة على النحو التالي:

 { "scripts": { "test": "echo Running tests" }, "devDependencies": { "eslint": "5.16.0", }, "husky": { "hooks": { "pre-commit": "eslint . && npm test", } } }

خاتمة

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

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