شيفرتي كانت بلا ذاكرة: كيف أنقذني GitLens من جحيم تتبع أصل كل سطر برمجي؟

يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.

خلوني أرجع بالذاكرة ليلة من ليالي الشتاء الباردة، قبل كم سنة. كنت قاعد في مكتبي، فنجان الشاي بالنعنع جنبي، والساعة تجاوزت منتصف الليل. وصلني إيميل عاجل من مدير المشروع: “أبو عمر، في مشكلة حرجة (critical bug) على النظام الأساسي، والمستخدمون لا يستطيعون إتمام عمليات الدفع!”. قلبي وقتها “نقز” نقزة قوية، زي ما بنحكي. مشاكل الدفع هي الكابوس الأكبر لأي مطور.

فتحت المشروع، وبدأت رحلة البحث عن سبب المشكلة. بعد ساعة من التنقيب والـ “debugging”، حصرت المشكلة في سطر واحد غريب، سطر منطقي (logical condition) ما كان إله أي معنى في السياق الحالي. أول سؤال خطر في بالي: “مين كتب هذا السطر؟ وليش؟!”.

وقتها، كانت طريقتي في تتبع التاريخ بدائية شوي. أفتح الطرفية (Terminal)، أكتب git blame a/long/path/to/the/file.js، وأقعد أدور بعيوني على السطر المطلوب. لما ألاقيه، آخذ “هاش” الـ commit، وأرجع أكتب git show <commit_hash> عشان أقرأ رسالة الـ commit وأشوف التغييرات كاملة. كانت عملية مرهقة، بتقطع حبل أفكاري، وبتخليني أكره Git وكل اللي اخترعوه في هذيك اللحظة.

في هذيك الليلة، وبعد ما ضيعت وقت ثمين في التنقل بين المحرر والطرفية، تذكرت إضافة (extension) كنت قد ثبتها على VS Code قبل فترة ونسيتها، اسمها GitLens. قلت لحالي “خليني أجربها، مش خسران إشي”. وبكل بساطة، ضغطت على السطر المشؤوم… وفجأة، ظهرت بجانبه معلومة صغيرة ومضيئة: “You, 8 months ago: Fix for bug #342 – Prevent double payment submission”.

أنا! أنا اللي كتبت هذا السطر قبل 8 شهور! ورسالة الـ commit ذكرتني بالمشكلة القديمة اللي كنت بحاول أحلها. في لحظة واحدة، فهمت السياق كاملًا. السطر هذا كان ضروريًا لمنع مشكلة قديمة، لكنه تسبب في مشكلة جديدة مع التحديثات الأخيرة. امتلاك هذا السياق التاريخي بشكل فوري أنقذني من ساعات إضافية من الحيرة، وخلاني ألاقي حل للمشكلة الجديدة بدون ما أرجع أكسر إشي قديم. هذيك الليلة، ما أنقذني فنجان الشاي، بل أنقذتني GitLens. ومن يومها، صارت جزء لا يتجزأ من арсенаلي البرمجي.

ما هو GitLens؟ ولماذا هو “عدسة” Git الخارقة؟

ببساطة، GitLens هو إضافة مجانية لبرنامج VS Code. وظيفته الأساسية هي “إحياء” تاريخ شيفرتك البرمجية وعرضه لك مباشرة داخل المحرر. بدلًا من أن يكون Git مجرد نظام للتحكم في الإصدارات يعمل في الخلفية وتتعامل معه عبر أوامر في الطرفية، يحوله GitLens إلى طبقة معلوماتية غنية تتفاعل معها وأنت تكتب الكود.

الاسم “GitLens” (عدسة Git) عبقري جدًا، لأنه فعلًا يعطيك عدسة مكبرة ترى بها ماضي كل سطر، كل دالة، وكل ملف. من كتبه؟ متى؟ لماذا؟ وما هي القصة وراء هذا التغيير؟ كل هذه الأسئلة تجد إجاباتها بلمح البصر.

أهم الميزات التي غيرت طريقة عملي (والتي ستغير طريقتك أيضًا)

هذه الأداة مليئة بالميزات، لكن خلوني أركز على الجواهر الحقيقية اللي بستخدمها بشكل يومي.

ميزة “Blame” الفورية: من كتب هذا السطر ومتى ولماذا؟

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

نصيحة أبو عمر: يمكنك تخصيص شكل هذه المعلومة. أنا شخصيًا بحب أغير الإعدادات عشان تظهر لي فقط اسم الشخص والوقت النسبي (e.g., “Abu Omar, 8 months ago”). هذا يبقي الواجهة نظيفة ومركزة. اذهب إلى إعدادات GitLens وابحث عن “current line blame format”.

عدسة التاريخ (Code Lens): رؤية تاريخ الملف والمقطع البرمجي

فوق كل دالة (function) أو صنف (class) في ملفك، ستلاحظ ظهور نص صغير يخبرك بتاريخ آخر تعديل على هذا المقطع وعدد المبرمجين الذين ساهموا فيه. مثلاً: “Last changed by Abu Omar 2 weeks ago • 3 authors”.

هذه الميزة رائعة لسببين:

• تعطيك فكرة سريعة عن “نشاط” الكود: هل هذا الكود قديم جدًا ولم يلمسه أحد منذ سنوات (قد يكون مستقرًا أو مهملًا)؟ أم أنه يتغير باستمرار (قد يكون منطقة نشطة أو بحاجة لإعادة هيكلة)؟
• نقطة بداية للاستكشاف: بالضغط على هذا النص، تفتح لك قائمة سريعة تظهر لك تاريخ التعديلات على هذا المقطع تحديدًا، مما يسهل فهم تطوره.

مقارنة الفروع والـ Commits بلمح البصر

هل سبق لك أن أردت أن ترى الفرق بين فرعك الحالي وفرع main الرئيسي قبل أن تقوم بإنشاء Pull Request؟ مع GitLens، هذه العملية تتم بضغطة زر.

في الشريط الجانبي الخاص بـ GitLens، يوجد قسم “Compare”. يمكنك اختيار أي فرعين، أو أي commit-ين، أو حتى فرع مع حالتك الحالية غير المحفوظة، وستعرض لك الأداة قائمة بجميع الملفات التي تغيرت، مع عرض تفصيلي للتغييرات جنبًا إلى جنب (side-by-side diff).

نصيحة أبو عمر: قبل كل Pull Request، أقوم دائمًا بمقارنة فرعي مع الفرع الهدف (e.g., develop or main). هذا يساعدني على مراجعة تغييراتي مرة أخيرة، والتأكد من أنني لم أضف ملفات غير ضرورية أو تغييرات ناتجة عن خطأ. إنها خطوة مراجعة ذاتية فعالة جدًا.

البحث في تاريخ المشروع (Commits Search)

تخيل أنك تريد أن تجد كل الـ commits التي قمت بها والتي تحتوي على كلمة “refactor” في رسالتها. أو تريد أن تبحث عن أي تغيير تم على ملف معين. أو حتى تريد أن تبحث عن commit أضفت فيه سطر كود معين!

قسم البحث في GitLens هو محرك جوجل الخاص بتاريخ مشروعك. يمكنك البحث حسب:

• رسالة الـ commit.
• اسم المبرمج.
• اسم الملف.
• حتى التغييرات في الكود نفسه (e.g., -console.log للعثور على كل الـ commits التي حذفت console.log).

// مثال على بحث في GitLens
// في خانة البحث، يمكنك كتابة شيء مثل:
//
// author: "Abu Omar" message: "fix" file: "payment.js"
//
// هذا سيعرض لك كل الـ commits التي قمت بها، والتي تحتوي على كلمة "fix" في رسالتها،
// والتي أثرت على ملف payment.js. قوة لا تصدق!

الخريطة الحرارية (Heatmap): أين تتركز التعديلات في ملفاتك؟

هذه ميزة بصرية ممتعة ومفيدة جدًا. تقوم الخريطة الحرارية بتلوين شريط التمرير الجانبي (أو أرقام الأسطر) ليعكس “عمر” الكود. الأسطر التي تم تعديلها مؤخرًا تكون “ساخنة” (حمراء أو برتقالية)، بينما الأسطر القديمة تكون “باردة” (زرقاء).

هذا يساعدك على تحديد “النقاط الساخنة” (Hotspots) في الكود، وهي المناطق التي تتغير بشكل متكرر. هذه المناطق غالبًا ما تكون مرشحة جيدة لإعادة الهيكلة (Refactoring) أو تحتاج إلى المزيد من الاختبارات لأنها مصدر دائم للتغييرات والمشاكل المحتملة.

نصائح أبو عمر الذهبية لتحقيق أقصى استفادة من GitLens

1. خصص الأداة لتناسبك: لا تكتفِ بالإعدادات الافتراضية. اقضِ نصف ساعة في استكشاف إعدادات GitLens. غير الألوان، وشكل معلومات الـ blame، واضبط الاختصارات. اجعل الأداة تعمل من أجلك، وليس العكس.
2. استكشف الواجهة الجانبية: الكثير من قوة GitLens تكمن في الواجهة التي تظهر في الشريط الجانبي لـ VS Code. هناك ستجد قوائم بكل الـ Commits, Branches, Stashes, Remotes، وأكثر. تعلم كيفية التنقل فيها بفعالية.
3. استخدمها كأداة تعلم: عندما تنضم إلى مشروع جديد، فإن GitLens هو أفضل صديق لك. تجول في الكود، وانظر من هم المبرمجون الرئيسيون في كل جزء، واقرأ رسائل الـ commits القديمة لفهم القرارات المعمارية التي تم اتخاذها. إنها مثل آلة زمن تأخذك في جولة تاريخية داخل المشروع.
4. ادمجها في مراجعة الكود (Code Review): عندما تراجع كود زميلك، استخدم GitLens. انظر إلى تاريخ الملفات التي يعدلها. هل هذا التعديل منطقي في سياق التغييرات السابقة؟ ميزة “Blame” تساعدك على طرح أسئلة أذكى وأكثر عمقًا.

الخلاصة: شيفرتك ليست يتيمة، بل لها تاريخ وقصة 📜

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

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

نصيحتي الأخيرة لكم: إذا كنتم تستخدمون VS Code و Git ولم تثبتوا GitLens بعد، فأنتم تفوتون على أنفسكم الكثير. ثبتوها اليوم، أعطوها أسبوعًا واحدًا فقط لتعتادوا عليها، وأنا أضمن لكم أنكم لن تستطيعوا تخيل حياتكم البرمجية بدونها. بالتوفيق في رحلتكم! 💪