Git-da Branch-lar orasidagi Merge Conflict-larni hal qilish

Bu — seriyaning eng murakkab mavzularidan biri: merge conflict (birlashtirish ziddiyati). Bu branch asosiy kod bazasiga birlashtirilayotganda, ikki versiya o'rtasida ziddiyat yuzaga kelganda sodir bo'ladi. Bunday holatda Source Control qaysi o'zgarish to'g'ri ekanini avtomatik bilmaydi — bu qaror dasturchi tomonidan qo'lda qabul qilinishi kerak.

Merge conflict qachon yuzaga keladi?

Conflict odatda quyidagi vaziyatda paydo bo'ladi: ikki dasturchi bir xil koddan yangi branch ochadi, ikkalasi ham bir xil qatorni o'zgartiradi, va birinchisi o'z o'zgarishini asosiy branch-ga birlashtirgandan so'ng, ikkinchisi o'z branch-ini birlashtirmoqchi bo'lganda — Git ikki versiya o'rtasidagi farqni avtomatik hal qila olmaydi.

Oddiy misol — bitta qatordagi conflict

Tasavvur qiling, ikkita dasturchi bir xil ekranni o'zgartirmoqchi:

// Boshlang'ich kod
Image(systemName: "heart.fill")

1-dasturchi o'z branch-ida:

Image(systemName: "house.fill")

2-dasturchi o'z branch-ida (xuddi shu boshlang'ich koddan, lekin alohida):

Image(systemName: "bolt.fill")

1-dasturchi o'z branch-ini avval birlashtiradi — muammosiz o'tadi. 2-dasturchi keyin o'z branch-ini birlashtirmoqchi bo'lganda — endi asosiy branch-da allaqachon house.fill bor, lekin 2-dasturchi branch-i bu o'zgarishdan bexabar, chunki u eski versiyadan ochilgan edi. Shu sababli Git conflict signali beradi.

Conflict-ni Xcode orqali hal qilish

Merge bosilganda, agar conflict bo'lsa, Xcode maxsus hal qilish ekranini ko'rsatadi. Bu yerda ikki versiya yonma-yon ko'rsatiladi va quyidagi tanlovlar mavjud:

Choose Left   — faqat asosiy branch versiyasini olish
Choose Right  — faqat yangi branch versiyasini olish
Left then Right — ikkalasini ham, avval chap keyin o'ng
Right then Left — ikkalasini ham, avval o'ng keyin chap

Misolda faqat bittasi to'g'ri kerak bo'lganda — Choose Right (yoki Choose Left) tanlanadi. Ikkalasini ham qo'shish — odatda noto'g'ri natijaga olib keladi, chunki ikkala o'zgarish ham bir xil qatorga tegishli.

GitKraken orqali hal qilish

GitKraken-da conflict hal qilish jarayoni yanada vizual: chap va o'ng versiyalar alohida ko'rsatiladi, har birini alohida belgilash mumkin, natija pastda darhol ko'rinadi. Ko'p dasturchilar GitKraken-ning bu ko'rinishini Xcode-nikidan qulayroq deb hisoblaydi.

Conflict hal qilingandan keyin

Barcha conflict-lar hal qilingach, Merge tugmasi bosiladi va branch asosiy kod bazasiga muvaffaqiyatli birlashtiriladi. Shundan so'ng, yangilangan asosiy branch GitHub-ga push qilinishi va endi keraksiz bo'lgan branch-lar o'chirilishi tavsiya etiladi.

Branch nomlash — Jira ticket konventsiyasi

Jamoaviy ishlashda, har bir vazifa odatda Jira kabi tizimda ticket sifatida rasmiylashtiriladi (masalan, XYZ-123). Ko'plab jamoalar branch nomiga ticket raqamini qo'shadi:

XYZ-123-update-feature

Bu yondashuvning ikkita afzalligi bor:

1. Jira tizimi branch-ni avtomatik tanib, ticket bilan bog'lay oladi
2. Boshqa dasturchilar branch ro'yxatini ko'rganda, qaysi ticket ustida allaqachon ish boshlanganini darhol bilishadi

Murakkabroq conflict — qisman birlashtirish

Ba'zan conflict-da ikkala versiyadan ham qism-qism olish kerak bo'ladi — to'liq chap yoki to'liq o'ng emas:

// Chap versiya (asosiy branch)
ScrollView {
    VStack {
        ForEach(0..<20) { item in
            Text("Yo")
        }
    }
}

// O'ng versiya (yangi branch)
Text("Yangi sarlavha")
Image(systemName: "globe")
Button("Bosing") { }

Bu holatda ikkala qismni ham saqlash, lekin ularni to'g'ri tartibda birlashtirish kerak bo'lishi mumkin — masalan, sarlavha va tugmani saqlab qolib, ForEach ichiga joylashtirish. Bunday murakkab hollarda kodni qo'lda tahrirlash, kerakli qismlarni kesib-joylashtirish to'g'ri yondashuv hisoblanadi.

⚠️ Muhim ogohlantirish — conflict hal qilish kompilyatsiyani kafolatlamaydi

Bu — ehtiyot bo'lish kerak bo'lgan eng muhim jihatlardan biri: Source Control conflict yo'qligini tasdiqlashi, kodning kompilyatsiya bo'lishini bildirmaydi.

✅ Conflict hal qilindi → Merge muvaffaqiyatli
❌ Lekin kod hali ham build bo'lmasligi mumkin!

Masalan, qo'lda kod birlashtirilganda, qavslar ({ }) noto'g'ri joyga tushib qolishi yoki butunlay yo'qolib qolishi mumkin — chunki Git buni matn darajasida ko'radi, kod sintaksisi darajasida emas. Shuning uchun merge yakunlangandan so'ng, loyihani albatta build qilib tekshirish kerak.

Agar build xato bersa, odatda eng tezkor yo'l — merge-ni yakunlab, keyin xatoni alohida tuzatib, qo'shimcha commit bilan saqlash:

1. Merge-ni yakunlash (build bo'lmasa ham)
2. Build xatosini topish (masalan, yetishmayotgan qavs)
3. Xatoni tuzatish
4. "fix merge conflict" kabi commit bilan saqlash
5. Push qilish

Conflict-larni kamaytirish — arxitekturaning roli

Ko'p dasturchi bir vaqtning o'zida bitta katta faylda ishlasa, conflict-lar muqarrar va tez-tez sodir bo'ladi — bu xuddi bir nechta odam bitta Google Docs hujjatini bir vaqtda tahrirlashga o'xshaydi.

Yechim — yaxshi arxitektura: Agar har bir funksiya o'z alohida faylida bo'lsa, turli jamoalar yoki dasturchilar turli fayllar ustida ishlasa, ular bir-birining koduga tegmasdan parallel ishlay oladi. Bu conflict-larning yuzaga kelish ehtimolini sezilarli darajada kamaytiradi.

Katta jamoalarda yaxshi arxitektura — shunchaki yaxshi amaliyot emas, balki conflict-larning oldini olishning asosiy vositalaridan biri hisoblanadi. Agar arxitektura yomon bo'lib, hamma narsa bir-biriga bog'liq (coupled) bo'lsa, ikki haftalik ishlab chiqilgan ikkita funksiyani birlashtirishda son-sanoqsiz conflict paydo bo'lishi mumkin — bu butun jamoa uchun katta vaqt yo'qotish va bosh og'rig'iga aylanadi.

Branch-larni bir-biriga birlashtirish

Har doim asosiy branch-ga (main) birlashtirish shart emas. Murakkab funksiya ustida ishlaganda, avval funksiya uchun asosiy branch ochib, keyin uning ichida har bir kichik qism uchun alohida sub-branch-lar yaratish va ularni birinchi navbatda funksiya branch-iga birlashtirish — keyin esa butun funksiya branch-ini asosiy branch-ga birlashtirish odatiy amaliyot hisoblanadi.

Xulosa

Merge conflict-lar bilan ishlash — Git va Source Control-dagi eng qiyin jihatlardan biri va vaqt o'tishi bilan osonlashmaydi, faqat tajriba bilan ko'nikma ortadi. Asosiy maqsad — yaxshi arxitektura va to'g'ri branch strategiyasi orqali conflict-larning oldini olish, lekin ular yuzaga kelganda, qaysi o'zgarishni saqlash kerakligini aniq tushunib, qo'lda hal qilishni bilish zarur.