Rebase: bu nima, Merge-dan nimasi bilan farq qiladi va ishlash prinsipi

Rebase nima?

Rebase (bazani o'zgartirish) — joriy filialdan commitlarni yangi tayanch nuqtasiga (bazaga) ko'chiradigan Git operatsiyasidir. Birlashtiruvchi commit yaratish o'rniga, rebase har bir commitni manba filialdan olib, navbat bilan yangi baza ustiga qo'llaydi. Natijada tarmoqlanmasdan chiziqli commitlar ketma-ketligi hosil bo'ladi.

Rebase nomi „re-base" — bazani o'zgartirish ma'nosidan keladi. Agar merge ikki filialni bir nuqtada birlashtirsa, rebase butun filialingizni yangi joyga ko'chiradi, go'yo ishni maqsadli filialning joriy holatidan boshlagandek tuyuladi. Bu ideal ketma-ket ish taassurotini yaratadi.

Atlassian, 2025 ma'lumotlariga ko'ra, feature filiallari uchun rebase ishlatadigan jamoalar commit tarixini tahlil qilishga faqat merge ishlatadigan jamoalarga nisbatan 30% kam vaqt sarflashadi. Chiziqli tarix git blame, bisect va git log --oneline orqali jurnalni ko'rishni soddalashtiradi.

Merge-dan asosiy farq

Merge ikkita ota-onaga ega commit yaratib filiallarni birlashtiradi. Rebase tarixni qayta yozadi: yangi commitlar asl o'zgarishlar bilan bir xil bo'lsa-da, yangi hashlar bilan qaytadan yaratiladi. Bu rebase commitlarning SHA identifikatorlarini o'zgartiradi, bu ommaviy filiallar uchun juda muhimdir.

Rebase qanday ishlaydi

Rebase mexanizmi to'rt qadamdan iborat: Git joriy va maqsadli filialning umumiy ajdodini (merge base) aniqlaydi, so'ngra joriy filialning har bir commitini ketma-ket maqsadli filial ustiga qo'llaydi. Agar biror qadamda ziddiyat yuzaga kelsa — rebase to'xtaydi va yechimni kutadi.

# Boshlang'ich holat: feature develop-dan 3 commit orqada
git checkout feature/new-login
git rebase develop

# Git feature-dan 3 commitni oladi va ularni develop ustiga qo'llaydi
# Ziddiyatlar bo'lmasa — rebase avtomatik yakunlanadi
# Bo'lsa — Git ziddiyatli commitda to'xtaydi

Rebase-dan so'ng feature filiali develop-dan barcha commitlarni va o'z commitlarini o'z ichiga oladi, ular develop-ning davomi kabi ko'rinadi. Bu birlashtiruvchi commit yaratmasdan develop-ga fast-forward orqali qo'shilish imkonini beradi.

Bosqichma-bosqich jarayon

Batafsil misolni ko'rib chiqaylik: dasturchi develop-dan feature filialini yaratdi, ikkita commit qildi, bu vaqtda boshqa dasturchilar develop-ga uchta commit qo'shdilar. Rebase feature-ning ikkita commitini yangi joyga ko'chiradi, ularning yangi SHA bilan nusxalarini yaratadi.

# 1. Feature filialini yaratish
git checkout -b feature/payment-refactor develop

# 2. Feature-da commitlar qilish
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Develop-ni yangilash (hamkasblar ishi)
git checkout develop
git pull

# 4. Feature-ni yangi develop ustiga rebase qilish
git checkout feature/payment-refactor
git rebase develop

# 5. Endi feature fast-forward orqali birlashtirilishi mumkin
git checkout develop
git merge feature/payment-refactor

4-qadamda ziddiyat yuzaga kelsa, Git muammoli commitda to'xtaydi. Dasturchi ziddiyatni hal qiladi, git add qiladi va git rebase --continue ni bajaradi. Agar commitni o'tkazib yuborish kerak bo'lsa — git rebase --skip, butun rebase-ni bekor qilish uchun — git rebase --abort.

Bo'sh commitlarni avtomatik o'tkazib yuborish

--empty bayrog'i bo'sh commitlarda rebase xatti-harakatini boshqaradi — commitning barcha o'zgarishlari allaqachon maqsadli filialda mavjud bo'lgan holatlar. Odatiy bo'lib, rebase to'xtaydi va qaror so'raydi. --empty=drop bayrog'i bilan Git bunday commitlarni to'xtamasdan avtomatik o'tkazib yuboradi, bu ko'p sonli commitlar bilan ommaviy bazani o'zgartirishni tezlashtiradi.

Interaktiv Rebase

Interactive rebase (git rebase -i) — commit tarixini tahrirlash uchun kuchli vositadir. U commitlar ro'yxati va asosiy buyruqlar bilan muharrir ochadi: pick (saqlash), reword (xabarni o'zgartirish), edit (mazmunni o'zgartirish), squash (oldingisi bilan birlashtirish), fixup (xabarsiz birlashtirish), drop (o'chirish).

# Oxirgi 4 commitning interaktiv rebase-i
git rebase -i HEAD~4

# Muharrirda rebase rejasi ochiladi:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# O'zgartiramiz:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Natija: uchta commit (kirish ekrani, validatsiya, tartib) bittaga siqildi, sharhlar bilan commit o'chirildi. Bu kod tekshiruviga qoralama va tuzatishlarsiz toza tarixni taqdim etish imkonini beradi. Interactive rebase — Pull Request-dan oldin feature filialini tayyorlash uchun standart vositadir.

Rebase vs Merge: taqqoslash

Rebase va Merge bir vazifani — o'zgarishlarni integratsiyalashni — hal qiladi, lekin tubdan farqli usullar bilan. Ularning o'rtasida tanlov git log-da qanday tarixni ko'rishni xohlayotganingizga va filialingiz bilan kim ishlayotganiga bog'liq.

Amaliy qoida: umumiy filiallarga (develop, main) integratsiya uchun merge, shaxsiy feature filiallarini joriy holatga keltirish uchun rebase dan foydalaning. Ko'p jamoalar birlashtiradi: feature-ni develop-ga rebase, keyin develop-ga --no-ff merge.

git bisect ga ta'siri

Git bisect — regressiyaga sabab bo'lgan commitni topish uchun vositadir. Merge ishlatilganda, git bisect ikkala ota-onani hisobga olgan holda birlashtiruvchi commitlardan to'g'ri o'tadi. Rebase-da bisect tezroq ishlaydi, chunki tarix chiziqli va tarmoqlanishni talab qilmaydi. Biroq rebase commitlar jamoaga ma'lum bo'lgandan keyin qilingan bo'lsa, asl SHA yo'qoladi va bisect muammoli commitni topa olmasligi mumkin.

Rebase qachon qo'llaniladi

Rebase uchta stsenariyda optimaldir: feature filialini Pull Request-ga tayyorlash, shaxsiy filialni main/develop ning joriy holatiga yangilash va birlashishdan oldin tarixni tozalash. Har bir holatda rebase jamoa ishi uchun xavf tug'dirmasdan tarixning o'qilishini yaxshilaydi.

Pull Request oldidan ishchi commitlarni (WIP, tekshiruvdan keyingi tuzatishlar) mazmunli mantiqiy birliklarga birlashtirish uchun interactive rebase bajarish tavsiya etiladi. Bu kod tekshiruvini osonlashtiradi: tekshiruvchi 15 mayda commitni emas, balki tushunarli xabarlar bilan 3-5 tuzilgan o'zgarishlarni ko'radi.

Feature filialini yangilash uchun rebase merge-dan afzal, chunki u keraksiz birlashtiruvchi commitlarni yaratmaydi. Feature filialida vaqti-vaqti bilan git rebase develop qilsangiz, yakuniy birlashishdan keyin 10 ta birlashtiruvchi commit kaskadi bo'lmaydi — faqat develop ustida toza funksiya commitlari.

Tarixni tozalash birlashishdan oldin interactive rebase orqali kichik tuzatishlarni (matn xatolari, formatlash) yashirish va commitlarni funksionallik bo'yicha guruhlash imkonini beradi. Git xabarlari Conventional Commits (fix:, feat:, refactor:, docs:) kelishuviga mos kelishi kerak, bu avtomatik changelog yaratadi.

Rebase xavflari va qoidalari

Rebase — noto'g'ri qo'llanilsa xavfli operatsiya. Asosiy xavf — nashr etilgan tarixni qayta yozish. Agar dasturchi boshqalar allaqachon push qilgan va ishlatayotgan filialni rebase qilsa, ularning mahalliy nusxalari desinxronlashadi va ma'lumot yo'qotish xavfi bilan force-pull qilishga majbur bo'ladilar.

• Oltin qoida: umumiy omborda allaqachon mavjud commitlarni hech qachon rebase qilmang. Bu jamoa a'zolari kirish huquqiga ega bo'lgan har qanday filiallarga tegishli
• Force push: mahalliy feature filialining rebase-dan so'ng --force-with-lease bayrog'i bilan push talab qilinadi, bu --force-dan xavfsizroq, chunki serverda filialni kimdir yangilaganligini tekshiradi
• Kontekst yo'qolishi: rebase feature filiali qachon va qaysi filialdan yaratilganligi haqidagi ma'lumotni yo'q qiladi. Filialning yaratilish sanalarini saqlash muhim bo'lsa — merge dan foydalaning
• Ziddiyatlar: rebase paytida ziddiyatlar har bir commit uchun alohida hal qilinishi kerak, bu ko'p sonli commitlar bilan zerikarli bo'lishi mumkin

Xavflarni kamaytirish uchun qoidaga rioya qiling: rebase faqat nashr etilmagan shaxsiy filiallar uchun. Agar filial allaqachon umumiy omborda bo'lsa — --no-ff bilan merge dan foydalaning. Nashr etilgan filialni rebase qilish zarur bo'lsa — jamoani ogohlantiring va force push-ni oldindan kelishib oling.

Xavfli rebase-dan avtomatik himoya server-side hooks orqali amalga oshiriladi: Git server tomonidagi pre-receive hook push nashr etilgan commitlarni qayta yozayotganligini tekshirishi mumkin. GitHub va GitLab himoyalangan filiallar uchun o'rnatilgan himoyani ta'minlaydi — administrator himoyani olib tashlamasa, force push bloklanadi.