Git, GitHub va jamoaviy workflow

Dasturchilar Git branch va pull request orqali web loyiha ustida hamkorlik qilishi — Git o’zgarishlar tarixini boshqaradi, GitHub kabi platforma esa kodni ulashish, review va avtomatik tekshiruvni tashkil qiladi.

Web loyiha bir kunda tugamaydi. Kod yuzlab marta o’zgaradi, ayrim yechimlar ishlamaydi va jamoada bir nechta odam bir faylga tegishi mumkin. Versiya nazorati o’zgarishlar tarixini saqlab, kim nima va nima sabab o’zgartirganini ko’rishga yordam beradi.

Git va GitHub bir xil emas

Git — kompyuteringizda ishlaydigan taqsimlangan versiya nazorati tizimi. U commitlar, branchlar va tarixni boshqaradi. GitHub, GitLab yoki boshqa platforma esa Git repozitoriysini internetda saqlash, jamoa bilan ulashish, pull request, issue va avtomatik tekshiruvlarni tashkil qilish xizmatidir.

Internet bo’lmasa ham lokal Git bilan commit qilish mumkin. GitHub’ga push qilish uchun esa tarmoq va remote repozitoriy kerak.

Asosiy tushunchalar

Tushuncha	Ma’nosi
Repository	Loyiha fayllari va ularning Git tarixi
Commit	Ma’noli o’zgarishlar to’plamining tarixdagi nuqtasi
Branch	Asosiy tarixdan mustaqil ish yo’nalishi
Remote	Internetdagi repozitoriy manzili
Push	Lokal commitlarni remote’ga yuborish
Pull	Remote’dagi o’zgarishlarni olish va birlashtirish
Merge	Ikki tarix yo’nalishini birlashtirish

Yaxshi commit bitta maqsadni bajaradi va tushunarli nomga ega bo’ladi: Login formasida email tekshiruvi qo'shildi. update, fix yoki asd kabi nomlar keyin tarixni o’qishda yordam bermaydi.

Branch va pull request

Jamoada yangi vazifa odatda alohida branchda bajariladi:

Asosiy branchning yangi holati olinadi.
Vazifa uchun branch yaratiladi.
Kichik, mantiqiy commitlar qilinadi.
Branch remote’ga push qilinadi.
Pull request ochiladi.
Avtomatik test va build bajariladi.
Jamoa a’zosi kodni review qiladi.
Kamchiliklar tuzatilgach, branch asosiy tarixga merge qilinadi.

Main branchdan feature branch ochilib commit, pull request, review va merge orqali qaytishi — Feature branch tajribani asosiy koddan ajratadi; pull request esa merge oldidan tekshiruv nuqtasini yaratadi.

Merge conflict nima

Ikki branch bir faylning bir xil qatorlarini turlicha o’zgartirsa, Git qaysi variantni tanlashni bilmaydi va merge conflict chiqaradi. Bu Git buzildi degani emas; inson qarori kerak degani.

Conflict yechishda:

Ikkala o’zgarishning maqsadini tushuning.
Kerakli yakuniy kodni qo’lda yozing.
Conflict belgilarini olib tashlang.
Test va buildni qayta bajaring.
Yechimni commit qiling.

Faqat “mine” yoki “theirs”ni ko’r-ko’rona tanlash boshqa odamning zarur o’zgarishini yo’qotishi mumkin.

`.gitignore` va sirlar

Build natijalari, o’rnatilgan paketlar, lokal sozlama va maxfiy .env fayllari odatda Git’ga qo’shilmaydi. Buning uchun .gitignore ishlatiladi.

Pull requestda avtomatik build, test, code review va tasdiqdan so'ng merge bajarilishi — Pull request kodni asosiy branchga qo’shishdan oldin avtomatik va inson tekshiruvlarini bir joyga yig’adi.

Qisqacha xulosa

Git lokal versiya nazorati, GitHub esa hamkorlik platformasidir.
Commit bitta ma’noli o’zgarishni tushunarli nom bilan saqlaydi.
Branch yangi ishni asosiy tarixdan ajratadi.
Pull request build, test va code review uchun nazorat nuqtasidir.
Merge conflict inson qaysi yakuniy kod to’g’ri ekanini hal qilishini talab qiladi.
Sirlar repozitoriyga yozilmaydi; oshkor bo’lgan kalit almashtiriladi.

Keyingi darsda deploy va operatsiyalar — tayyor kodni serverga chiqarish va kuzatishni ko’ramiz.