Kommit qilish — bu nima, rasmiylashtirish qoidalari va Git bilan ishlash

Git-da kommit nima

Git-dagi kommit — bu loyiha fayllarining holatini ma'lum bir vaqtda saqlaydigan ob'ektdir. Har bir kommit barcha kuzatilayotgan fayllarning snapshotini, ota-kommitga havolani va metama'lumotlarni o'z ichiga oladi. Boshqa versiyalarni boshqarish tizimlaridan farqli o'laroq, Git content-addressable storage dan foydalanadi — har bir ob'ekt uning mazmunining SHA-1 heshi bilan aniqlanadi.

Dasturchi o'zgarishlarni kommit qilganda, Git commit obyektini yaratadi: tree obyekti (fayl tuzilmasi), ota-kommit hashi, muallif, komitter, sana va xabar. Bu obyekt o'zgarmasdir — yaratilgandan so'ng kommitni uning hashini o'zgartirmasdan modifikatsiya qilib bo'lmaydi. Aynan o'zgarmaslik loyiha tarixining yaxlitligini kafolatlaydi.

# O'zgarishlarni tayyorla va kommit qil
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Kommit tafsilotlarini ko'rish
git log --oneline -3
git show HEAD

# Barcha o'zgarishlarni tayyorla va bir qadamda kommit qil
git commit -a -m "Update dependencies to latest versions"

Kommitlar yo'naltirilgan siksiz grafik (DAG) tashkil qiladi, bunda har bir yangi kommit avvalgisiga havola qiladi. Bu tarix bo'ylab harakatlanish, o'zgarishlarni bekor qilish va kod bazasi evolyutsiyasini tahlil qilish imkonini beradi. Git DAG tuzilmasini tushunish — kommitlar bilan ilg'or ishlashning asosidir.

O'zgarishlarni qanday to'g'ri kommit qilish

Git-da kommit jarayoni ikki bosqichdan iborat: o'zgarishlarni staging area (indeks) ga qo'shish va kommit yaratish. Staging area dasturchiga ishchi katalogida ko'p fayllar o'zgartirilgan bo'lsa ham, kommitga qaysi o'zgarishlar kirishini tanlash imkonini beradi.

Atomarlik qoidasi — yaxshi kommitning asosiy prinsipi. Har bir kommit bitta mantiqiy o'zgarishni o'z ichiga olishi kerak. Agar dasturchi xatoni tuzatayotgan va kodni refaktor qilayotgan bo'lsa — bu ikki xil kommit. Atomar kommitlar kod-reviewni, o'zgarishlarni qaytarishni va tarix tahlilini soddalashtiradi.

Kommit qilishdan oldin tekshirish kerak: kodda disk raskadka chiqishi, sharhlangan bloklar yoki tasodifiy o'zgarishlar qolmaganmi. Buning uchun git diff --cached buyrug'i ishlatiladi, u kommitga nima kirishini ko'rsatadi. git status orqali qo'shimcha tekshirish staging area-dagi fayllar ro'yxatini ko'rsatadi.

• O'zgarishlarni tekshir — git diff --cached kommitga nima kirishini ko'rsatadi
• Sifatni tekshir — kod kommitdan oldin linter va testlardan o'tishi kerak
• Xabar yoz — o'zgarish maqsadining tushunarli tavsifi
• Stagedni tekshir — git status fayllar ro'yxatini tasdiqlaydi

Kommit xabarlarini yozish qoidalari

Kommit xabari — kelajak dasturchilari uchun o'zgarish hujjatidir. Yaxshi xabar savollarga javob beradi: nima o'zgartirildi va nima uchun. Conventional Commits konvensiyasi (Angular team, 2016) ko'plab loyihalar uchun standartga aylandi va formatni belgilaydi: tur(soha): tavsif.

Yaxshi kommit xabari sarlavhadan (50 belgigacha) va tanadan (ixtiyoriy, qatorga 72 belgigacha) iborat. Sarlavha buyruq maylida yoziladi: “Add” emas “Added” yoki “Adds”. Bosh harf va sarlavha oxirida nuqta qo'yilmaydi — bu xalqaro Git kelishuvi.

Yomon xabar: “fix things” yoki “update” — axborot bermaydi. Bir oydan so'ng dasturchi nima o'zgartirilganini va nima uchunligini tushuna olmaydi. Yaxshi xabar: “fix(payment): handle timeout in stripe callback” — darhol qayerda va nima tuzatilgani aniq.

Kommitlardagi keng tarqalgan xatolar

Dasturchilar, ayniqsa yangi boshlovchilar, kommitlarda tez-tez tipik xatolarga yo'l qo'yadilar. Eng keng tarqalgani — juda katta kommit, unda o'nlab o'zgarishlar aralashtirilgan. Bunday kommitni qisman qaytarib bo'lmaydi, kod-review esa azobga aylanadi.

Tezligi bo'yicha ikkinchi xato — yomon kommit xabari. “fix”, “update”, “changes” yoki “wip” turidagi xabarlar kelajak dasturchilariga kontekst bermaydi. Olti oydan keyin hech kim nima tuzatilganini eslamaydi. Qoida oddiy: tasavvur qiling, bir yildan keyin tarixga qarayapsiz va aniq o'zgarishni topishga harakat qilyapsiz.

Uchinchi xato — kompilyatsiya qilinmagan yoki ishlamaydigan kodni kommit qilish. Kommitdan keyin kod hech bo'lmaganda kompilyatsiya qilinishi kerak. Buzilmagan build — umumiy tarmoqqa har qanday kommit uchun asosiy talab. Buning uchun kommitdan oldin qurish va testlar ishga tushiriladi.

To'rtinchi xato — maxfiy ma'lumotlar bilan kommit. API kalitlari, parollar va tokenlar Git tarixiga tushmasligi kerak. Agar sir allaqachon kommit qilingan bo'lsa, uni oddiygina yangi kommitda o'chirish yetarli emas — butun tarixdan git filter-branch yoki BFG Repo-Cleaner orqali o'chirish kerak.

Kommitlar bilan ishlashda ilg'or texnikalar

Git kommitlar tarixini boshqarish uchun vositalarni taqdim etadi. Eng foydalilaridan biri git commit --amend — so'nggi kommitni yangi o'zgarishlar bilan to'ldirish yoki xabarni tuzatish imkonini beradi. Agar dasturchi fayl qo'shishni unutgan yoki xabarda xato qilgan bo'lsa, bu qulay.

# Oxirgi kommit xabarini tuzat
git commit --amend -m "fix(auth): correct token validation logic"

# O'tkazib yuborilgan faylni oxirgi kommitga qo'shish
git add missed-file.txt
git commit --amend --no-edit

# Oxirgi 3 kommit uchun interaktiv rebase
git rebase -i HEAD~3

Interactive rebase — tarixni qayta yozish uchun kuchli vosita. Kommitlarni birlashtirish (squash), xabarlarni o'zgartirish (reword), tartibni o'zgartirish (reorder) va kommitlarni o'chirish (drop) imkonini beradi. Biroq rebase tarixni o'zgartiradi, shuning uchun faqat uzoq repozitoriyga yuborilmagan lokal kommitlarga qo'llaniladi.

Kommitlarni bekor qilish uchun ikki yondashuv mavjud. git revert avvalgi kommitning o'zgarishlarini bekor qiladigan yangi kommit yaratadi — tarixni saqlaydigan xavfsiz usul. git reset kommitlarni tarixdan o'chiradi — agar kommitlar allaqachon yuborilgan bo'lsa xavfli. Jamoa ishida nashr etilgan kommitlarni bekor qilish uchun faqat git revert ishlatiladi.