تنفيذ commit — ما هو، قواعد التنسيق والعمل مع Git

ما هو commit في Git

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

عندما يقوم المطور بتنفيذ commit للتغييرات، ينشئ Git كائن commit يخزن: كائن tree (هيكل الملفات)، تجزئة commit الأب، المؤلف، committer، التاريخ والرسالة. هذا الكائن غير قابل للتغيير — بمجرد إنشائه، لا يمكن تعديل commit دون تغيير تجزئته. يضمن عدم القابلية للتغيير سلامة تاريخ المشروع.

# تجهيز التغييرات وتنفيذ commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# عرض تفاصيل commit
git log --oneline -3
git show HEAD

# تجهيز جميع التغييرات وتنفيذ commit في خطوة واحدة
git commit -a -m "Update dependencies to latest versions"

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

كيفية تنفيذ commit للتغييرات بشكل صحيح

تتكون عملية commit في Git من مرحلتين: إضافة التغييرات إلى منطقة staging (الفهرس) وإنشاء commit. تسمح منطقة staging للمطور باختيار التغييرات المحددة التي ستُدرج في commit، حتى لو تم تعديل العديد من الملفات في دليل العمل.

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

قبل تنفيذ commit، يجدر التحقق: ما إذا كان هناك مخرجات تصحيح أخطاء أو كتل معلقة أو تغييرات عرضية في الكود. لهذا يُستخدم الأمر git diff --cached الذي يظهر ما سيدخل بالضبط في commit. تحقق إضافي عبر git status يعرض قائمة الملفات في منطقة staging.

• تحقق من التغييرات — git diff --cached يظهر ما سيدخل في commit
• تحقق من الجودة — يجب أن يجتاز الكود المدقق والاختبارات قبل commit
• اكتب رسالة — وصف واضح للغرض من التغيير
• تحقق من الملفات المضافة — git status يؤكد قائمة الملفات

قواعد كتابة رسائل commit

رسالة commit هي توثيق التغيير للمطورين المستقبليين. الرسالة الجيدة تجيب على الأسئلة: ما الذي تغير ولماذا. أصبحت اتفاقية Conventional Commits (فريق Angular، 2016) معيارًا للعديد من المشاريع وتحدد التنسيق: النوع(النطاق): الوصف.

تتكون رسالة commit الجيدة من عنوان (حتى 50 حرفًا) ونص (اختياري، حتى 72 حرفًا في السطر). يُكتب العنوان بصيغة الأمر: «Add» وليس «Added» أو «Adds». Capitalization والنقطة في نهاية العنوان لا تُستخدم — هذه اتفاقية Git دولية.

الرسالة السيئة: «fix things» أو «update» — لا تحمل معلومات. بعد شهر، لن يتمكن المطور من فهم ما تم تغييره بالضبط ولماذا. الرسالة الجيدة: «fix(payment): handle timeout in stripe callback» — يتضح فورًا ما وأين تم إصلاحه.

الأخطاء الشائعة عند تنفيذ commit

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

ثاني أكثر الأخطاء شيوعًا هو رسالة commit رديئة. الرسائل مثل «fix» أو «update» أو «changes» أو «wip» لا توفر سياقًا للمطورين المستقبليين. بعد ستة أشهر، لن يتذكر أحد ما تم إصلاحه بالضبط. القاعدة بسيطة: تخيل أنك بعد عام تنظر في التاريخ وتحاول العثور على تغيير معين.

الخطأ الثالث هو تنفيذ commit لرمز غير مُجمّع أو غير عامل. بعد commit، يجب أن يترجم الرمز على الأقل. عدم كسر البناء هو متطلب أساسي لأي commit في فرع مشترك. لهذا، يتم تشغيل البناء والاختبارات قبل commit.

الخطأ الرابع هو تنفيذ commit لبيانات سرية. مفاتيح API وكلمات المرور والرموز يجب ألا تصل إلى تاريخ Git. إذا تم commit سر بالفعل، فلا يكفي حذفه في commit جديد، بل يجب حذفه من التاريخ بأكمله عبر git filter-branch أو BFG Repo-Cleaner.

التقنيات المتقدمة للعمل مع commits

يوفر Git أدوات لإدارة تاريخ commits. من أكثرها فائدة git commit --amend، الذي يسمح بتكميل آخر commit بتغييرات جديدة أو تصحيح الرسالة. هذا مفيد إذا نسي المطور تضمين ملف أو أخطأ في الرسالة.

# تصحيح رسالة آخر commit
git commit --amend -m "fix(auth): correct token validation logic"

# إضافة ملف تم نسيانه إلى آخر commit
git add missed-file.txt
git commit --amend --no-edit

# Rebase تفاعلي لآخر 3 commits
git rebase -i HEAD~3

Interactive rebase هي أداة قوية لإعادة كتابة التاريخ. تسمح بدمج commits (squash) وتغيير الرسائل (reword) وإعادة الترتيب (reorder) وحذف commits (drop). ومع ذلك، يغير rebase التاريخ، لذلك يُستخدم فقط مع commits المحلية التي لم تُدفع بعد إلى المستودع البعيد.

هناك طريقتان لتراجع commits. git revert ينشئ commit جديدًا يلغي تغييرات السابق — طريقة آمنة تحفظ التاريخ. git reset يحذف commits من التاريخ — خطير إذا كانت commits قد دُفعت بالفعل. في التطوير الجماعي، يُستخدم git revert فقط لتراجع commits المنشورة.