Conflict — version control tizimi ikki o‘zgarishni avtomatik va ishonchli tarzda bitta natijaga birlashtira olmagan holatdir. Git merge, rebase, cherry-pick, revert yoki patch qo‘llashda conflict ko‘rsatishi mumkin. Conflict kod xatosining o‘zi emas; yakuniy ma’no uchun inson qarori talab qilinayotganini bildiradi.
Yuzaga kelish sabablari
Ikki branch bir faylning bir xil satrlarini turlicha o‘zgartirsa content conflict paydo bo‘ladi. Biri faylni o‘chirib, boshqasi tahrir qilsa modify/delete conflict yuz beradi. Ikkala tomon bir nomda turli fayl yaratishi yoki rename’lar to‘qnashishi ham mumkin.
Git satrlar turli joyda bo‘lsa avtomatik merge qiladi. Biroq semantik conflict marker chiqarmasdan qolishi mumkin: bir branch function parametrini o‘zgartiradi, boshqasi eski chaqiruvni yangi faylga qo‘shadi. Shu sababli “conflictsiz merge” to‘g‘ri integratsiya kafolati emas.
Conflict marker
Matnli faylda Git odatda quyidagi markerlarni yozadi:
<<<<<<< HEAD
current branch matni
=======
incoming branch matni
>>>>>>> feature
Yechim markerlarning bir tomonini ko‘r-ko‘rona qoldirish emas. Ikkala niyat o‘qilib, kerak bo‘lsa yangi uchinchi variant yoziladi. Barcha markerlar olib tashlanadi va fayl sintaksisi tekshiriladi.
Index bosqichlari
Conflict vaqtida index base, ours va theirs versiyalarini alohida bosqichlarda saqlashi mumkin. git checkout --ours va --theirs atamalari merge kontekstida tushunarli, rebase’da “ours” yangi base tomoni bo‘lib kutilganga teskari ko‘rinishi mumkin. Buyruqdan oldin aynan qaysi versiya ekanini diff bilan ko‘rish kerak.
git status unresolved fayllarni ko‘rsatadi. Fayl hal qilingach git add yechimni indexga belgilaydi. Keyin merge commit yoki rebase --continue jarayonni davom ettiradi.
Binary va generated fayl
Binary fayl satr bo‘yicha birlashtirilmaydi; tomonlardan biri tanlanadi yoki maxsus merge driver ishlatiladi. Generated lockfile conflictida source dependency ta’rifini to‘g‘rilab, package manager bilan faylni qayta yaratish qo‘lda satr aralashtirishdan xavfsizroq bo‘lishi mumkin.
Database migration raqami yoki schema fayli conflict marker bo‘lmasa ham mantiqiy to‘qnashishi mumkin. Ikkala migration bir xil nom yoki ketma-ketlikka da’vo qilsa framework qoidasi bilan yangi migration yaratiladi.
Oldini kamaytirish
Kichik va tez-tez integratsiya qilinadigan branchlar farq hajmini kamaytiradi. Kod ownership va jamoa aloqasi bir xil modulni parallel katta qayta yozishni muvofiqlashtiradi. Formatter versiyasi bir xil bo‘lsa keraksiz whitespace conflictlari kamayadi.
Yechimdan keyin test, lint va funksional talab tekshiriladi. Conflictni hal qilgan commit review’da alohida ko‘rilishi mumkin, chunki asl branchlarning hech birida bo‘lmagan yangi kombinatsiya paydo bo‘ladi.
Rerere mexanizmi
Gitdagi rerere funksiyasi “reuse recorded resolution” ma’nosini anglatadi. U conflictning oldingi va yechilgan ko‘rinishini yozib, ayni to‘qnashuv rebase yoki merge jarayonida yana uchrasa, avvalgi yechimni taklif qilishi mumkin. Bu uzoq davom etuvchi branchni takroran rebase qiladigan jamoalarda vaqtni tejaydi. Avtomatik qo‘llangan yechim ham tekshiruvsiz qabul qilinmaydi, chunki atrofdagi kod va talab o‘zgargan bo‘lishi mumkin. Conflict markerlarini oddiy matn qidiruvi bilan CI bosqichida tekshirish tasodifan <<<<<<< satrlari commit qilinishini aniqlaydi, ammo sintaktik to‘g‘ri, mazmunan xato yechimni test va review topishi kerak.
Conflict yechimida “ours” va “theirs” atamalari bajarilayotgan operatsiyaga bog‘liq. Oddiy merge va rebase jarayonida ularning ko‘rsatadigan tomoni foydalanuvchi kutganiga teskari ko‘rinishi mumkin. Faylni butunlay bir tomondan olishdan oldin git status va diff bilan bosqichlar tekshiriladi.
Bog‘liq tushunchalar
Git, merge, rebase, conflict marker, index, three-way merge, code review