Rebase: nima, qanday ishlaydi va Git bilan ishlash

Git-da rebase nima

Rebase — bu Git buyrug‘i bo‘lib, joriy tarmoqni ko‘rsatilgan bazaga qayta bazalaydi: joriy tarmoqning barcha commit-larini oladi, ularni vaqtincha saqlaydi, tarmoq ko‘rsatkichini maqsadli commit-ga olib boradi va saqlangan commit-larni ketma-ket uning ustiga qo‘llaydi. Natija — tarix dasturchi to‘g‘ridan-to‘g‘ri maqsadli tarmoqning oxirgi commit-idan ishlagandek ko‘rinadi.

Asosiy sintaksis: git rebase main — feature tarmog‘ida bo‘lganingizda, bu buyruq barcha feature commit-larini main tepasiga ko‘chiradi. Git har bir commit uchun alohida three-way merge strategiyasidan foydalanadi. Agar commit A maqsadli tarmoqda allaqachon mavjud bo‘lsa (hash bilan aniqlanadi), Git uni avtomatik ravishda o‘tkazib yuboradi, bu esa o‘zgarishlarning takrorlanishini oldini oladi.

Rebase shuningdek commit-larning bir qismini ko‘chirish uchun onto rejimini qo‘llab-quvvatlaydi: git rebase --onto target start end — bu shakl bir tarmoqdan commit diapazonini ajratib olish va ularni boshqasining ustiga qo‘llash imkonini beradi. Masalan, git rebase --onto main feature~3 feature feature tarmog‘ining oxirgi uchta commit-ni main tepasiga ko‘chiradi.

# Feature tarmog'iga o'tish
git checkout feature

# Feature-ni main-ga qayta bazalash
git rebase main

# Muvaffaqiyatli rebase-dan so'ng — tarix chiziqli
git log --oneline --graph

# Oxirgi 3 commit-ni main-ga ko'chirish
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: asosiy farqlar

Rebase va merge bir xil vazifani hal qiladi — turli tarmoqlardan o‘zgarishlarni birlashtirish — lekin buni tubdan farqli usullar bilan amalga oshiradi. Merge ikkita ota-onaga ega merge-commit yaratib, to‘liq birlashma tarixini saqlaydi. Rebase tarixni qayta yozib, uni chiziqli qiladi. Ularning orasidagi tanlov jamoaning ish jarayoni va repozitoriy bilan ishlash qoidalariga bog‘liq.

Asosiy farq — birlashma faktining qanday qayd etilishi. Merge saqlaydi: “bu nuqtada biz feature-ni main-ga birlashtirdik” — bu loyiha tarixi uchun ma’lumotlidir, lekin tez-tez birlashtirishlarda jurnalni ifloslantiradi. Rebase ko‘rsatadi: “feature commit-lari main-ning oxirgi holatidan ketma-ket qilindi” — bu toza, lekin ishning parallel olib borilgan faktini yashiradi.

Ikkinchi farq — mojarolarni qayta ishlash. Merge-da mojarolar bir marta hal qilinadi va yechim merge-commit-da qayd etiladi. Rebase-da mojarolar har bir ko‘chirilgan commit uchun yuzaga kelishi mumkin va har biri alohida hal qilishni talab qiladi. Bu ko‘proq mehnat talab qiladi, lekin yakuniy versiyaga qanday o‘zgarishlar kirishini aniqroq nazorat qilish imkonini beradi.

Interaktiv rebase: buyruqlar va bayroqlar

Interaktiv rebase (git rebase -i) — bu Git commit-lar ro‘yxati va har biri uchun mavjud harakatlar bilan muharrirni ochadigan rejimdir. Dasturchi uzoq repozitoriyga yuborishdan oldin tarixni qayta yozishi mumkin. Bu feature tarmog‘ida commit-larning tozaligini saqlash uchun asosiy vositadir.

Interaktiv rejimdagi mavjud buyruqlar: pick (commit-ni avvalgidek qoldir), reword (commit xabarini o‘zgartir), edit (o‘zgartirishlar uchun to‘xta), squash (oldingi commit bilan birlashtir, ikkala xabarni saqla), fixup (xabarni tashlab birlashtir), drop (commit-ni o‘chir). Har bir buyruq ochilgan muharrirda commit hash-idan oldin ko‘rsatiladi.

Squash va fixup — commit-larni birlashtirish uchun eng ko‘p ishlatiladigan buyruqlar. Agar dasturchi ish jarayonida 5 ta kichik tuzatish commit-larini qilgan bo‘lsa, squash ularni mazmunli xabar bilan bitta mantiqiy commit-ga birlashtiradi. Fixup matn xatolarini tuzatish uchun foydali: o‘zgarishlar o‘z xabarini saqlamasdan oldingi commit-ga qo‘shiladi.

# Oxirgi 4 commit uchun muharrirni ochish
git rebase -i HEAD~4

# Muharrir ko'rsatadi:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Saqlagandan so'ng — Git rebase-ni bajaradi
# va birlashtirilgan commit xabari uchun muharrirni ochadi

# Muharrirni ochmasdan auto-squash
git rebase -i HEAD~4 --autosquash

--autosquash bayrog‘i xabarlari fixup! yoki squash! bilan boshlanadigan commit-lar uchun avtomatik fixup/squash o‘rnatadi. Bu dasturchi oldindan commit-larni keyingi birlashtirish uchun belgilab qo‘ysa, ishni tezlashtiradi. --committer-date-is-author-date bayrog‘i qayta bazalashda commit-ning asl sanasini saqlaydi — tarixda xronologiyani saqlash uchun foydali.

Rebase paytida mojarolarni hal qilish

Rebase paytida mojarolar Git maqsadli tarmoqdagi o‘zgarishlar bilan ziddiyat tufayli ko‘chirilgan commit-ni avtomatik qo‘llay olmaganda yuzaga keladi. Merge-dan farqli o‘laroq, mojaro bir marta hal qilinadi, rebase-da esa har bir commit mojaroga sabab bo‘lishi mumkin va uni eng eskisidan eng yangisigacha ketma-ket hal qilish kerak.

Mojaro yuzaga kelganda, Git rebase-ni to‘xtatadi va qaysi commit muammo keltirib chiqarganini xabar qiladi. Dasturchi mojaroli faylni ochadi (Git mojaro joylarini <<<<<<<, =======, >>>>>>> belgilari bilan belgilaydi), uni tahrir qiladi, indeksga qo‘shadi (git add) va git rebase --continue buyrug‘i bilan rebase-ni davom ettiradi. Agar yechim topilmasa — git rebase --abort rebase-ni butunlay bekor qiladi.

Maslahat: ko‘p sonli mojarolarda qarama-qarshiliklarni hal qilish uchun vizual muharrirni ochadigan git mergetool-dan foydalanish samaraliroq. Shuningdek, muammoli commit-ni o‘tkazib yuborish mumkin (git rebase --skip), lekin bu uning o‘zgarishlarini yakuniy tarixdan olib tashlaydi, bu kamdan-kam hollarda to‘g‘ri yechim bo‘ladi.

# Mojaro bilan rebase-ni boshlash
git rebase main
# Auto-merging file.txt
# MOJARO (mazmun): file.txt-da birlashma mojarosi

# Holatni tekshirish
git status
# ikkalasi o'zgartirilgan: file.txt

# Mojaroli qismlarni tahrirlash → git add → davom etish
git add file.txt
git rebase --continue

# Shubha bo'lsa — bekor qilish
git rebase --abort

Qachon rebase qilmaslik kerak

Rebase-ning oltin qoidasi: uzoq repozitoriyga allaqachon yuborilgan va boshqa dasturchilar uchun mavjud bo‘lgan commit-larni hech qachon qayta bazalamang. Rebase commit hash-larini qayta yozganligi sababli, hamkasblar sinxronlashga urinishda mojarolarga duch kelishadi — ularning mahalliy tarixi qayta yozilgan uzoq tarix bilan mos kelmaydi.

Rebase qat‘iy taqiqlangan vaziyat: agar kimdir sizning commit-laringiz asosida tarmoq yaratgan bo‘lsa (masalan, hamkasbingiz sizning feature-ingizdan feature yaratgan bo‘lsa), tarixni o‘zgartirish uning ishini buzadi. Bunday hollarda merge-dan foydalanish kerak. Shuningdek, muddatdan oldin rebase qilish tavsiya etilmaydi — mojarolarni hal qilishdagi xato kutilganidan ko‘proq vaqt olishi va nashrni bloklashi mumkin.

Istisno: agar tarmoq faqat bitta dasturchi tomonidan ishlatilsa (shaxsiy feature tarmog‘i, nashr etilmagan yoki draft rejimida nashr etilgan), push-dan oldin rebase standart amaliyotdir. Nashrdan va jamoaviy ish boshlanganidan keyin — faqat merge. GitHub va GitLab sukut bo‘yicha squash merge-ni murosali yechim sifatida taklif qiladi: commit-larni bittaga birlashtiradi, lekin maqsadli tarmoq tarixini qayta yozmaydi.

• Ommaviy tarmoqlar (main, develop, release) — rebase butunlay taqiqlangan.
• Boshqalarning commit-lari — agar tarmoq boshqa dasturchining commit-larini o‘z ichiga olsa, rebase joiz emas.
• Nashrdan oldin — mojaro xavfi yuqoriroq: merge muddatdan bir kun oldin xavfsizroq.
• Tegli tarmoqlar — teg bilan commit-ni ko‘chirish semantik versiyalash konvensiyalarini buzadi.
• CI/CD hash-larga bog‘liq — ba‘zi joylashtirish tizimlari build-larni commit hash-i bilan aniqlaydi; rebase kuzatishni buzadi.

Rebase bilan amaliy ish jarayoni

Zamonaviy jamoalarda ko‘pincha rebase-ga yo‘naltirilgan ish jarayoni GitHub Flow bilan birgalikda qo‘llaniladi. Jarayon quyidagicha ko‘rinadi: dasturchi main-dan feature tarmog‘ini yaratadi, unda ishlaydi, vaqti-vaqti bilan git rebase main orqali sinxronlanadi va pull request yaratishdan oldin tarixni tozalash uchun interaktiv rebase qiladi.

PR yaratgandan so‘ng (main-dan yangi o‘zgarishlarni olish kerak bo‘lsa) oddiy git pull o‘rniga git pull --rebase main ishlatiladi. Bu keraksiz merge-commit yaratmasdan o‘zgarishlarni olish imkonini beradi. --rebase bayrog‘i bilan git pull git fetch + git rebase-ga teng — Git avval yangi commit-larni yuklaydi, so‘ngra mahalliy o‘zgarishlarni ularning ustiga qayta bazalaydi.

Git pull uchun rebase-ni standart xatti-harakat sifatida sozlash imkonini beradi: git config --global pull.rebase true. Ushbu konfiguratsiyadan so‘ng git pull har doim merge o‘rniga rebase qiladi. Agar oddiy pull kerak bo‘lsa — git pull --no-rebase ishlatiladi. Ko‘plab jamoalar autostash-ni ham yoqadi: git config --global rebase.autoStash true — bu rebase-dan oldin tasdiqlanmagan o‘zgarishlarni avtomatik yashiradi va keyin tiklaydi.