# مطور يحاول تخزين الـ issues داخل Git ويشرح لماذا فشلت الفكرة البديهية

> **المغزى:** مكان تخزين المهام قرار يُتخذ مرة واحدة في بداية أي أداة أو فريق، وكل خيار يربح شيئًا ويخسر آخر: العمل دون اتصال مقابل بساطة التعديل.

- المصدر: المغزى (https://almaghza.com/a/2026-09-17-git-native-issue-tracking/)
- التاريخ: 6 ربيع الآخر - 17 سبتمبر 2026 (2026-09-17)
- القسم: فرق ومنتجات
- الوسوم: Git، إدارة المشاريع، أدوات المطورين

نشر مطور يوم 15 سبتمبر 2026 سجلًا تقنيًا بعنوان Reinventing issue tracking: Local-first and Git-native، يشرح فيه محاولته تخزين الـ issues الخاصة بمشروعه داخل Git نفسه. وتصدّر المقال موقع Lobsters.

الفكرة البديهية كانت مجلدًا باسم .issues/ داخل المشروع، يحتوي كل ملف فيه على issue واحدة. وتبدو الفكرة ممتازة في البداية، فحالة الـ issue تتحرك مع الكود، ويمكن إغلاقها في الـ commit نفسه الذي يصلح المشكلة.

لكنها تتعثر أمام سؤال بسيط: issue جديدة فُتحت على الفرع main، إلى أي فرع من الفروع الجارية تنتمي؟ والسبب الأعمق، بحسب الكاتب، أن الـ issues تتغير بوتيرة أعلى بكثير من الكود. فكل فتح أو تعديل أو إغلاق يعني pull ثم rebase للبقاء متزامنًا، أي أن جدول عمل الفريق يصبح مرتبطًا بتاريخ الفروع.

## الحل عبر الـ refs

انتقل الكاتب إلى تخزين الـ issues في refs بأسماء غير تقليدية، مثل refs/issues/12. ينقل Git هذه الـ refs مع المستودع، وتمررها منصات مثل GitHub دون أن تفهم محتواها، ولا تظهر في شجرة الملفات.

والثمن أن تعديل issue واحدة أصبح أربع خطوات: إنشاء blob ثم tree ثم commit ثم تحديث الـ ref، بأربعة معرّفات مختلفة، لما هو في النهاية ملف نصي صغير. ويسمي الكاتب ما يكسبه في المقابل Atomicity، أي أن التعديل يتم كاملًا أو لا يتم.

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

## المصادر

- [المقال الأصلي](https://blog.manganin.dev/blog/reinventing-issue-tracking/)
- [توثيق Git عن الـ refs](https://git-scm.com/book/en/v2/Git-Internals-Git-References)
- [توثيق أمر git update-ref](https://git-scm.com/docs/git-update-ref)