Git — ما هو، مبادئ العمل والأوامر

ما هو Git؟

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

بدأ تاريخ Git في عام 2005 عندما أنشأ لينوس تورفالدس نظام VCS جديد بعد أن سحبت BitKeeper ترخيصها المجاني لمطوري نواة لينكس. كانت الأهداف: السرعة، بساطة البنية، دعم التطوير غير الخطي من خلال التفرع، والتوزيع الكامل. في 3 أشهر كتب تورفالدس نواة Git، وفي غضون عام أصبح المشروع يدير نفسه بنفسه تحت قيادة جونيو هامانو.

وفقًا لاستطلاع Stack Overflow (2024)، يستخدم Git 93.9% من المطورين المحترفين، مما يجعله نظام التحكم بالنسخ المهيمن في الصناعة. أقرب منافس — Subversion (SVN) — يُستخدم فقط في 5.2% من المشاريع، بشكل رئيسي في بيئات الشركات الكبيرة ذات العمليات المركزية.

كيف يعمل Git: المستودع والـ commits

مستودع Git هو دليل يتتبع فيه Git التغييرات في جميع الملفات. داخل الدليل يوجد مجلد مخفي .git يخزن جميع كائنات النظام: الـ commits والأشجار والـ blobs والمراجع. عندما ينشئ المطور commit، لا ينسخ Git الملفات بالكامل — بل ينشئ لقطة ويحفظ مرجعًا إليها.

كل commit يحتوي على: تجزئة SHA-1 فريدة (40 حرفًا)، مرجع إلى الـ commit السابق (parent)، المؤلف، التاريخ، رسالة الـ commit، ومرجع إلى شجرة تصف حالة الملفات في وقت الـ commit. سلسلة الـ commits تشكل رسمًا بيانيًا لا دوريًا موجهًا حيث يشير كل commit إلى واحد أو أكثر من الوالدين.

# تهيئة المستودع
git init my-project
cd my-project

# إنشاء commit
echo "مرحبًا، Git" > README.md
git add README.md
git commit -m "Initial commit"

# عرض التاريخ
git log --oneline --graph --all

يستخدم Git ثلاث مناطق رئيسية: working directory (الملفات على القرص)، staging area (المؤشر حيث تذهب الملفات المعدة)، وrepository (سجل الـ commits). الأمر git add ينقل التغييرات من دليل العمل إلى staging، وgit commit يسجل محتويات staging في المستودع. هذا الفصل يسمح للمطور بتجميع commit ذي معنى من مجموعة من التغييرات دون تأكيد كل تعديل على حدة.

أوامر Git الأساسية

أوامر Git الأساسية تغطي 90% من العمليات اليومية للمطور. الأمر git clone ينشئ نسخة محلية من مستودع بعيد، git pull يجلب التغييرات من الخادم ويدمجها مع الفرع الحالي، وgit push يرسل الـ commits المحلية إلى الخادم. هذه الأوامر الثلاثة تشكل دورة سير العمل الرئيسية مع Git.

لعرض الحالة يُستخدم git status — يُظهر الملفات المعدلة والتي تمت إضافتها إلى staging والتي لم يتم تتبعها. git diff يعرض التغييرات المحددة في الملفات قبل الإضافة إلى staging. فيما يلي جدول بالأوامر الأكثر استخدامًا:

للتراجع عن التغييرات، يوفر Git عدة خيارات. git reset ينقل مؤشر الفرع إلى commit محدد ويمكنه إعادة تعيين staging أو دليل العمل. git revert ينشئ commit جديدًا يعكس تغييرات الـ commit المحدد — هذه طريقة آمنة للتراجع للفروع المشتركة لأن التاريخ لا يُعاد كتابته.

التفرع في Git: main وfeature وrelease

الفروع في Git هي مؤشرات متحركة خفيفة إلى commit محدد. إنشاء فرع جديد لا ينسخ الملفات، بل ينشئ مؤشرًا جديدًا فقط، مما يجعل التفرع فوريًا تقريبًا. الفرع main (المعروف سابقًا باسم master) هو الفرع الرئيسي للمشروع الذي يحتوي على الكود المستقر الجاهز للإصدار.

الممارسة القياسية هي استخدام Git Flow أو GitHub Flow. يستخدم Git Flow الفروع: main (كود الإصدار)، develop (فرع التكامل)، feature/* (الميزات الجديدة)، release/* (تحضير الإصدارات) وhotfix/* (الإصلاحات العاجلة). GitHub Flow أبسط: فقط main وفروع الميزات، ويتم تسليم جميع التغييرات عبر Pull Request.

# إنشاء فرع والتبديل إليه
git branch feature-auth
git checkout feature-auth
# أو بأمر واحد:
git checkout -b feature-auth

# قائمة الفروع
git branch --list
git branch -a  # جميع الفروع بما فيها المحذوفة

# حذف فرع
git branch -d feature-auth

ميزة مهمة لـ التفرع في Git هي cherry-pick: نقل commit فردي من فرع إلى آخر باستخدام الأمر git cherry-pick <hash>. هذا مفيد عندما تحتاج إلى نقل إصلاح خطأ من فرع ميزة إلى إصدار بدون دمج الفرع بأكمله. يدعم Git أيضًا الـ rebase والـ rebase التفاعلي (git rebase -i) لدمج وإعادة ترتيب وتحرير الـ commits.

Merge وRebase

Merge (الدمج) ينشئ commit دمج خاصًا له والدان. هذا الـ commit يسجل حقيقة دمج فرعين ويحافظ على التاريخ الكامل — يمكن رؤية أين ومتى حدث الدمج. يحافظ Merge على التاريخ كما تم إنشاؤه، مما يبسط التدقيق لكنه يجعل رسم الـ commits أكثر تعقيدًا.

Rebase (إعادة التأسيس) بدلاً من إنشاء commit دمج، ينقل commits الفرع الحالي إلى قمة الفرع الهدف. يصبح التاريخ خطيًا — مما يخلق انطباعًا بأن التطوير كان تسلسليًا. ومع ذلك، يعيد rebase كتابة التاريخ، مما يغير تجزئات SHA-1 للـ commits، مما يجعله خطيرًا للفروع المشتركة التي يمكن للمطورين الآخرين الوصول إليها.

توصية: استخدم merge للفروع العامة حيث يكون التاريخ مرئيًا للمطورين الآخرين (feature → develop)، وrebase للعمل المحلي عندما تحتاج إلى تطبيق تغييرات جديدة من main إلى فرع الميزة الخاص بك قبل إنشاء Pull Request. القاعدة بسيطة: إذا تم دفع commit بالفعل إلى الخادم — لا تقم بإعادة تأسيسه.

حل التعارضات

تعارض الدمج يحدث عندما لا يستطيع Git دمج التغييرات تلقائيًا في ملف واحد. يحدد Git الأقسام المتعارضة في الملف بعلامات خاصة: <<<<<<< (تغييراتنا)، ======= (فاصل)، >>>>>>> (تغييراتهم). يقوم المطور بتحرير الملف يدويًا، واختيار الخيار المطلوب أو الجمع بينهما، ويكمل الدمج بـ commit.

العمل مع المستودعات البعيدة

المستودع البعيد (remote) هو نسخة من مستودع Git موجودة على خادم. GitHub وGitLab وBitbucket هي المنصات الأكثر شهرة لاستضافة المستودعات البعيدة. توفر واجهة ويب لعرض الكود وإدارة الوصول ومراجعة الكود والتكامل مع أنظمة CI/CD.

في Git، يمكنك تكوين عدة مستودعات بعيدة لمشروع واحد. افتراضيًا، يُسمى المستودع البعيد الرئيسي origin. الأمر git remote add يضيف مستودعًا بعيدًا جديدًا، git fetch يجلب التغييرات بدون دمج، وgit pull هو اختصار لـ git fetch + git merge. للعمل مع الكود عبر Pull Request، ينشئ المطور forkًا للمستودع، ويستنسخه، ويعمل في فرع ميزة، ويرسل طلب دمج إلى المستودع الأصلي.

# إضافة مستودع بعيد
git remote add origin https://github.com/user/repo.git

# عرض المستودعات البعيدة
git remote -v

# دفع فرع إلى الخادم
git push -u origin feature-auth

# جلب التغييرات من فرع بعيد
git pull origin main

المستودعات البعيدة تدعم الوسم لتحديد إصدارات الإصدار. يمكن أن تكون الوسوم خفيفة (مؤشر فقط إلى commit) أو مشروحة (تحتوي على بيانات وصفية: المؤلف، التاريخ، الرسالة). يُنصح باستخدام الوسوم المشروحة لإصدارات الإصدار لأنها تحمل معلومات كاملة عن الإصدار ويمكن توقيعها بمفتاح GPG للـ تحقق من التأليف.

Git Worktree للعمل المتوازي

Git Worktree يسمح بالعمل مع عدة فروع في وقت واحد في أدلة مختلفة بدون التبديل بينها. الأمر git worktree add ../feature-auth feature-auth ينشئ دليل عمل جديد feature-auth حيث يمكنك كتابة الكود بدون تبديل الفروع في الدليل الرئيسي. Worktree مفيد للإصلاحات السريعة في فرع release عندما يكون الدليل الرئيسي مشغولاً بتطوير طويل المدى.

Git Submodules للتبعيات

Git Submodules هي آلية لتضمين مستودع Git داخل آخر. يخزن الـ submodule مرجعًا إلى commit ثابت من مستودع خارجي، مما يضمن قابلية إعادة بناء التجميع. الأمر git submodule add https://github.com/example/lib.git يضيف مكتبة خارجية كـ submodule. عند استنساخ مشروع به submodules، تحتاج إلى تنفيذ git submodule update --init --recursive لتحميل جميع التبعيات.