Filiallarni birlashtirish — bu nima, birlashtirish usullari va nizolarni hal qilish

Git-da merge nima

Git-da merge — ikki yoki undan ortiq rivojlanish tarixini bittaga birlashtirish operatsiyasidir. Dasturchi filialni birlashtirganda, Git avtomatik ravishda umumiy ajdodni (base commit) topadi va ikkala filialdagi o‘zgarishlarni o‘z ichiga olgan yangi merge commit yaratadi. Three-way merge — uchta holatni taqqoslaydigan standart algoritm: umumiy ajdod, birinchi filial va ikkinchi filial.

Merge jarayoni git merge buyrug‘i bilan boshlanadi. Git filiallarning ajralish nuqtasini aniqlaydi va o‘zgarishlarni manba filialdan maqsadli filialga ketma-ket qo‘llaydi. Agar o‘zgarishlar ziddiyatli bo‘lmasa, Git sozlamalarga qarab fast-forward ni bajaradi yoki merge commit yaratadi. Fast-forward — maqsadli filial shunchaki manba filialning commit-lariga suriladigan stsenariydir.

# Maqsadli filialga o‘t va birlashtir
git checkout main
git merge feature/payment-module

# Aniq no-fast-forward bilan birlashtir
git merge --no-ff feature/payment-module

# Agar nizolar juda murakkab bo‘lsa, birlashtirishni bekor qil
git merge --abort

--no-ff (no fast-forward) bayrog‘i fast-forward mumkin bo‘lsa ham, majburiy ravishda merge commit yaratadi. Bu o‘zgarishlarning alohida filialda qilinganligi haqidagi ma’lumotni saqlaydi. Ko‘plab jamoalar tarixning tarmoqlanishini aniq shaklda saqlash uchun aynan shu yondashuvni afzal ko‘radi.

Filiallarni birlashtirish usullari

Git-da filiallarni birlashtirishning uchta asosiy strategiyasi mavjud, ularning har biri muayyan stsenariy uchun mos keladi. Strategiyani tanlash jamoaning madaniyati va loyiha tarixining tozaligiga bo‘lgan talablarga bog‘liq.

Standard merge ikkita ota-onaga ega merge commit yaratadi. To‘liq tarix saqlanadi, biroq tarmoqlanish grafi murakkablashadi. Squash merge feature filialining barcha commit-larini bittaga birlashtiradi va uni maqsadli filialga qo‘llaydi — tarix chiziqli va toza bo‘ladi, ammo oraliq bosqichlar haqidagi ma’lumot yo‘qoladi.

Rebase, to‘liq merge bo‘lmasa-da, xuddi shu natijaga erishadi — bir filialdagi o‘zgarishlar boshqasiga ko‘chiriladi. Farq shundaki, tarix qayta yoziladi: feature filialining commit-lari maqsadli filialning oxirgi commit-i ustida qayta yaratiladi. Bu ideal chiziqli tarixni beradi, ammo jo‘natishda force push talab qiladi.

Merge paytida nizolarni qanday hal qilish

Merge paytida nizo ikki filialda faylning bir xil satrlari o‘zgartirilganda yuzaga keladi. Git qaysi variantni saqlashni avtomatik aniqlay olmaydi va dasturchining aralashuvini talab qiladi. Nizolar fayllarda maxsus markerlar ko‘rinishida ko‘rsatiladi: <<<<<<<, =======, >>>>>>>.

Nizoni hal qilish jarayoni bir necha bosqichlarni o‘z ichiga oladi. Avval dasturchi nizoli faylni ochadi va kerakli o‘zgarishlarni qo‘lda tanlaydi. Faqat versiyalardan birini tanlash emas, balki ikkala o‘zgarishning mantiqini tushunish va to‘g‘ri qaror qabul qilish muhimdir. Faylni tahrir qilgandan so‘ng, nizo markerlari o‘chiriladi va o‘zgarishlar git add orqali staging area-ga qo‘shiladi.

# Nizoli fayllar ro‘yxatini ko‘rish
git status

# Mergetool-ni ishga tushir (masalan, VS Code, IntelliJ)
git mergetool

# Barcha nizolarni hal qilgandan so‘ng
git add .
git merge --continue

# Yoki birlashtirishni butunlay bekor qil
git merge --abort

Vizual merge vositalaridan foydalanish nizolarni hal qilishni sezilarli darajada tezlashtiradi. VS Code, IntelliJ IDEA va GitKraken uch panelli interfeyslarni taqdim etadi: joriy filial, kiruvchi filial va natija. Git mergetool vositasi har bir nizoli fayl uchun sozlangan muharrirni avtomatik ravishda ochadi.

Murakkab nizolarning oldini olishning eng yaxshi usuli — feature filialini asosiy filial bilan muntazam sinxronlashtirish. Agar dasturchi har kuni main ni o‘z filialiga birlashtirsa, nizolar kichik va oson hal qilinadigan bo‘ladi. O‘zgarishlarning bir hafta davomida to‘planishi murakkab nizolarni va yuqori xato xavfini kafolatlaydi.

Qachon merge o‘rniga rebase ishlatish kerak

Rebase va merge — o‘zgarishlarni birlashtirishning ikki usuli bo‘lib, ular orasidagi tanlov ko‘pincha jamoalarda bahslarga sabab bo‘ladi. Rebase commit-larni bir filialdan ikkinchisiga ko‘chirib, tarixni qayta yozadi. Merge birlashtirish tarixini saqlab, yangi merge commit yaratadi. Har bir yondashuvning o‘z afzalliklari va cheklovlari bor.

Rebase dasturchi o‘zining lokal feature filialida ishlayotganda va Pull Request yaratishdan oldin toza chiziqli tarix olishni xohlaganda mos keladi. Rebase-dan so‘ng barcha commit-lar ketma-ket joylashadi, keraksiz merge commit-larsiz. Biroq rebase force push talab qiladi va bir vaqtning o‘zida bir necha kishi ishlaydigan filiallarda qo‘llanilmaydi.

• Rebase — toza tarix kerak bo‘lgan shaxsiy feature filiallari uchun
• Merge — umumiy filiallar va birlashtirish momentini qayd etish uchun
• Squash — feature filialida ko‘plab kichik ishchi commit-lar bo‘lganda

Git-ning oltin qoidasi: umumiy repozitoriyga yuborilgan commit-larda rebase ishlatmang. Bu umumiy filialda tarixning o‘zgarishsiz qolishini kafolatlaydi va boshqa dasturchilar takroriy yoki yo‘qolgan commit-larga duch kelmaydi. Feature filialini asosiy filialga integratsiya qilish uchun Pull Request orqali merge dan foydalaning.

Filiallarni birlashtirish bo‘yicha eng yaxshi amaliyotlar

To‘g‘ri merge jarayoni — barqaror dasturlashning asosidir. Zamonaviy jamoaviy ishda merge konsol orqali emas, balki GitHub-da Pull Request yoki GitLab-da Merge Request orqali amalga oshiriladi. PR kod ko‘rib chiqish, avtomatik CI tekshiruvlaridan o‘tadi va faqat shundan so‘ng asosiy filialga birlashtiriladi.

Birinchi amaliyot — faqat barcha tekshiruvlardan o‘tgandan so‘ng birlashtiring. CI pipeline loyihani yig‘ishi, testlarni ishga tushirishi va kod sifatini tekshirishi kerak. Agar biron bir tekshiruv o‘tmagan bo‘lsa, merge bloklanadi. Zamonaviy platformalar (GitHub, GitLab) o‘rnatilgan himoyaga ega: branch protection rules CI muvaffaqiyatsiz bo‘lganda merge-ni avtomatik bloklaydi.

Ikkinchi amaliyot — hech qachon buzilgan kodni birlashtirmang. Merge-dan oldin dasturchi o‘z o‘zgarishlari build-ni buzmasligiga va mavjud funksionallikni regressiya qilmasligiga ishonch hosil qilishi kerak. Buning uchun avtomatik testlar va code review mavjud.

Uchinchi amaliyot — merge-dan so‘ng feature filiallarini tozalang. Birlashtirilgan filial o‘chirilishi kerak. Bu chalkashlikning oldini oladi va repozitoriyning ifloslanishiga yo‘l qo‘ymaydi. GitHub PR merge-dan so‘ng filialni o‘chirishni avtomatik taklif qiladi va repozitoriy sozlamalari avtomatik o‘chirishga moslashtirilishi mumkin.