GitHub لشركة ليست شركة برمجيات

المنظمة على GitHub التي تنتهي إليها الشركة يصنعها عادةً من كان يبني وقتها، ولهذا تكون ملكًا لشخص لا لشركة. وهذه الحقيقة وحدها تقرر في برمجيات الشركة أكثر من أي خيار تقني داخل المستودع: هل يمكن إضافة مطوّر جديد يوم الاثنين، وهل يبقى السجل بعد رحيل من بناه، وهل تستطيع الشركة ترك مورّد دون أن تطلب إذنه. والمستودع يستحق أن يُدار سجلًا تجاريًا — المكان المؤرخ الذي يجتمع فيه الطلب والقرار وسببه — لا مجلدًا يرفع إليه أحد ملفات.

ما وظيفة المستودع حين لا تكتبون الشيفرة؟

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

وملف مضغوط من الشيفرة الحالية يقول للمطوّر التالي ما هو النظام. والسجل يقول له لماذا يقفز ترقيم الفواتير نطاقًا، ولماذا يُحسب تقرير واحد ليلًا، وأي الجدولين المتشابهين مستعمل فعلًا.

لماذا يهم مالك الحساب أكثر من الشيفرة؟

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

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

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

كيف تصير البلاغات وطلبات الدمج سجلًا؟

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

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

ماذا يضمنه المستودع الخاص للعميل؟

الخاص يعني غير المنشور، لا أنه ليس لكم، والالتباس يعمل في الاتجاهين: عميل يظن أن الخاص يعني أنه لا يصل إليه، ومورّد يظن أن الخاص يعني أنه له.

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

ما الذي يجعل المستودع مقروءًا لمن يأتي بعدكم؟

ثلاث عادات صغيرة، ولا واحدة منها تقنية.

ملف README يقول ما النظام، وكيف يعمل محليًا، وأي متغيرات بيئة يحتاج ومن أين تأتي قيمها، وكيف يُنشر، وبمن يُسأل. يُكتب لمن لم يرَ المشروع قط، ويُختبر بأن يتبعه ذلك الشخص.

ورسالة إيداع تقول السبب. fix: duplicate invoice numbers when two tills save at once سجل. أما update فلامبالاة، ومئة منها تجعل السجل بلا قيمة.

ومكان للقرارات ذات الأثر. ملف docs/decisions.md واحد، فيه بند لكل قرار بتاريخه والبديل الذي رُفض، يكلّف ساعة ويمنع الجدال الذي يبدأ بـ«تكلّمنا في هذا».

كيف يبدو الإعداد السليم؟

العنصر	ما يحمله	ما يعوّضه
حساب المنظمة	المالكون والفوترة والعضوية	دخول مطوّر شخصي
البلاغات	ما طُلب، ومن طلبه، ومتى	محادثة
طلبات الدمج	ما تغيّر ومن راجعه	«تمّ»
README ورسائل الإيداع	كيف يُشغَّل، ولماذا تغيّر	مكالمة تسليم لم يسجلها أحد

كيف تُعدّونه في مساء واحد؟

1. أنشئوا المنظمة ببريد على نطاق الشركة، لا بصندوق المؤسس الشخصي.
2. سجّلوا مالكين اثنين، مع تحقق بخطوتين لكل منهما، وضعوا الفوترة على بطاقة الشركة.
3. انقلوا كل مستودع إلى المنظمة، وأعطوا من يبني حق الكتابة لا الملكية.
4. اكتبوا README قبل وجود المطوّر الثاني، ثم اطلبوا من شخص لم يشغّل المشروع أن يتبعه.
5. حدّدوا أين تعيش الطلبات وأين تعيش القرارات، واذكروا ذلك في README.
6. اكتبوا قاعدة رسالة الإيداع مرة، وراجعوها شهريًا؛ فهي تضعف بهدوء.
7. عند التسليم، أضيفوا الفريق الجديد، واحذفوا القديم، وبدّلوا كل سرّ يذكره الإعداد.

أين يخطئ الفريق؟

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

ما لا يغطيه هذا الرأي

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

نعمل داخل منظمات العملاء، ونبني في حسابات يملكونها، ولا نتقاضى عمولة من أي مورّد منصة.

نبني المستودع ليكون أصلًا للشركة، باسمها، مع README يستطيع المطوّر التالي أن يتبعه.