جيت

يحفظ جيت (Git) سجلًا لكل تغيير جرى على البرنامج، ومن غيّره ومتى ولماذا. وكل تغيير محفوظ يسمى «كوميت»، ولأن شيئًا لا يُحذف، يمكن التراجع عن أي كوميت منها. هذه هي الفكرة كلها، وهي أيضًا سبب قدرة عدة أشخاص على العمل على المنتج نفسه في وقت واحد دون أن يمحو أحدهم عمل الآخر.

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

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

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

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