Push qilish — bu nima, git push qanday ishlaydi va qachon kerak

Gitda push nima

Git push — bu lokal repozitoriyadan uzoq repozitoriyaga commit-larni uzatuvchi buyruq. Commitdan farqli o'laroq, o'zgarishlarni faqat dasturchining lokal mashinasida saqlaydi, push esa bu o'zgarishlarni butun jamoa uchun e'lon qiladi. Push Pull Request yaratish va deploy qilishdan oldin majburiy qadamdir.

Git arxitekturasi har bir dasturchining o'z lokal repozitoriyasida ishlashini nazarda tutadi. Commit-lar lokal ravishda yaratiladi va dasturchi ularni push qilishga qaror qilguncha to'planadi. Bu erkinlik beradi: ko'plab lokal commit-lar qilish, tajriba o'tkazish va tarixni jamoaga ta'sir qilmasdan qayta yozish mumkin.

# Origin remote-ga push, main branch
git push origin main

# Joriy branchni remote-ga upstream bilan push qil
git push -u origin feature/new-dashboard

# Mos nomlar bilan barcha branchlarni push qil
git push --all origin

# Lease bilan force push (xavfsiz force push)
git push --force-with-lease

Pushdan so'ng uzoq repozitoriya refs-larni (branch havolalarini) yangilaydi, ular yangi commit-larga ishora qiladi. Boshqa dasturchilar bu o'zgarishlarni git pull yoki git fetch orqali olishlari mumkin. Aynan shu commit almashinuvi hamkorlikda ishlashning asosini tashkil qiladi.

Git push qanday ishlaydi

Git push buyrug'i lokal va uzoq branch-larni taqqoslaydi va faqat yetishmayotgan commit-larni uzatadi. Git barcha fayllarni qaytadan yubormaydi — faqat farqni (delta) uzatadi, bu esa push-ni katta repozitoriyalarda ham tez qiladi. Git Protokoli uzatiladigan ma'lumot hajmini minimallashtiradigan smart transferdan foydalanadi.

Agar uzoq branchda lokalda mavjud bo'lmagan commit-lar bo'lsa, push rad etiladi. Bu o'zgarishlarni yo'qotishning oldini oluvchi himoya mexanizmidir. Bunday vaziyatda dasturchi avval git pull-ni bajarishi, o'zgarishlarni birlashtirishi va shundan keyin qayta push qilishi kerak. Muqobil variant force push bo'lib, u uzoq branch-ni qayta yozadi, ammo ehtiyotkorlik bilan ishlatilishi kerak.

Uzoq repozitoriyalarni tushunish to'g'ri pushning kalitidir. Odatda origin — standart uzoq repozitoriya nomi ishlatiladi. Git remote -v buyrug'i uzoq repozitoriyalar ro'yxatini va ularning URL-larini ko'rsatadi. Bir nechta remote qo'shish mumkin (masalan, asosiy repozitoriya uchun origin va fork uchun upstream).

Qachon push qilish kerak

Asosiy qoida: har bir mantiqiy tugallangan ish bosqichidan keyin push qilish kerak. Agar dasturchi vazifani yoki uning bir qismini tugatgan bo'lsa — push vaqti. Biroq, build-ni buzadigan tugallanmagan ishni push qilish tavsiya etilmaydi. Ishlaydigan build har qanday branchga push uchun minimal talabdir.

Jamoa ishlarida quyidagi ritm qabul qilingan: ertalab — hamkasblarning o'zgarishlarini olish uchun git pull, kun davomida — bir nechta commit va bir-ikki push, kechqurun — barcha tugallangan vazifalarning yakuniy pushi. Dasturchi qanchalik tez-tez push qilsa, branch-larni birlashtirishda konflikt xavfi shunchalik kam va ish jarayoni shunchalik shaffof bo'ladi.

• Vazifani tugatgandan keyin — commit qilish va yakuniy yechimni feature branchga push qilish
• Ketishdan oldin — tugallanmagan ishni feature branchga push qilish (mainga emas!)
• PR yaratishdan oldin — barcha commit-lar push qilinganiga va review uchun mavjudligiga ishonch hosil qilish
• Rebasedan keyin --force-with-lease bilan o'z feature branchiga push qilish

Xavfsiz push qoidalari

Xavfsiz push — jamoada ma'lumot yo'qotilishi va konfliktlarning oldini oluvchi qoidalar to'plamidir. Birinchi va eng muhim qoida: agar loyihada to'g'ridan-to'g'ri deploy sozlanmagan bo'lsa, hech qachon to'g'ridan-to'g'ri main yoki master branchga push qilmang. Zamonaviy jamoalarda main branch himoyasi GitHub branch protection darajasida sozlanadi.

Ikkinchi qoida: pushdan oldin uzoq branch bilan sinxronlashing. Birlashishda merge commitdan qochish uchun git pull --rebase-ni bajaring. Bu tarixni soddalashtiradi va uni chiziqli qiladi. Agar push rad etilsa — yalang'och force push ishlatmang, avval uzoq branchda qanday commit-lar paydo bo'lganini tekshiring.

Uchinchi qoida: yuborishdan oldin avtomatik testlar va linter-ni ishga tushiruvchi pre-push hook-larni sozlang. Agar testlar muvaffaqiyatsiz bo'lsa — push bloklanadi. Bunday hook-lar Husky yoki Git hooks (pre-push fayli .git/hooksda) orqali sozlanadi.

To'rtinchi qoida: katta ikkilik fayllarni push qilmang. Git ikkilik artefaktlarni saqlash uchun mo'ljallanmagan — ular repozitoriyani shishirib, operatsiyalarni sekinlashtiradi. Katta fayllar uchun Git LFS (Large File Storage) ishlatiladi. Agar ikkilik fayl allaqachon push qilingan va tarixga tushgan bo'lsa, uni git filter-branch orqali olib tashlash kerak.

Push o'tmasa nima qilish kerak

Muvaffaqiyatsiz pushning eng keng tarqalgan sababi — uzoq branchda lokalda mavjud bo'lmagan commit-larning borligi. Bu boshqa dasturchi o'z o'zgarishlarini xuddi shu branchga push qilganda sodir bo'ladi. Yechim: git pull-ni bajarish, mumkin bo'lgan konfliktlarni hal qilish va push-ni takrorlash.

# Push rad etildi — avval fetch va rebase qil
git fetch origin
git rebase origin/main
# Konfliktlarni hal qil, keyin:
git push --force-with-lease

# Yoki oddiygina uzoq o'zgarishlarni birlashtir
git pull origin main
git push

Ikkinchi sabab — branchga yozish huquqining yo'qligi. Agar main branch branch protection qoidasi bilan himoyalangan bo'lsa, to'g'ridan-to'g'ri push-lar taqiqlangan. Yechim: feature branchga push qilish va Pull Request yaratish. Himoya sozlamalari odatda GitHub settings yoki GitLab protected branches orqali boshqariladi.

Uchinchi sabab — autentifikatsiya muammolari. Eski credentials, SSHga o'tish yoki personal access tokenning o'zgarishi. Yechim: remote URL-ni tekshirish (git remote -v) va credentials-ni yangilash. 2021-yildan boshlab GitHub HTTPS uchun parol bilan autentifikatsiyani bekor qildi — shaxsiy token yoki SSH kaliti ishlatiladi.