Git-da Commit qilish va yaxshi Commit xabarlari yozish

Bu videoda commit qilish va yaxshi commit xabarlari yozish o'rganiladi. Source Control loyihada o'zgarish bo'lganda, eski va yangi versiya o'rtasidagi farqni tushunadi. Vaqti-vaqti bilan bu o'zgarishlarni Version Control tarixiga saqlash kerak bo'ladi — bu jarayon commit deb ataladi.

Commit nima — Checkpoint metaforasi

Commit-ni video o'yinlardagi checkpointga o'xshatish mumkin. O'yinda checkpointga yetganingizda, keyingi safar "o'lganingizda" o'yin boshidan emas, checkpointdan qayta boshlanadi.

Xuddi shunday, kod yozishda ma'lum bir nuqtaga yetganda — bu nuqtani commit qilib, "checkpoint" yaratish mumkin. Bu checkpointga istalgan vaqtda qaytish imkoniyati beradi.

.gitignore — keraksiz fayllarni chetlatish

Commit qilishdan oldin, ba'zi fayllarni Source Control-dan chetlatish tavsiya etiladi — masalan, .DS_Store va xcuserdata fayllari. Bu fayllar Xcode tomonidan avtomatik yaratiladi va boshqa dasturchilar bilan ulashishning hojati yo'q.

Xcode → Settings → Source Control → Git bo'limida bu fayllarni chetlatish mumkin:

xcuserdata/
.DS_Store

Bu fayllarni commit qilish katta muammo emas, lekin ular doimiy o'zgarib turadi va Git tarixida keraksiz shovqin yaratadi.

Xcode orqali commit qilish

Asosiy jarayon

1. Integrate → Commit (yoki klaviatura: Option + Command + C)
2. O'zgargan fayllar ro'yxati ko'rinadi
3. Commit xabari yoziladi
4. Stage All bosiladi
5. Commit tugmasi bosiladi

Jarayon: Option+Command+C → commit xabarini yozish → Stage All → Commit

O'zgarishlarni ko'rish

Xcode-da fayl tanlanganda, eski va yangi versiya solishtirib ko'rsatiladi:

• Raqamsiz qatorlar — o'chirilgan
• Yangi qo'shilgan qatorlar — belgilangan
• O'zgarmagan qatorlar — oddiy ko'rinishda

Eslatma: Xcode-ning o'zgarishlarni ko'rsatish interfeysi ko'pchilik dasturchilar uchun unchalik qulay emas. GitKraken kabi uchinchi tomon vositalari (inline yoki split view bilan) buni ancha tushunarli qiladi.

GitKraken orqali commit qilish

GitKraken-da jarayon yanada vizual:

1. O'zgargan fayl tanlanadi — qaysi qatorlar o'zgarganini aniq ko'rish mumkin (qizil — o'chirilgan, yashil — qo'shilgan)
2. Faqat kerakli fayllar stage qilinadi (hammasi emas, agar kerak bo'lmasa)
3. Commit xabari yoziladi (sarlavha va ixtiyoriy tavsif)
4. Commit tugmasi bosiladi

GitKraken-ning afzalligi — commit tarixi vizual daraxt shaklida ko'rsatiladi, har bir commit alohida nuqta sifatida ko'rinadi.

Main branch — ikki marta ko'rinishi

GitKraken-da ba'zan main belgisi ikki marta ko'rinadi. Bu normal holat: biri local (lokal kompyuterdagi) branch holatini, ikkinchisi remote (GitHub-dagi) branch holatini bildiradi. Agar lokal branch-da yangi commit-lar bo'lib, ular hali push qilinmagan bo'lsa, ikkala belgi turli joyda ko'rinadi.

Yomon commit xabarlari — misollar

❌ "my first commit"
❌ "my second commit"
❌ "fixed a bug"
❌ "changed style"
❌ "oops"

Bu xabarlar hech narsani anglatmaydi. Loyihada yuzlab yoki minglab commit bo'lganda, qaysi commit-da nima o'zgarganini bilish uchun har birini alohida ochib ko'rish kerak bo'ladi — bu juda ko'p vaqt oladi.

Yaxshi commit xabarlari — misollar

✅ "add click me button"
✅ "fixed background color on click me button"
✅ "home view updates - progress"
✅ "home view finish"

Yaxshi commit xabari — keyinchalik o'zingiz yoki boshqa dasturchilar commit tarixini ko'rganda, har bir commitda aniq nima o'zgarganini tushunish imkonini beradi.

Prefiks tizimi — tartibli commit yozish usuli

Ko'plab jamoalar commit xabarlariga prefiks qo'shadi — bu commit turi haqida tezkor ma'lumot beradi:

feature: yangi funksiya qo'shildi tavsifi
patch: production-dagi xatoni tuzatish tavsifi
bug: xato tavsifi
clean: kod tartibga solish yoki hujjat yangilash tavsifi
release: yangi versiya chiqarilishi tavsifi

Prefikslar nima uchun ishlatiladi

• feature — yangi funksiya qo'shilganda
• patch — allaqachon ishlab chiqarishda (production) bo'lgan xatoni tuzatishda
• bug — umumiy xato haqida (production-da bo'lmasligi mumkin)
• clean — kodni tartibga solish, hujjat qo'shish, fayllarni qayta nomlash kabi oddiy ishlar uchun
• release — yangi versiya chiqarilganda

Misol jarayon

1. feature: yangi ekran qo'shildi
2. feature: ekran funksiyasi to'ldirildi
3. (testga yuborildi, foydalanuvchilar xato topdi)
4. bug: tugma ishlamayotgan xato tuzatildi
5. (production-ga chiqarildi)
6. release: 1.2.0 versiyasi
7. (production-da yana xato topildi)
8. patch: production-dagi kritik xato tuzatildi

Prefiks tizimining afzalligi

Jamoada ishlaganda, prefiks tizimi orqali commit tarixini ko'rib, kim nima ustida ishlayotganini tezda tushunish mumkin: agar 20 ta commit "feature" prefiksi bilan kelsa — bu muhandis uzoq vaqt biror funksiya ustida ishlagani bildiradi. Agar ko'p commit "clean" bo'lsa — bu kodni tartibga solish ishi.

Eslatma: Bu — bitta yondashuv namunasi, majburiy qoida emas. Jamoaga qo'shilganda, mavjud konventsiyalarni so'rab bilish va ularga moslashish tavsiya etiladi.

⚠️ Muhim qoida — hech qachon kompilyatsiya bo'lmagan kodni commit qilmang

❌ Loyiha build bo'lmasa — commit qilmang!

Agar boshqa dasturchi loyihani clone qilib, kompilyatsiya qilolmasa — bu jiddiy muammo. Commit qilishdan oldin loyiha muvaffaqiyatli build bo'lishini tekshirish kerak. Bu — Source Control bilan ishlashda eng muhim qoidalardan biri.

Bir nechta o'zgarishni bitta commitga jamlash

Agar bir vaqtning o'zida bir nechta kichik o'zgarish kiritilgan bo'lsa, ularni vergul bilan ajratib bitta commit xabarida yozish mumkin:

"change button color, update text, fix spacing"

Yoki ularni alohida-alohida commit qilish ham mumkin. Bu — loyihaning xususiyatlariga va shaxsiy ish uslubiga bog'liq.

Faqat lokalda ishlash

Bu video davomida barcha commit-lar faqat lokal repositoryda qoladi — ular GitHub-ga (remote-ga) push qilinmaydi. Bu ataylab shunday qilinadi — push qilish alohida videoda ko'rib chiqiladi.

Xulosa

Yaxshi commit xabari yozish — Source Control-dan samarali foydalanishning yarmidan ko'pini tashkil etadi. Bu kelajakda o'zingiz va jamoadoshlaringiz uchun loyiha tarixini tushunishni ancha osonlashtiradi.