mrsaynothing.dev
.gitignore لا يعمل: القاعدة لا تصل إلى الفهرس
check-ignore -v يحسم الأمر في ثلاثين ثانية — قاعدة مطبوعة تعني مشكلة في القواعد، والصمت يعني أن الملف متتبَّع أصلًا، وrm --cached ينهي القصة.
■ space · مسار النثر
.gitignore «لا يعمل» تعني في الغالب أن الملف متتبَّع أصلًا — الملف في الفهرس محصَّن ضد أي قاعدة تكتبها.
git check-ignore -v <path> يحسمها: قاعدة مطبوعة = مشكلة في القواعد؛ صمت = متتبَّع ولا قاعدة تسري.
العلاج: git rm --cached <path>، ثم commit — القاعدة تعمل من ذلك الـcommit فصاعدًا.
البابان
أمر واحد، نتيجتان — git check-ignore -vيوصلك إلى أحدهما:
الباب 1 · يطبع قاعدة
$ git check-ignore -v debug.log
.gitignore:3:*.log debug.logقاعدة تسري — غير الصحيحة، أو في النطاق الخطأ. المشكلة تسكن ملف .gitignore: ترتيب القواعد، فخاخ النفي، أو ملف التجاهل الذي يملك المسار.
الباب 2 · صمت
$ git check-ignore -v src/.env
$ # (nothing — no rule applies)الملف متتبَّع على أي حال. تأكَّد بـ git ls-files --error-unmatch <path>، ثم git rm --cached <path> وأودِع حذفَه. الصمت هو التشخيص.
رموز الخروج قابلة للبرمجة: 0 = متجاهَل، 1 = غير متجاهَل — git check-ignore -q debug.log && echo ignored || echo tracked-or-unruly
العينة — ملف .gitignore سطرًا سطرًا
فخ النفي، مشروحًا. لماذا !build/keep.me لا ينقذ الملف أبدًا:
build/يتجاهل المجلد بأكمله — git لا يعود ينظر بداخله أبدًا!build/keep.meرسالة ميتة: لا يمكنك إعادة تضمين ملف داخل مجلد مستثنىbuild/*الحل — تجاهل المحتويات، لا المجلد!build/keep.meالآن تنجح: المسار الأصلي سالك، والاستثناء يسري*.log ثم !important.logالقاعدة الأخيرة المطابقة هي الفائزة — النفي بعد القاعدة يعيد تضمين ذلك الملف وحدهجدول الأسباب الكامل
| العَرَض | السبب الحقيقي | العلاج |
|---|---|---|
الملف المتجاهَل ما يزال يظهر في git status | أُودِع قبل القاعدة — في الفهرس | git rm --cached + commit |
git add . يعيد إضافته باستمرار | نفس الشيء: التتبع يغلِّب التجاهل | بالجملة: git rm -r --cached . → git add . |
!build/keep.me لا ينقذ الملف أبدًا | المجلد الأب مستثنى — git يتخطاه كله | build/* + !build/keep.me |
| قاعدة لاحقة تلغي قاعدتك | القاعدة الأخيرة المطابقة هي الفائزة | أعد الترتيب، أو اقرأ الفائزة عبر check-ignore -v |
| القاعدة تعمل عند زملائك لا عندك (أو العكس) | .gitignore المتداخل / exclude / العام غير متطابقة | قارن مع جدول النطاقات أدناه |
| VS Code يظهره معدَّلًا بعد التجاهل | متتبَّع — أو عرض SCM قديم غير محدَّث | git rm --cached؛ أعد تحميل النافذة أولًا |
| تريد تعديلات صامتة والملف يبقى متتبَّعًا | انحراف محلي مقصود | git update-index --skip-worktree |
النطاقات الثلاثة
القواعد يمكن أن تسكن ثلاثة أماكن، و«تعمل عند الزملاء ولا تعمل عندي» يعني في الغالب عدم تطابق النطاق:
.gitignoreفي المستودع — مودَع ومشترك مع الجميع. البيت الافتراضي لمخرجات البناء ومجلدات الاعتماديات..git/info/exclude— لكل استنساخ، لا يُودَع أبدًا. لملفاتك الشخصية في هذا checkout بعينه.- ملف التجاهل العام عندك (
core.excludesFile) — لكل آلة، عبر كل المستودعات. البيت الكلاسيكي لـ.DS_Storeوفضلات المحررات.
قراءة مخرجات check-ignore -v يسمّي المصدر مباشرةً: ملف التجاهل، ثم line-number:pattern، ثم المسار — فحين تربح قاعدة غير متوقعة، يعرِّف الفائز عن نفسه.
تحقّق: git check-ignore -v debug.log → .gitignore:3:*.log debug.log
إخراج من التتبع، خطوة بخطوة
# untrack one file (the local copy survives — --cached touches the index only)
git rm --cached .env
git commit -m "stop tracking .env"
# verify the ignore rule now applies
git check-ignore -v .envمن هذا الـcommit فصاعدًا، .gitignore يملك المسار: التعديلات لا تظهر بعد الآن في git status، ولن git add . يلتقط الملف مرة أخرى.
إن كان سرًّا، فالإخراج من التتبع ليس العلاج. الملف يبقى في التاريخ — إزالته من آخر commit لا تكفي. تدوير بيانات الاعتماد هو العلاج الحقيقي؛ وإعادة كتابة التاريخ تجميلي.
نهاية البابين · لا شيء جُلِب بـfetch · كل شيء محلي