انتقل إلى المحتوى

دورة العمل اليومية

دورة العمل اليومية مع Git ستة أوامر متكرّرة: git pull لتجلب آخر التعديلات، ثم عدّل الملفات، ثم git status لترى ما تغيّر، ثم git add لتجهّز التعديلات، ثم git commit لتحفظها، وأخيرًا git push لترسلها إلى ليڤانت غيت. وتحت هذه الحلقة تجد شرح الـ staging area، وكتابة commit messages جيدة، والتراجع عن خطأ قبل أن تحفظه.

نفترض أن عندك repository نفّذت له clone على جهازك. إن لم يكن، ابدأ من أول repository.

الحلقة في سطر واحد

git pull ← تعديل ← git status ← git add ← git commit ← git push

افتح الطرفية داخل مجلد المشروع، ثم تابع الخطوات.

١. نفّذ pull لآخر التعديلات

قبل أن تبدأ العمل، اجلب ما دفعه زملاؤك إلى الـ remote:

git pull

إن كنت تعمل وحدك فلن يتغيّر شيء غالبًا، لكن العادة مفيدة.

٢. عدّل الملفات

افتح الملفات بمحرّرك المعتاد وعدّل ما تشاء. Git لا يراقبك لحظيًا؛ هو يقارن فقط عندما تطلب منه.

٣. انظر ماذا تغيّر

git status

يعرض لك الملفات المعدَّلة (بالأحمر عادةً) والملفات الجديدة التي لا يتتبّعها Git بعد. هذا الأمر آمن تمامًا، استخدمه كلما شككت.

لرؤية التعديلات سطرًا سطرًا:

git diff            # الفرق بين الـ working directory والـ staging area
git diff --staged   # الفرق بين الـ staging area وآخر commit

الأول يريك ما عدّلته ولم تجهّزه بعد، والثاني يريك ما جهّزته ولم تحفظه في commit بعد.

٤. جهّز التعديلات

git add index.html        # ملف واحد
git add src/              # مجلد كامل
git add .                 # كل التعديلات في المجلد الحالي

٥. نفّذ commit

git commit -m "أضف صفحة الاتصال"

الـ commit لقطة محفوظة لحالة المشروع مع رسالة تشرحها. لو عدّلت عشرة ملفات لكن جهّزت ملفين فقط، فالـ commit يضم الملفين فقط.

٦. نفّذ push

git push

الآن تعديلاتك على ليڤانت غيت ويستطيع الآخرون جلبها بـ git pull.

ما هو الـ staging area؟

بين مجلد عملك على القرص — وهو ما يسمّيه Git الـ working directory — وبين الـ commit توجد منطقة وسيطة اسمها staging area. فكّر فيها كطاولة تجمع عليها ما تريد حفظه الآن: git add يضع الملف على الطاولة، وgit commit يلتقط صورة لما على الطاولة فقط. هذا يسمح لك بتقسيم عمل يوم كامل إلى commits صغيرة ومفهومة.

كتابة commit message جيدة

  • سطر أول قصير (أقل من ٥٠ حرفًا تقريبًا) يصف ماذا فعلت في هذه الـ commit.
  • صيغة الأمر: «أضف» لا «أضفتُ»، وبالإنجليزية Add لا Added.
  • العربية أو الإنجليزية كلتاهما جيدتان؛ المهم أن تختار لغة واحدة للمشروع كله.
  • إن احتجت شرحًا أطول، اترك سطرًا فارغًا ثم اكتب التفاصيل:
git commit -m "أصلح حساب الضريبة في الفاتورة" -m "كانت النسبة تُطبَّق مرتين عند وجود خصم."

نصيحة

إن لم تستطع وصف الـ commit بجملة واحدة، فغالبًا يجب أن تكون commitين.

قراءة الـ log

git log --oneline

الـ log هو سجل الـ commits، ويعرضه هذا الأمر commit في كل سطر: معرّف قصير ثم الرسالة. اضغط q للخروج إن طال العرض.

التراجع قبل الـ commit

  • عدّلت ملفًا ثم ندمت؟ أعده إلى حالته في آخر commit:
git restore index.html
  • جهّزته بـ git add ثم أردت إخراجه من الـ staging area (دون فقدان التعديل):
git restore --staged index.html

تنبيه

git restore <file> بلا --staged يمحو تعديلاتك التي لم تحفظها في commit نهائيًا.

تعديل آخر commit

نسيت ملفًا أو أخطأت في الرسالة؟ جهّز ما نسيته ثم:

git commit --amend -m "الرسالة الصحيحة"

هذا يستبدل آخر commit بأخرى جديدة. استخدمه قبل الـ push فقط؛ بعده يصبح تغيير التاريخ مصدر متاعب لزملائك.

ملف .gitignore

بعض الملفات لا يجب أن تدخل الـ repository أبدًا: مجلدات التبعيات، ملفات البناء، كلمات السر، ملفات النظام. اكتب أسماءها في ملف .gitignore في جذر المشروع:

node_modules/
*.log
.env
.DS_Store

كل ما يطابق هذه الأنماط يتجاهله git status وgit add .. أضف ملف .gitignore نفسه إلى الـ repository حتى يستفيد الجميع.

متى تنفّذ commit؟

صغيرًا وكثيرًا. كل خطوة منطقية مكتملة تستحق commit: إصلاح خطأ، إضافة دالة، تحديث README. الـ commits الصغيرة أسهل في المراجعة، وأسهل في التراجع عنها إن لزم. ونفّذ push في نهاية كل جلسة عمل على الأقل، فالـ commit التي لم تُدفع لا نسخة منها إلا على جهازك.

ماذا بعد؟