المناطق الثلاث: الـ Working Tree والـ Index والـ Repository

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

ثلاثة أماكن قد يكون فيها عملك

كل تغيير في مشروع Git يعيش في واحد من ثلاثة أماكن:

• الـ working tree (مجلد العمل) هو الملفات على القرص، تلك التي يفتحها محرّرك. تغيّرها بحرية، و Git يراقب فقط.
• الـ index، ويُسمّى أيضًا staging area (منطقة التجهيز)، هو الـ commit التالي قيد التجميع. الأمر git add ينسخ المحتوى الحالي للملف إليه.
• الـ repository (المستودع) هو الـ commits المسجّلة بالفعل داخل .git. والأمر git commit يحوّل الـ index إلى commit جديد.

بعد الـ commit لا يُفرَّغ الـ index. بل يظل يحمل اللقطة الكاملة التي سجّلتها للتو، فيطابق آخر commit إلى أن تجهّز شيئًا جديدًا. لهذا فإن «التغييرات المجهّزة» تعني الفرق بين الـ index وآخر commit.

رؤية الفرق: status و diff بنوعيه

هذا عمل الأمسية كما يعرضه git status:

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	styles.css

no changes added to commit (use "git add" and/or "git commit -a")

يخبرك git status أيّ الملفات تختلف. ولرؤية الأسطر نفسها استخدم git diff، وتذكّر أن هناك مقارنتين:

git diff            # working tree vs index: what you haven't staged yet
git diff --staged   # index vs last commit: what the next commit will contain

الخيار --cached مرادف أقدم لـ --staged؛ وستراهما كليهما في الشروحات. اجعل تشغيل git diff --staged عادة قبل كل commit مباشرة. إنها اللحظة الأخيرة لتلاحظ console.log نسيته أو ملفًا لا ينتمي إلى هذا الـ commit.

تقسيم ملف واحد على اثنين من الـ commits

تصحيح الخطأ الإملائي وشريط التنقّل كلاهما في index.html. الأمر git add index.html سيجهّزهما معًا. جهّز تصحيح الخطأ وحده بدلًا من ذلك:

git add -p index.html

يعرض Git كل كتلة متغيّرة، وتُسمّى hunk، ويسأل Stage this hunk [y,n,q,a,d,s,e,?]? (تعرض الإصدارات الأحدث حروفًا إضافية، والحرف ? يشرحها كلها). أجب بـ y على كتلة الخطأ الإملائي و n على كتلة شريط التنقّل (والحرف s يقسم الكتلة إن كانت كبيرة جدًا). ثم:

git diff --staged          # only the typo fix
git commit -m "Fix spelling of name in header"
git add index.html styles.css
git commit -m "Add navigation bar with base styles"

اثنان من الـ commits، لكل منهما غرض واحد. ولاحقًا، إن احتجت إلى إزالة شريط التنقّل، تستطيع التراجع عن ذلك الـ commit وحده.

ما الحجم المناسب للـ commit؟

الـ commit الجيد يفعل شيئًا واحدًا تستطيع وصفه بجملة قصيرة دون كلمة «و». الرسالة “Fix spelling of name in header” تنجح في هذا الاختبار. أما “Add nav, fix typo, tweak colours” فتفشل، ويظهر الفشل لاحقًا: حين يتبيّن أن الألوان خاطئة، فإن التراجع عن ذلك الـ commit يزيل شريط التنقّل أيضًا ويعيد الخطأ الإملائي.

لا يوجد حدّ لعدد الأسطر. الـ commit الذي يعيد تسمية class في CSS عبر اثني عشر ملفًا يظل فكرة واحدة، وتقسيمه سيترك الموقع معطّلًا بين الخطوتين. اسعَ إلى commits يبقى المشروع بعدها وقبلها يعمل، وكل واحد منها خطوة تستطيع شرحها للمراجِع في نَفَس واحد. ستقدّر هذا في القسم الرابع، حين يصبح التراجع عن commit واحد أمرًا من سطر واحد بدل ساعات من العمل الجراحي الدقيق.

الحالة المختصرة، والتراجع

يضغط git status -s المعلومات نفسها في عمودين: الأيسر يقارن الـ index بآخر commit، والأيمن يقارن الـ working tree بالـ index.

M  README.md
 M index.html
MM styles.css
?? projects.html

README.md مجهّز؛ و index.html فيه تغييرات غير مجهّزة؛ و styles.css فيه من الاثنين؛ و projects.html غير متتبَّع (untracked).

لإخراج ملف من الـ index دون أن تخسر تعديلاتك، استخدم git restore --staged styles.css. ولرمي التعديلات غير المجهّزة والعودة إلى نسخة الـ index، استخدم git restore styles.css. الأمر الثاني هو الوحيد في هذا الدرس الذي يُتلف عملًا: التغييرات التي لم تُجهَّز ولم تُسجَّل قط لا يمكن استرجاعها.

صرت قادرًا على تسجيل السجلّ الذي تقصده بالضبط. في الدرس التالي ستقرأ هذا السجلّ، وترى لماذا يسمّيه Git رسمًا بيانيًا (graph) لا قائمة.