Git merge yoki rebase: farqlari va qachon nimani ishlatish kerak

Qisqa javob

merge ham, rebase ham bitta vazifani hal qiladi — bir branchdagi o‘zgarishlarni boshqasiga o‘tkazadi. Farq shundaki, keyin tarix qanday ko‘rinishda bo‘ladi:

• Merge haqiqiy tarixni saqlaydi va alohida birlashtirish commitini qo‘shadi.
• Rebase commitlaringizni boshqa branch ustiga qaytadan qo‘llaydi, tarix to‘g‘ri chiziqqa aylanadi.
• Squash merge branchdagi barcha commitlarni bittaga jamlab, asosiy branchga qo‘shadi.

Asosiy qoida: boshqalar allaqachon foydalanayotgan branchlarni rebase qilmang.

Tarix qanday ko‘rinadi

Boshlang‘ich holat: siz main dan feature branchini ochdingiz va D hamda E commitlarini qildingiz, bu orada main da B va C commitlari paydo bo‘ldi.

          D---E  feature
         /
    A---B---C  main

Merge dan keyin

git switch main
git merge feature

          D---E
         /     \
    A---B---C---M  main

Ikki ota-onali M birlashtirish commiti paydo bo‘ladi. Ish parallel borgani ko‘rinib turadi, mavjud commitlarning hech biri o‘zgarmagan.

Squash merge dan keyin

git switch main
git merge --squash feature
git commit -m "Add feature"

    A---B---C---S  main

Branchdagi barcha o‘zgarishlar bitta S commitiga jamlangan. main tarixi toza, lekin branchning oraliq qadamlari unda ko‘rinmaydi.

Rebase dan keyin

git switch feature
git rebase main

                  D'--E'  feature
                 /
    A---B---C  main

D va E commitlari C ustida D' va E' sifatida yangi heshlar bilan qayta yaratilgan. Endi main ga git merge feature oddiy fast-forward bo‘ladi va tarix chiziqli qoladi.

Taqqoslash

Rebase ning oltin qoidasi

Yuborilgan va boshqalar tayanayotgan commitlarni rebase qilmang.

Rebase eski commitlar o‘rniga yangilarini yaratadi. Agar hamkasbingiz o‘z ishini eski commitlar ustiga qurgan bo‘lsa, sizning push --force dan keyin tarixlaringiz ajralib ketadi: dublikatlar, konfliktlar va chalkashlik paydo bo‘ladi.

Rebase xavfsiz bo‘lgan holatlar:

• yuborishdan oldin o‘z lokal branchingiz;
• boshqa hech kim ishlamaydigan shaxsiy branchingiz;
• yangilashda ortiqcha birlashtirish commitlari yaratmaslik uchun git pull --rebase.

Agar yuborilgan shaxsiy branchni baribir qayta yozishga to‘g‘ri kelsa, git push --force-with-lease dan foydalaning — serverda boshqalarning commitlari paydo bo‘lgan bo‘lsa, u rad etadi.

Qachon nimani ishlatish kerak

• Merge — umumiy uzoq yashaydigan branchlarni birlashtirish uchun (develop ni main ga, reliz branchlari) va aniq xronologiya muhim bo‘lganda.
• Squash merge — «fix typo» kabi ko‘plab mayda commitli pull requestlar uchun: main ga bitta mazmunli yozuv tushadi.
• Rebase — pull requestdan oldin branchingizni yangi main bilan yangilash va lokal commitlarni tartibga keltirish uchun (git rebase -i).

Jamoa uchun siyosat

Ko‘pchilik jamoalar uchun ishlaydigan oddiy sxema:

1. Har bir vazifa — main dan ochilgan alohida, qisqa muddatli branch.
2. Pull request ochishdan oldin dasturchi branchni git rebase main orqali yangilaydi (branch uning shaxsiy branchi, bu xavfsiz).
3. O‘zgarishlar main ga squash merge yoki oddiy merge orqali tushadi — bittasini tanlang va repozitoriy sozlamalarida mustahkamlang.
4. main va boshqa umumiy branchlarga force push branch himoyasi orqali taqiqlanadi.
5. Dasturchilar Git konfiguratsiyasida pull.rebase = true ni yoqishlari mumkin, shunda lokal yangilanishlar birlashtirish commitlarini ko‘paytirmaydi.

Aniq tanlov bir xillikdan kamroq muhim: aralash yondashuvlar tarixni ularning har biridan ko‘ra o‘qishni qiyinlashtiradi.