git add — fayllarni staging ga qo'shish, . va fayl nomi farqi

~10 daq · Git · Git Asoslari

Muammodan boshlaylik

Ko'p qo'llanmalarda shunday yoziladi:

git add .
git commit -m "update"

Va bir kuni GitHub dan xat keladi: "Sizning repozitoriyingizda AWS kaliti topildi". git add . hamma narsani qo'shgan edi — .env faylini ham. Yoki 200 MB lik node_modules ni.

git add — oddiy buyruq, lekin uning turli shakllari turlicha xatti-harakatga ega. Bu darsda — qaysi birini qachon ishlatish.

Asosiy shakllar

git add index.html                  # bitta fayl
git add index.html style.css        # bir nechta fayl
git add src/                        # papka (ichidagi hammasi)
git add *.css                       # naqsh bo'yicha
git add .                           # joriy papka va ichidagi hammasi
git add -A                          # butun repozitoriydagi hamma o'zgarishlar
git add -u                          # faqat kuzatiladigan fayllar (yangilar emas)

. va -A — farqi

Repozitoriyning ildizida turgan bo'lsangiz — . va -A bir xil. src/ ichida turgan bo'lsangiz — git add . faqat src/ ni qo'shadi.

-u (update) — "faqat Git allaqachon kuzatayotgan fayllardagi o'zgarishlar": tasodifiy yangi fayllar (loglar, vaqtinchalik fayllar) kirmaydi.

git add . — qachon xavfli

git add . — qulay, lekin ko'r-ko'rona. Xavfsiz ishlatish uchun ikki shart:

1. .gitignore to'g'ri sozlangan (11-dars) — node_modules, .env, build papkalar, OS fayllari
2. Avval git status — nima qo'shilishini ko'ring

git status            # 1. Nima o'zgargan?
git add .             # 2. Qo'shish
git status            # 3. Staging da nima borligini tekshirish
git commit -m "..."

[!WARNING] Parollar, API kalitlari, .env fayllar bir marta commit qilinsa — keyin o'chirsangiz ham, ular tarixda qoladi. GitHub ga push qilingan bo'lsa — botlar ularni bir necha daqiqada topadi. Yagona to'g'ri yechim — kalitni darhol bekor qilish (yangisini yaratish), keyin tarixni tozalash. Eng yaxshisi — bunga yo'l qo'ymaslik: .gitignore va git status.

git add -p — faylning bir qismini

Bitta faylda ikki xil o'zgarish: xato tuzatish va debug uchun console.log. Faqat tuzatishni commit qilmoqchisiz:

git add -p login.js

Git o'zgarishlarni bo'laklarga (hunk) ajratib, har biri uchun so'raydi:

@@ -12,7 +12,7 @@ function login(email, parol) {
-  if (parol.length > 0) {
+  if (parol && parol.length >= 8) {
     return tekshir(email, parol);
   }
(1/2) Stage this hunk [y,n,q,a,d,s,e,?]? y

@@ -30,6 +30,7 @@ function tekshir(email, parol) {
+  console.log('DEBUG:', email, parol);
   const user = await db.find(email);
(2/2) Stage this hunk [y,n,q,a,d,s,e,?]? n

Natija: tuzatish — staging da, console.log — working directory da qoldi.

[!TIP] git add -p ni hech qanday fayl nomisiz ishlatish ham mumkin — barcha o'zgargan fayllarni birma-bir ko'rib chiqadi. Bu commit qilishdan oldin o'z kodingizni ko'rib chiqishning ajoyib usuli: nima kiritayotganingizni ko'rasiz va tasodifiy debug qatorlarini ushlaysiz.

VS Code da xuddi shu narsa — Source Control panelida faylni ochib, kerakli qatorlarni belgilab, o'ng tugma → Stage Selected Ranges.

Staging dan olib tashlash

Adashib qo'shdingiz:

git add .env
git restore --staged .env           # staging dan olib tashlash (fayl o'zgarmaydi)

Eski versiyalarda va qo'llanmalarda — git reset HEAD .env (xuddi shu narsa).

Hammasini staging dan olish:

git restore --staged .

Faylni Git kuzatuvidan butunlay chiqarish (lekin diskda qoldirish):

git rm --cached .env
echo ".env" >> .gitignore

Bu — .env allaqachon commit qilingan bo'lsa kerak (keyingi commit dan boshlab kuzatilmaydi; tarixdagi nusxasi baribir qoladi).

O'chirish va ko'chirish

git rm eski.js              # diskdan o'chirish + staging ga "o'chirildi" deb qo'yish
git mv eski.js yangi.js     # nomini o'zgartirish + staging ga

Bu rm eski.js && git add eski.js ning qisqartmasi. Oddiy rm yoki muharrirda o'chirsangiz ham bo'ladi — keyin git add -A o'chirishni ham qo'shadi.

Nima qo'shilganini ko'rish

git status                  # qaysi fayllar staged
git status -s               # qisqa format
git diff --staged           # staging da aynan nima o'zgargan (10-dars)

Qisqa format:

M  login.js         ← staged (chap ustun)
 M config.js        ← modified, staged emas (o'ng ustun)
MM style.css        ← ikkalasi: bir qismi staged, keyin yana o'zgargan
A  savat.js         ← yangi, staged
?? temp.log         ← untracked

Nima uchun shunday?

Nima uchun git add -p kabi "nozik" vosita kerak — butun faylni qo'shish oddiyroq-ku?

Chunki fayl — mantiqiy birlik emas. Bitta faylda bir vaqtda xato tuzatish, refaktoring va yangi funksiya bo'lishi mumkin. Agar Git faqat butun fayllarni qabul qilsa, siz yo ularni bitta "aralash" commit ga tiqasiz, yo ishlashni to'xtatib, har bir o'zgarishni alohida qilasiz. add -p bu tanlovni olib tashlaydi: erkin ishlaysiz, keyin tarixni toza yozasiz. Qo'shimcha foydasi — har bir bo'lakni ko'rib chiqish o'z-o'zidan code review: ko'p xatolar va unutilgan debug kodlar aynan shu bosqichda ushlanadi.

Xulosa

Eslab qoling:

• git add fayl — aniq; git add . — joriy papka; -A — butun repo; -u — faqat kuzatiladigan
• git add . dan oldin — .gitignore va git status
• Sirlar commit qilinsa — kalitni darhol bekor qiling
• git add -p — bo'laklab: y/n/s/q
• git restore --staged fayl — staging dan olish
• git rm --cached fayl — kuzatishni to'xtatish, diskda qoldirish
• git rm, git mv — o'chirish va nom o'zgartirish
• git status -s — qisqa holat

Keyingi dars

8-dars: git commit — commit nima, yaxshi commit xabari qanday yoziladi