ما هو Git؟ مقدمة للمبتدئين في التحكم في الإصدارات
نادراً ما يبقى البرنامج كما هو دون تغيير. يضيف المطور ميزة جديدة، ويصلح خطأً، ويحدّث إحدى الحزم، ويحذف شيفرة قديمة، ويجرّب فكرة مختلفة. وكل تعديل ينشئ حالة جديدة من المشروع، ومن دون سجل موثوق يصبح من الصعب معرفة ما الذي تغير، ولماذا تغير، وكيف يمكن العودة إلى حالة مستقرة عندما تحدث مشكلة.
يحل Git هذه المشكلة عبر تسجيل إصدارات ذات معنى من المشروع، وتوفير أدوات تتيح للمطورين مقارنة التغييرات وتنظيمها ودمجها واستعادتها. تبدأ هذه المقالة من الأساسيات، فتشرح المشكلة التي يعالجها Git، وكيف يعمل نظام التحكم الموزع في الإصدارات، والمفاهيم الجوهرية مثل المستودعات وعمليات الحفظ، والفرق المهم بين Git ومنصات مثل GitHub.
ما هو التحكم في الإصدارات؟
التحكم في الإصدارات هو نظام يسجل التغييرات التي تطرأ على الملفات بمرور الوقت. وبدلاً من الاحتفاظ بالنسخة الحالية فقط من المشروع، يحتفظ بسجل منظم للتغييرات التي تم اختيارها وتسجيلها.
يساعد هذا السجل المطور أو الفريق في الإجابة عن أسئلة عملية، مثل:
ما الذي تغير بين نسخة الأمس ونسخة اليوم؟
من عدّل جزءاً معيناً من المشروع؟
لماذا أُضيف سطر من الشيفرة أو حُذف؟
أي تغيير تسبب في ظهور الخطأ؟
هل يمكن استعادة نسخة مستقرة سابقة؟
هل يستطيع مطوران العمل على ميزتين مختلفتين دون أن يكتب أحدهما فوق تعديلات الآخر؟
يُستخدم التحكم في الإصدارات غالباً مع الشيفرة المصدرية، لكنه مناسب أيضاً للوثائق وملفات الإعداد وتعريفات البنية التحتية والسكربتات والمشاريع الأكاديمية وغيرها من المحتويات النصية.
الفكرة الأساسية بسيطة: بدلاً من التعامل مع المشروع على أنه مجلد يُنسخ ويُعاد تسميته في كل مرة، يُعامل كنظام يتطور باستمرار وله سجل يمكن فحصه ومراجعته.
المشكلة قبل استخدام التحكم في الإصدارات
تخيل أنك تطور تطبيقاً صغيراً. في البداية تحتفظ بمجلد واحد للمشروع، وقبل إجراء تعديل قد يكون خطراً تنشئ نسخة منه:
my-app
my-app-backup
my-app-final
my-app-final-2
my-app-final-working
my-app-final-really-workingقد تبدو هذه الطريقة آمنة، لكنها سرعان ما تسبب مشكلات عديدة:
لا تعرف بدقة ما الذي تغير بين المجلدات.
يصعب تحديد الشخص الذي أجرى كل تعديل.
قد يعدّل عدة مطورين نسخاً مختلفة من الملف نفسه.
يصبح دمج التغييرات يدوياً ومعرضاً للأخطاء.
تستهلك المجلدات القديمة مساحة من دون أن تقدم سجلاً واضحاً.
تفقد أسماء مثل
finalوlatestمعناها مع مرور الوقت.
يجيب مجلد النسخة الاحتياطية عن سؤال واحد فقط: «كيف كانت الملفات عند إنشاء هذه النسخة؟». أما نظام التحكم في الإصدارات فيسجل تسلسل التغييرات، وسبب كل نسخة مسجلة، ومن أنشأها، والعلاقة بين مسارات التطوير المختلفة.
ما هو Git؟
Git هو نظام مجاني ومفتوح المصدر وموزع للتحكم في الإصدارات. يتتبع التغييرات داخل المشروع، ويساعد المطورين على العمل بشكل فردي أو جماعي من دون فقدان تاريخ العمل.
أُنشئ Git عام 2005 أثناء تطوير نواة Linux، وصُمم لتحقيق أهداف مثل السرعة، ودعم العمل الموزع، وتسهيل التطوير المتوازي، والتعامل بكفاءة مع المشاريع الكبيرة.
يُستخدم Git اليوم في مشاريع من جميع الأحجام، بدءاً من أول تطبيق لطالب، وصولاً إلى الأنظمة الضخمة التي تديرها فرق موزعة في عدة دول.
Git ليس لغة برمجة، ولا إطار عمل، ولا خدمة سحابية، ولا موقعاً لاستضافة الشيفرة. إنه أداة للتحكم في الإصدارات تعمل على جهازك، ويمكنك استخدامها محلياً من دون اتصال بالإنترنت ومن دون إنشاء حساب في أي منصة استضافة.
لماذا يوصف Git بأنه موزع؟
يوصف Git بأنه نظام موزع للتحكم في الإصدارات لأن كل مطور يستطيع امتلاك مستودع محلي كامل يتضمن ملفات المشروع وتاريخه.
يختلف ذلك عن النموذج المركزي التقليدي الذي يوجد فيه المستودع الأساسي على خادم واحد، ويعتمد المطورون عليه بدرجة كبيرة لفحص التاريخ أو تسجيل التغييرات.
في Git، تُنفذ عمليات مهمة كثيرة محلياً، ومنها:
إنشاء عملية حفظ
commit.عرض عمليات الحفظ السابقة.
مقارنة الإصدارات.
إنشاء الفروع أو الانتقال بينها.
دمج الفروع.
استعادة حالة سابقة.
ولأن هذه العمليات تعتمد على المستودع المحلي، فهي غالباً سريعة ويمكن تنفيذها من دون اتصال بالشبكة.
يبقى الخادم البعيد مفيداً للتعاون والنسخ الاحتياطي والمراجعة والأتمتة، لكنه لا يحل محل مستودع Git المحلي؛ بل يمثل نسخة أخرى يمكن للمطورين تبادل التغييرات معها.
التحكم المركزي في الإصدارات مقابل التحكم الموزع
يساعد فهم الفرق بين النظامين المركزي والموزع في توضيح طريقة عمل Git.
التحكم المركزي في الإصدارات
في النظام المركزي، يخزن خادم مركزي المستودع الأساسي. يحصل المطورون على الملفات من هذا الخادم ثم يعيدون إرسال تعديلاتهم إليه.
يوفر هذا النموذج مصدراً مركزياً واضحاً للحقيقة وإدارة موحدة، لكنه يجعل المطورين أكثر اعتماداً على الخادم للوصول إلى التاريخ والتعاون.
التحكم الموزع في الإصدارات
في نظام موزع مثل Git، تحتوي كل نسخة مستنسخة عادةً على تاريخ المستودع. يستطيع المطور العمل محلياً، وإنشاء عمليات حفظ وفروع، ثم مزامنة عمله لاحقاً مع مستودع بعيد واحد أو أكثر.
| الجانب | النموذج المركزي | نموذج Git الموزع |
|---|---|---|
| تاريخ المستودع | يُخزن أساساً على خادم مركزي | يتوفر في كل نسخة محلية كاملة |
| عمليات الحفظ المحلية | تعتمد غالباً على سير العمل المركزي | تُنشأ مباشرة داخل المستودع المحلي |
| العمل دون اتصال | إمكاناته محدودة أكثر | تبقى عمليات كثيرة متاحة |
| الفروع | تعتمد على النظام المستخدم | مصممة لتكون خفيفة وعملية |
| التعاون | يتمحور عادةً حول خادم واحد | يمكن أن يعتمد على مستودع بعيد واحد أو أكثر |
لا تعني كلمة «موزع» أن على كل فريق العمل من دون منصة مركزية. تستخدم معظم الفرق مستودعاً بعيداً مشتركاً، لكن الفرق هو أن Git لا يجعل ذلك الخادم المكان الوحيد الذي يمكن تنفيذ عمليات المستودع المهمة فيه.
كيف ينظر Git إلى المشروع؟
يمكن تصور Git على أنه خط زمني من اللقطات المهمة لحالة المشروع.
عند إنشاء commit، يسجل Git حالة ملفات المشروع المختارة في تلك اللحظة، إلى جانب بيانات مثل:
اسم المؤلف.
التاريخ والوقت.
رسالة تصف التغيير.
مرجع إلى عملية الحفظ السابقة أو العمليات السابقة.
تشكل عمليات الحفظ المترابطة تاريخ المشروع.
Commit A → Commit B → Commit C → Commit Dتمثل كل عملية حفظ نقطة معروفة في تطور المشروع، ويستطيع Git مقارنة هذه النقاط وإظهار ما أُضيف أو حُذف أو عُدّل.
لهذا لا يقتصر التاريخ على الاستعادة فقط، بل يصبح نوعاً من التوثيق التقني. فالسجل المنظم يوضح كيف بُنيت ميزة، ولماذا اتُخذ قرار معين، ومتى ظهرت مشكلة للمرة الأولى.
يعتمد Git على اللقطات، وليس على فروق الملفات فقط
يتخيل كثير من المبتدئين أن التحكم في الإصدارات مجرد مجموعة تعليمات مثل «أضف هذا السطر» أو «احذف ذلك السطر». يستطيع Git عرض الفروق بهذه الطريقة، لكن نموذجه الداخلي مبني على لقطات لحالة المشروع.
عند إنشاء عملية حفظ، يسجل Git مراجع إلى محتوى المشروع كما كان في تلك اللحظة. ويمكنه إعادة استخدام الملفات التي لم تتغير بكفاءة بدلاً من تخزين نسخ كاملة غير ضرورية منها.
هذا النموذج مهم لأن Git يتعامل مع كل commit بوصفه حالة كاملة وذات معنى للمشروع، وليس مجرد قائمة منفصلة من التعديلات.
ما هو مستودع Git؟
مستودع Git هو مشروع يتتبعه Git. ويحتوي على ملفات العمل، إضافة إلى مجلد داخلي خاص اسمه .git.
يخزن مجلد .git بيانات Git الداخلية، ومنها:
تاريخ عمليات الحفظ.
الفروع والمراجع.
إعدادات المستودع.
بيانات منطقة التجهيز.
الكائنات التي تمثل الملفات والمجلدات وعمليات الحفظ.
من دون مجلد .git يكون المجلد عادياً، أما بوجوده فيصبح مستودع Git.
توجد طريقتان شائعتان للحصول على مستودع:
تهيئة Git داخل مشروع محلي موجود.
استنساخ مستودع موجود من مكان آخر.
ستُشرح الأوامر بالتفصيل في المقالات العملية التالية، لكن الفرق من حيث المفهوم هو:
التهيئة Initialize: بدء تتبع مشروع موجود بالفعل على جهازك.
الاستنساخ Clone: إنشاء نسخة محلية من مستودع Git موجود مع تاريخه.
المناطق الثلاث الأساسية في سير عمل Git
يصبح Git أسهل كثيراً عندما تفهم أن التغييرات تنتقل بين ثلاث مناطق رئيسية:
مجلد العمل.
منطقة التجهيز.
تاريخ المستودع.
1. مجلد العمل
يحتوي مجلد العمل على الملفات التي تراها وتعدلها. وعندما تغيّر ملفاً، يوجد التعديل في مجلد العمل لكنه لا يصبح جزءاً من عملية حفظ بعد.
2. منطقة التجهيز
منطقة التجهيز هي طبقة تحضير تتيح لك تحديد التغييرات التي ستدخل في عملية الحفظ التالية بدقة.
تفيد هذه المنطقة عندما تعدّل عدة ملفات، لكنك تريد إنشاء عمليات حفظ مركزة. فمثلاً يمكنك تجهيز ملفات إصلاح الخطأ أولاً، وترك تعديل تنسيق غير مرتبط لعملية حفظ منفصلة.
3. تاريخ المستودع
عند حفظ التغييرات المجهزة، تصبح جزءاً من تاريخ المستودع. وتحصل عملية الحفظ على معرّف، وتتحول إلى نسخة مسجلة يستطيع Git فحصها لاحقاً.
يبدو الانتقال الأساسي كالتالي:
Working Directory
↓
git add
↓
Staging Area
↓
git commit
↓
Repository Historyيمنح هذا الفصل المطور تحكماً في ما يدخل إلى التاريخ. لا يسجل Git تلقائياً كل تعديل يتم حفظه داخل الملف على أنه commit.
الحالات: Modified وStaged وCommitted
تصف وثائق Git محتوى الملفات المتتبعة عادةً بثلاث حالات أساسية:
Modified: تغير الملف في مجلد العمل، لكن نسخته الجديدة لم تُضف إلى منطقة التجهيز.
Staged: تم اختيار النسخة المعدلة لتدخل في عملية الحفظ التالية.
Committed: تم تسجيل النسخة بأمان في تاريخ Git المحلي.
لنأخذ مثالاً بسيطاً:
تعدل ملف
login.php، فيصبح في حالة Modified.تضيف التغيير إلى منطقة التجهيز، فيصبح Staged.
تنشئ عملية حفظ، فيصبح Committed.
إذا عدلت الملف مرة أخرى لاحقاً، يصبح التعديل الجديد في حالة Modified، بينما تظل النسخة المحفوظة سابقاً موجودة في التاريخ.
ما هي عملية الحفظ Commit؟
الـ commit هو لقطة مسجلة لحالة المشروع، ويعد من أهم مفاهيم Git.
تتضمن عملية الحفظ عادةً:
مرجعاً إلى محتوى المشروع.
بيانات المؤلف ومن نفذ عملية الحفظ.
طابعاً زمنياً.
رسالة تصف التغيير.
ارتباطاً بعملية حفظ سابقة واحدة أو أكثر.
ينبغي أن تشرح رسالة الحفظ الهدف من التغيير، لا أن تكرر اسم الملف الذي تم تعديله فقط.
رسالة ضعيفة:
update filesرسالة أفضل:
Validate email addresses before creating user accountsتساعد الرسالة الأفضل المطورين مستقبلاً على فهم سبب وجود عملية الحفظ.
يفضل أن تمثل كل عملية حفظ وحدة منطقية واحدة من العمل. فالـ commit المركّز أسهل في المراجعة والاختبار والفهم والتراجع من عملية حفظ كبيرة تجمع تغييرات غير مترابطة.
ما هو معرّف Commit Hash؟
تحصل كل عملية حفظ على معرّف فريد، ويُعرض غالباً على شكل سلسلة مختصرة من الأحرف والأرقام.
a4c29f1يسمح هذا المعرّف لـ Git بالإشارة إلى نقطة محددة في التاريخ. ويمكن استخدامه لفحص عملية حفظ، أو مقارنتها بإصدار آخر، أو إنشاء فرع منها، أو استعادة محتوى مرتبط بها.
يستخدم المطورون غالباً النسخة المختصرة من المعرّف في أوامرهم اليومية، بينما يحتفظ Git داخلياً بالمعرّف الكامل للكائن.
ما هو الفرع Branch؟
الفرع هو مسار تطوير مستقل. يتيح لك العمل على ميزة أو إصلاح خطأ أو تجربة من دون تعديل المسار الرئيسي للمشروع مباشرة.
لنفترض أن المشروع يحتوي حالياً على ثلاث عمليات حفظ:
A → B → Cثم تنشئ فرعاً وتضيف عمليتي حفظ للميزة:
A → B → C
D → Eيمكن أن يظل الفرع الرئيسي مستقراً، بينما يتطور فرع الميزة بشكل منفصل. وعندما تصبح الميزة جاهزة، يمكن دمج عملها مع الفرع المستهدف باستخدام merge أو استراتيجية دمج أخرى.
تعد الفروع أساساً مهماً للتعاون، لأنها تسمح بتقدم تغييرات متعددة بالتوازي:
يعمل مطور على نظام تسجيل الدخول.
يصلح مطور آخر خطأً في الدفع.
يحدّث مطور ثالث الوثائق.
يبقى فرع الإنتاج محمياً ومستقراً.
لا تمنع الفروع كل تعارض تلقائياً، لكنها تنظم العمل بحيث تتم مراجعة التغييرات ودمجها بشكل مقصود ومنضبط.
ما هو HEAD؟
HEAD هو المرجع الذي يستخدمه Git للإشارة إلى الفرع أو عملية الحفظ التي تعمل عليها حالياً.
في سير العمل المعتاد، يشير HEAD إلى الفرع الحالي، ويشير ذلك الفرع إلى أحدث عملية حفظ في مسار تطويره.
HEAD → feature/login → Commit Eعند الانتقال إلى فرع آخر، ينتقل HEAD إلى الفرع المحدد. ويصبح فهم هذا المفهوم مهماً عند تبديل الفروع، واستعادة الإصدارات، واستخدام rebase، أو التعامل مع حالة detached HEAD.
ما هو الدمج Merge؟
الدمج هو عملية جمع تواريخ تطوير مختلفة. ويُستخدم غالباً لنقل عمل مكتمل من فرع ميزة إلى فرع آخر.
مثال:
main: A → B → C
feature/login: D → Eبعد الدمج، يتضمن المسار الرئيسي عمل الميزة. وبحسب شكل التاريخ، قد يحرك Git مؤشر الفرع إلى الأمام أو ينشئ عملية حفظ مخصصة للدمج.
قد يحدث تعارض دمج عندما لا يستطيع Git تحديد الطريقة الآمنة لجمع تغييرات متنافسة. ويحدث ذلك غالباً عندما تعدّل فروع مختلفة الجزء نفسه من الملف بطرق غير متوافقة.
التعارض لا يعني أن Git فشل، بل يعني أنه يطلب من المطور اتخاذ قرار لا يمكن حسمه تلقائياً بطريقة آمنة.
ما هو المستودع البعيد Remote Repository؟
المستودع البعيد هو مستودع Git آخر يستطيع مستودعك المحلي التواصل معه، وغالباً ما يكون مستضافاً على خادم أو منصة تعاون.
يتيح المستودع البعيد:
مشاركة عمليات الحفظ مع الفريق.
جلب التغييرات التي أنشأها مطورون آخرون.
إدارة مستودع مشترك.
الاحتفاظ بنسخة بعيدة من تاريخ المشروع.
تشغيل عمليات المراجعة والأتمتة.
يستخدم Git أوامر شائعة مثل:
git fetchلجلب معلومات وتغييرات المستودع البعيد دون دمجها تلقائياً.git pullلجلب التغييرات البعيدة ودمجها.git pushلإرسال عمليات الحفظ المحلية إلى المستودع البعيد.
هذه الأوامر جزء من Git نفسه. أما المستودع البعيد فقد يكون مستضافاً على GitHub أو GitLab أو Bitbucket أو Azure Repos أو خادم خاص أو أي خدمة متوافقة مع Git.
Git وGitHub ليسا الشيء نفسه
هذا الفرق أساسي:
Git هو نظام التحكم في الإصدارات.
GitHub منصة تستضيف مستودعات Git وتضيف ميزات للتعاون.
يمكنك استخدام Git من دون GitHub. تستطيع مثلاً إنشاء مستودع محلي، وتنفيذ مئة عملية حفظ، وإنشاء فروع ودمجها وفحص التاريخ الكامل، من دون إنشاء حساب على GitHub.
يصبح GitHub مفيداً عندما تحتاج إلى ميزات مثل:
استضافة المستودعات البعيدة.
طلبات السحب Pull Requests.
مراجعة الشيفرة.
تتبع المشكلات.
مناقشات المشروع.
إدارة الصلاحيات.
مسارات العمل المؤتمتة.
صفحات الإصدارات.
| Git | GitHub |
|---|---|
| برنامج للتحكم في الإصدارات | منصة لاستضافة المستودعات والتعاون |
| يعمل محلياً | يُستخدم أساساً كخدمة عبر الإنترنت |
| يتتبع عمليات الحفظ والفروع والدمج | يضيف طلبات السحب والمراجعات والمشكلات والأتمتة |
| لا يحتاج إلى GitHub | يعتمد على مستودعات Git |
| يعمل مع خدمات بعيدة كثيرة | واحد من عدة خيارات لاستضافة Git |
يمكن تشبيه Git بالمحرك الذي يدير التاريخ، بينما GitHub مساحة عمل تعاونية مبنية حول المستودعات التي يديرها ذلك المحرك.
GitHub وGitLab وBitbucket
GitHub ليس المنصة الوحيدة التي تستضيف مستودعات Git.
GitHub: شائع في المشاريع مفتوحة المصدر، ومعارض الأعمال، والمستودعات الخاصة، وطلبات السحب، والتكاملات.
GitLab: يوفر استضافة Git وطلبات الدمج وإدارة المشاريع وإمكانات CI/CD مدمجة.
Bitbucket: يوفر استضافة مستودعات Git، ويشيع لدى الفرق التي تستخدم منظومة Atlassian.
Azure Repos: يوفر مستودعات Git ضمن مسارات عمل Azure DevOps.
الخوادم ذاتية الاستضافة: تستطيع المؤسسات استضافة مستودعات Git على بنية تحتية تديرها بنفسها.
تبقى معرفة Git الأساسية قابلة للنقل بين هذه المنصات. فأوامر مثل commit وbranch وmerge وfetch وpull وpush مفاهيم تابعة لـ Git، حتى لو استخدمت المنصات أسماء مختلفة لميزات التعاون المحيطة بها.
سيناريو عملي بسيط لاستخدام Git
لنفترض أن فريقاً يطور متجراً إلكترونياً، وأن الفرع الرئيسي يحتوي على النسخة المستقرة من التطبيق.
يتلقى أحد المطورين مهمة لإضافة التحقق من قسائم الخصم أثناء الدفع.
يمكن أن يكون سير العمل المعتمد على Git كما يلي:
إنشاء فرع جديد لميزة القسائم.
تعديل شيفرة الدفع.
اختبار منطق التحقق.
إضافة الملفات المرتبطة بالميزة فقط إلى منطقة التجهيز.
إنشاء عملية حفظ مركزة برسالة واضحة.
إرسال الفرع إلى المستودع البعيد المشترك.
فتح Pull Request أو Merge Request.
السماح للاختبارات الآلية والمراجعين بفحص التغيير.
إصلاح المشكلات التي تظهر أثناء المراجعة.
دمج الميزة المعتمدة في الفرع الرئيسي.
يدير Git عمليات الحفظ والفروع وتاريخ الدمج، بينما تدير منصة الاستضافة نقاشات المراجعة والصلاحيات والفحوص الآلية المحيطة بذلك التاريخ.
لماذا يستخدم المطورون Git؟
1. تاريخ موثوق للمشروع
يحفظ Git حالات المشروع المسجلة، ما يتيح فحص الطريقة التي تطور بها المشروع.
2. تجارب أكثر أماناً
يمكن للمطور إنشاء فرع منفصل للتجربة من دون التأثير مباشرة في العمل المستقر.
3. تطوير متوازٍ
يستطيع عدة مطورين العمل على مهام منفصلة ثم دمج تغييراتهم لاحقاً.
4. مراجعة أسهل للشيفرة
يعرض Git بدقة ما تغير بين عمليات الحفظ أو الفروع، فتكون المراجعة أكثر تركيزاً.
5. تحليل أسرع للمشكلات
يمكن للمطورين فحص التاريخ ومقارنة الإصدارات وتحديد اللحظة التي دخل فيها سلوك غير متوقع إلى المشروع.
6. إدارة أفضل للإصدارات
تستطيع الفرق وضع علامات على الإصدارات المهمة، والحفاظ على فروع للإصدارات، وربط الشيفرة المنشورة بعمليات حفظ محددة.
7. التكامل مع الأتمتة
يمكن لأحداث المستودع تشغيل الاختبارات وعمليات البناء وفحوص الجودة والأمان والنشر عبر منصات خارجية.
8. مفيد للمطور الفردي
Git ليس مخصصاً للفرق فقط. يستفيد المطور الفردي من التاريخ وإعادة الهيكلة الآمنة والفروع التجريبية وإمكانية استعادة عمل سابق.
ما الذي لا يستبدله Git؟
Git أداة قوية، لكنه ليس حلاً كاملاً لكل أنواع بيانات المشروع.
Git ليس استراتيجية نسخ احتياطي كاملة
يمكن للمستودع البعيد توفير نسخة إضافية مهمة من الشيفرة المصدرية، لكن لا ينبغي أن يكون Git خطة النسخ الاحتياطي الوحيدة لقواعد البيانات أو ملفات المستخدمين المرفوعة أو إعدادات الخادم أو الأسرار أو البنية التحتية الإنتاجية.
Git ليس نظاماً لإدارة المشاريع
يسجل Git إصدارات المشروع. أما المهام والمواعيد والنقاشات وتخطيط دورات العمل وتتبع المشكلات فتحتاج عادةً إلى أدوات إضافية أو ميزات توفرها منصة الاستضافة.
Git ليس نظام نشر متكاملاً بمفرده
يمكن لـ Git تشغيل أتمتة النشر، لكن النشر إلى بيئة الإنتاج يحتاج أيضاً إلى بنية تحتية وصلاحيات وإعدادات بيئة وخطوات بناء ومراقبة وخطة تراجع.
Git ليس مثالياً لكل تدفقات الملفات الثنائية الكبيرة
يعمل Git بكفاءة خاصة مع الملفات النصية. أما الملفات الثنائية الكبيرة فقد تحتاج إلى إضافات متخصصة أو تخزين منفصل أو سير عمل مصمم لهذا النوع من الملفات.
مفاهيم خاطئة شائعة لدى المبتدئين
«حفظ الملف ينشئ إصداراً في Git»
حفظ الملف يحدّث النسخة الموجودة في مجلد العمل فقط. لا يسجل Git التغيير إلا بعد إضافته إلى منطقة التجهيز وإنشاء commit.
«Git يرفع الشيفرة تلقائياً»
عمليات الحفظ محلية افتراضياً، ولا تصل إلى المستودع البعيد إلا عند تنفيذ push.
«يجب وضع كل التغييرات في Commit واحد»
يمكنك تنظيم التغييرات المترابطة ضمن عمليات حفظ مركزة. تساعدك منطقة التجهيز في اختيار ما يدخل إلى كل عملية حفظ.
«الفرع نسخة كاملة أخرى من مجلد المشروع»
فرع Git مرجع خفيف إلى مسار من عمليات الحفظ، وليس مجرد مجلد نُسخ يدوياً.
«GitHub يملك Git»
Git نظام مستقل ومفتوح المصدر للتحكم في الإصدارات، بينما GitHub منصة توفر خدمات مبنية حول مستودعات Git.
«لا نحتاج إلى التحكم في الإصدارات إلا عندما يكبر المشروع»
أفضل وقت لبدء استخدام التحكم في الإصدارات هو بداية المشروع. حتى التطبيق الصغير يستفيد من وجود تاريخ منظم.
مصطلحات Git الأساسية
| المصطلح | المعنى |
|---|---|
| Repository | المشروع مع تاريخ Git الخاص به |
| Working Directory | الملفات الظاهرة التي يجري تعديلها حالياً |
| Staging Area | مجموعة التغييرات المحضرة لعملية الحفظ التالية |
| Commit | لقطة مسجلة لحالة المشروع |
| Branch | مسار تطوير مستقل |
| Merge | عملية جمع مسارات التطوير |
| Conflict | حالة تتطلب قراراً يدوياً أثناء الدمج |
| HEAD | مرجع إلى الموقع النشط حالياً في المستودع |
| Remote | مستودع Git آخر يُستخدم لتبادل التغييرات |
| Clone | نسخة محلية من مستودع موجود مع تاريخه |
| Push | إرسال عمليات الحفظ المحلية إلى مستودع بعيد |
| Fetch | جلب التغييرات البعيدة من دون دمجها تلقائياً |
| Pull | جلب التغييرات البعيدة ودمجها |
| Tag | مرجع مسمى يُستخدم غالباً لتحديد إصدار |
نظرة أولى على سير عمل Git
الأوامر التالية مجرد معاينة. ستُشرح عملية التثبيت والإعداد ومنطقة التجهيز وعمليات الحفظ بالتفصيل في مقالات لاحقة.
# إنشاء مجلد جديد للمشروع
mkdir git-introduction-demo
cd git-introduction-demo
# تهيئة مستودع Git
git init
# إنشاء ملف
echo "# Git Introduction Demo" > README.md
# فحص حالة المستودع
git status
# تجهيز الملف لعملية الحفظ التالية
git add README.md
# تسجيل النسخة المجهزة
git commit -m "Create project README"
# عرض التاريخ
git log --onelineتنفذ هذه السلسلة من الناحية المفاهيمية خمس خطوات:
تنشئ مجلداً عادياً للمشروع.
تحوله إلى مستودع Git.
تنشئ ملفاً داخل المشروع.
تختار الملف ليدخل في اللقطة التالية.
تسجل اللقطة في التاريخ.
المهارة الأهم ليست حفظ الأوامر من دون سياق، بل فهم ما الذي يغيره كل أمر داخل سير عمل Git.
ما الذي ينبغي تخزينه في Git؟
ينبغي أن يحتوي المستودع على الملفات اللازمة لفهم المشروع وبنائه وصيانته، ما دامت هذه الملفات مناسبة للتحكم في الإصدارات.
من الملفات التي تُحفظ عادةً:
الشيفرة المصدرية للتطبيق.
الاختبارات الآلية.
الوثائق.
ملفات تعريف الاعتماديات.
ملفات ترحيل قواعد البيانات.
قوالب الإعداد.
ملفات البنية التحتية بوصفها شيفرة.
تعريفات البناء وCI/CD.
ومن الملفات التي تُستبعد عادةً:
كلمات المرور وأسرار API.
ملفات البيئة المحلية التي تحتوي على بيانات اعتماد.
الملفات المؤقتة.
ملفات التخزين المؤقت الخاصة بالمحرر.
مجلدات الاعتماديات المولدة عندما لا تتطلب المنظومة حفظها.
نواتج البناء التي يمكن توليدها من جديد.
ملفات السجلات المحلية الكبيرة.
يستخدم Git ملفاً اسمه .gitignore لتحديد أنماط الملفات والمجلدات التي ينبغي عادةً ألا يتتبعها.
الأمان: لا تحفظ الأسرار داخل المستودع
من أهم عادات استخدام Git إبقاء الأسرار خارج تاريخ المستودع.
لا تحفظ العناصر التالية:
كلمات مرور قواعد البيانات.
مفاتيح API الخاصة.
بيانات اعتماد الخدمات السحابية.
مفاتيح SSH الخاصة.
رموز الوصول.
ملفات بيئة الإنتاج.
حذف السر في عملية حفظ لاحقة لا يزيله تلقائياً من التاريخ السابق. إذا تم حفظ سر أو رفعه إلى مستودع بعيد، فتعامل معه على أنه مكشوف: ألغِه أو غيّره أولاً، ثم نظف التاريخ باستخدام عملية مناسبة ومخطط لها بعناية.
أفضل ممارسات Git منذ البداية
ابدأ التحكم في الإصدارات منذ بداية المشروع.
أنشئ عمليات حفظ لوحدات عمل ذات معنى.
اكتب رسائل توضح الهدف من التغيير.
راجع التغييرات المجهزة قبل تنفيذ
commit.استخدم الفروع للميزات والإصلاحات والتجارب.
أبقِ بيانات الاعتماد وأسرار البيئة المحلية خارج المستودع.
استخدم ملف
.gitignoreمناسباً.زامن عملك مع الفريق بانتظام.
لا تجمع تغييرات غير مترابطة في عملية حفظ كبيرة واحدة.
افهم الأمر قبل استخدام خيارات قد تحذف البيانات أو تعيد كتابة التاريخ.
هل تعلم Git صعب؟
قد يبدو Git مربكاً لأن عدة طبقات تظهر معاً: مجلد العمل، ومنطقة التجهيز، وعمليات الحفظ، والفروع، والمستودعات البعيدة، ومنصات الاستضافة.
الحل هو تعلم Git كنظام مترابط، لا كقائمة عشوائية من الأوامر.
يمكن اتباع الترتيب العملي التالي:
فهم المناطق الثلاث: مجلد العمل، ومنطقة التجهيز، والمستودع.
التدرب على
statusوaddوcommitوlog.تعلم الفروع والدمج محلياً.
فهم المستودعات البعيدة وأوامر
fetchوpullوpush.التدرب على التعاون باستخدام Pull Requests أو Merge Requests.
تعلم أوامر التراجع بعد فهم تأثير كل أمر.
الانتقال لاحقاً إلى أساليب العمل و
rebaseوcherry-pickوhooks والأتمتة.
لا تتطلب معظم أعمال التطوير اليومية جميع أوامر Git المتقدمة. فهم مجموعة أساسية صغيرة بعمق أفضل من حفظ عشرات الأوامر من دون معرفة تأثيرها.
متى ينبغي استخدام Git؟
يناسب Git معظم مشاريع تطوير البرمجيات الحديثة، ومنها:
تطبيقات الويب.
تطبيقات الهواتف.
واجهات API وخدمات الخلفية.
مشاريع الواجهة الأمامية.
المكتبات والحزم.
سكربتات الأتمتة.
مستودعات DevOps والبنية التحتية.
الوثائق التقنية.
مشاريع البرمجة الأكاديمية.
مشاريع التعلم الشخصية.
حتى عند العمل منفرداً، يمنحك Git طريقة منظمة للتجربة والاستعادة. وعند العمل ضمن فريق، يصبح أساساً للمراجعة والدمج وإدارة الإصدارات والتسليم المؤتمت.
قائمة التحقق بعد مقدمة Git
قبل الانتقال إلى مقالة التثبيت والإعداد، تأكد من وضوح النقاط التالية:
يسجل التحكم في الإصدارات تغييرات المشروع المهمة بمرور الوقت.
Git نظام موزع للتحكم في الإصدارات.
Git وGitHub مرتبطان، لكنهما أداتان مختلفتان.
يحتوي المستودع على ملفات المشروع وتاريخ Git.
عملية الحفظ هي لقطة مسجلة للمشروع.
تجهز منطقة التجهيز التغييرات لعملية الحفظ التالية.
يمثل الفرع مسار تطوير مستقلاً.
المستودع البعيد هو مستودع Git آخر يُستخدم لمشاركة التغييرات.
تبقى عمليات الحفظ محلية حتى يتم إرسالها باستخدام
push.يجب عدم حفظ الأسرار داخل المستودع.
الأسئلة الشائعة
هل يمكن استخدام Git من دون GitHub؟
نعم. يمكن استخدام Git بالكامل على جهازك أو مع خادم Git خاص، واستخدام GitHub اختياري.
هل يحتاج Git إلى اتصال بالإنترنت؟
لا. يمكن تنفيذ عمليات الحفظ المحلية وإنشاء الفروع والمقارنات وفحص التاريخ من دون اتصال. تحتاج إلى الإنترنت فقط عند التواصل مع مستودع بعيد موجود على الإنترنت.
هل Git مخصص للمطورين المحترفين فقط؟
لا. يمكن للطلاب والباحثين والكتّاب التقنيين ومديري الأنظمة والمطورين المستقلين الاستفادة منه.
هل يحفظ Git كل ملف تلقائياً؟
لا. يسجل Git التغييرات التي تختارها عند إضافتها إلى منطقة التجهيز ثم إنشاء عملية حفظ.
هل يستطيع Git استعادة شيفرة محذوفة؟
يستطيع Git استعادة محتوى تم حفظه سابقاً. لكنه لا يستطيع ضمان استعادة عمل لم يُسجل أبداً ثم حُذف نهائياً من مجلد العمل.
هل مستودع Git نسخة احتياطية؟
يوفر تاريخاً قيماً للمشروع، خصوصاً عند نسخه إلى موقع بعيد، لكنه ينبغي أن يكون جزءاً من استراتيجية نسخ احتياطي أوسع، لا النسخة الاحتياطية الوحيدة.
أي منصة استضافة ينبغي أن أتعلم أولاً؟
تعلم أساسيات Git أولاً. بعد ذلك يُعد GitHub نقطة بداية عملية، لكن المعرفة الأساسية نفسها تعمل مع GitLab وBitbucket وAzure Repos والخوادم الخاصة.
الخلاصة
Git نظام موزع للتحكم في الإصدارات يحول المشروع المتغير إلى تاريخ منظم يمكن فحصه. يتيح للمطورين إنشاء لقطات ذات معنى، وتجربة الأفكار باستخدام الفروع، ومقارنة الإصدارات، والتعاون ضمن الفرق، والتعافي من كثير من الأخطاء الشائعة.
المفاهيم الأهم ليست الأوامر نفسها، بل النموذج الذي تقف خلفه: تُعدّل الملفات في مجلد العمل، ثم تُختار عبر منطقة التجهيز، وبعدها تُسجل كعمليات حفظ داخل المستودع. تنظم الفروع مسارات التطوير المستقلة، بينما تتيح المستودعات البعيدة مشاركة هذه التواريخ.
عندما يتضح هذا النموذج الذهني، يصبح Git أقل غموضاً بكثير. والخطوة التالية هي تثبيت Git، وإعداد هويتك وخياراتك الافتراضية، وتجهيز بيئة نظيفة لإنشاء أول مستودع عملي.
المراجع الرسمية ومصادر إضافية
