Question 1

هل يحذف git rm --cached السرّ من تاريخ مستودعي؟

Accepted Answer

لا. يوقف تعقّب الملف فقط ابتداءً من الكوميت التالي. لا يزال .env وسره موجودَين في الكوميت السابق. إيقاف التعقّب هو الخطوة الأولى؛ المسح الفعلي يستلزم إعادة كتابة التاريخ.

Question 2

إذًا ماذا يفعل git rm --cached فعلًا؟

Accepted Answer

يزيل الملف من فهرس Git (التعقّب) مع إبقائه على القرص. مدموجًا مع إدخال في .gitignore، يتوقف Git عن تسجيل الملف مستقبلًا، وهذا ما يتدرب عليه السيناريو.

Question 3

إن بقي السرّ في التاريخ، فما الذي يجب فعله حقًا؟

Accepted Answer

اعتبر السرّ مكشوفًا وقم بتدويره: غيّر فورًا كلمة المرور أو مفتاح الـ API أو الرمز. ثم احذفه من الكوميتات السابقة بأداة لإعادة كتابة التاريخ مثل git filter-repo أو BFG، وافعل force-push إن كان قد شُورك.

Question 4

لماذا نضيف .env إلى .gitignore؟

Accepted Answer

كي لا يُجهَّز الملف عن طريق الخطأ مرة أخرى. إيقاف التعقّب دون .gitignore سيتيح لـ git add التالي إعادة إضافة السر نفسه.

Question 5

كيف أزيل ملف .env كان قد كُوّم بالفعل؟

Accepted Answer

نفّذ git rm --cached .env لإيقاف تعقّبه، أضف .env إلى .gitignore، ثم كوّم. هذا يوقف التسريبات المستقبلية، لكن السر لا يزال يعيش في الكوميتات السابقة، فتحتاج أيضًا إلى إعادة كتابة التاريخ وتدوير السر.

Question 6

كيف أزيل سرًّا من تاريخ Git بأكمله؟

Accepted Answer

أعد كتابة كل كوميت يحويه بـ git filter-repo (المُوصى به) أو BFG Repo-Cleaner، ثم افعل force-push. ولأن التاريخ يتغير، نسّق مع كل من استنسخ المستودع.

Question 7

هل يكفي حذف السر في كوميت جديد فقط؟

Accepted Answer

لا. لا يزال الكوميت القديم يحوي السر، فبإمكان أي شخص لديه وصول إلى التاريخ قراءته. عليك إعادة كتابة التاريخ لتطهيره، والأهم من ذلك تدوير بيانات الاعتماد المسرَّبة.

Question 8

هل ينبغي تدوير سرّ بعد كوميته؟

Accepted Answer

نعم، دائمًا. حالما يُكوَّم سرّ ويُدفع، اعتبره مكشوفًا وأصدر مفتاحًا أو رمزًا جديدًا. إزالته من التاريخ تقلّل التعرّض لكنها لا تلغي التسريب.

إزالة الأسرار من repository في Git | WebTerm