Cherry-pick — bu nima, mexanizmi va Git-da qo'llanilishi

Cherry-pick nima?

Cherry-pick — bu belgilangan kommitdan o'zgarishlarni nusxalab, ularni joriy tarmoqdagi yangi kommit sifatida qo'llaydigan Git buyrug'idir. Nomi "gilos tanlash" metaforasidan kelib chiqqan: dasturchi faqat kerakli kommitlarni tanlaydi, qolganlarini e'tiborsiz qoldiradi.

Merge dan farqli o'laroq, cherry-pick merge kommit yaratmaydi va tarmoqlarni to'liq birlashtirishni talab qilmaydi. Rebase dan farqli o'laroq, cherry-pick kommitlar ketma-ketligini emas, faqat belgilanganlarni ko'chiradi. Bu cherry-pickni aniq tuzatishlarni ko'chirish uchun ideal vositaga aylantiradi.

Atlassian, 2025 ma'lumotlariga ko'ra, cherry-pick bir vaqtning o'zida bir nechta reliz tarmoqlari bilan ishlaydigan jamoalarning 47 foizida qo'llaniladi. Cherry-pick, ayniqsa, bir vaqtning o'zida ilovaning bir nechta versiyalari (LTS relizlari) qo'llab-quvvatlanadigan va ular o'rtasida tuzatishlarni ko'chirish talab qilinadigan mobil ishlanmada talab qilinadi.

Ko'chirish mexanizmi

Cherry-pick bajarilganda, Git belgilangan kommit va uning ota-onasi o'rtasidagi diff ni hisoblaydi, so'ngra bu diffni joriy tarmoqqa qo'llaydi. Agar o'zgarishlar konfliktsiz qo'llanilsa — Git bir xil xabar bilan, lekin yangi SHA bilan yangi kommit yaratadi. Agar konflikt bo'lsa — cherry-pick qo'lda hal qilish uchun to'xtatiladi.

Cherry-pick qanday ishlaydi

Sintaksis oddiy: ko'chirmoqchi bo'lgan kommitning xeshini ko'rsating. Git o'zgarishlarni joriy tarmoqqa yangi kommit sifatida nusxalaydi. Bir vaqtning o'zida bir nechta kommitlarni va butun diapazonlarni ko'chirish qo'llab-quvvatlanadi.

# Bitta kommitni joriy tarmoqqa ko'chirish
git cherry-pick a1b2c3d4

# Bir nechta kommitlarni ko'chirish
git cherry-pick a1b2c3d4 e5f6g7h8

# Kommitlar diapazonini ko'chirish (a1b2 dan f9e8 gacha, a1b2 ni hisobga olmaganda)
git cherry-pick a1b2c3d4..f9e8d7c6

Cherry-pick bajarilgandan so'ng, joriy tarmoq asl nusxadagi o'zgarishlar bilan yangi kommit oladi. Kommit xabari sukut bo'yicha asl nusxadan nusxalanadi, lekin -n (kommit yaratma) yoki --edit (xabarni tahrir qil) bayrog'i bilan o'zgartirilishi mumkin.

Tuzatishni ko'chirish misoli

Oddiy stsenariyni ko'rib chiqaylik: develop-da release/v2.0 reliz tarmog'ida ham mavjud bo'lgan tanqidiy xato topildi va tuzatildi. Butun develop-ni reliz tarmog'iga birlashtirmasdan, faqat shu tuzatishni ko'chirish kerak.

# Develop-da tuzatish bilan kommit xeshini top
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Reliz tarmog'iga o't
git checkout release/v2.0

# Tuzatishni qo'lla
git cherry-pick a1b2c3d4

# Agar konflikt bo'lsa — hal qil va davom et
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

-x bayrog'i kommit xabariga asl SHA-ga havola qo'shadi: "(cherry picked from commit a1b2c3d4)". Bu kommit qayerdan ko'chirilganini kuzatishni osonlashtiradi. Vaqtinchalik qoralamalardan tashqari barcha stsenariylarda -x dan foydalanish tavsiya etiladi.

Konfliktlar bilan ishlash

Konflikt paytida cherry-pick merge kabi ishlaydi: Git to'xtaydi va konfliktli fayllarni belgilaydi. Dasturchi konfliktni hal qiladi, git add ni bajaradi va keyin git cherry-pick --continue ni amalga oshiradi. Bekor qilish uchun — git cherry-pick --abort. --strategy bayrog'i birlashtirish strategiyasini belgilashga imkon beradi (masalan, variantlar bilan recursive).

# Cherry-pick da konfliktni hal qilish
# Git konfliktli fayllarni ko'rsatadi
git status

# Qo'lda hal qil, so'ng:
git add ruxsat_etilgan_fayl.kt
git cherry-pick --continue

# Yoki cherry-pick ni bekor qil:
git cherry-pick --abort

Cherry-pick qachon qo'llaniladi

Cherry-pick butun tarmoqlarni birlashtirmasdan aniq o'zgarishlarni ko'chirish talab qilinadigan stsenariylarda optimaldir. Cherry-pick eng yaxshi tanlov bo'lgan beshta asosiy holatni ko'rib chiqaylik.

• Hotfix ko'chirish — tuzatish develop-da topilgan, lekin uni reliz tarmog'iga (release/v2.0) qo'llash kerak. Cherry-pick develop-dagi tugallanmagan funksiyalarga tegmasdan faqat tuzatish kommitini ko'chiradi
• Eski versiyalarga backport — joriy versiya uchun tuzatish LTS reliziga ko'chirilishi kerak. Butun kod bazasini birlashtirish o'rniga cherry-pick faqat kerakli kommitlarni tanlaydi
• Boshqa tarmoqdagi kommitni bekor qilish — kommit noto'g'ri tarmoqqa qilingan bo'lsa, cherry-pick uni to'g'ri tarmoqqa ko'chiradi va asl kommit bekor qilinadi
• Hujjatlarni ko'chirish — barcha tarmoqlarda bo'lishi kerak bo'lgan README yoki konfiguratsiya fayllaridagi o'zgarishlarni cherry-pick orqali ko'chirish qulay
• Tanlab qo'llash — prototip tarmog'idan butun prototipni asosiy ishlanmaga ko'chirmasdan faqat bitta muvaffaqiyatli kommitni olish kerak

Mobil ishlanma uchun cherry-pick ilovaning bir nechta versiyalarini qo'llab-quvvatlashda juda muhimdir. Masalan, Google Play-da allaqachon chiqarilgan 3.2 versiyasida xato topilsa, develop esa 4.0 versiyasi uchun kodni o'z ichiga olsa — cherry-pick barcha breaking changes larni birlashtirmasdan tuzatishni v3.x tarmog'iga ko'chirishga imkon beradi. Bu, ayniqsa, turli API va bog'liqliklarga ega ikki yoki undan ortiq asosiy versiyalarni bir vaqtning o'zida qo'llab-quvvatlaydigan loyihalar uchun dolzarbdir.

Amaliyotdan misol: mobil ilovada Android 12 da Google Sign-In orqali avtorizatsiya paytida crash aniqlandi. Tuzatish develop-ga kiritildi va ko'rib chiqishdan o'tdi. Biroq joriy reliz tarmog'i v2.5 allaqachon beta-test bosqichida. Develop-dan release/v2.5 ga fix kommitining cherry-pick i tuzatishni keyingi relizga kiritish imkonini beradi, hali chiqarishga tayyor bo'lmagan qolgan o'zgarishlarni ko'chirmasdan.

Mobil loyihalarda cherry-pick dan foydalanganda bog'liqliklarni hisobga olish muhim: agar tuzatish reliz tarmog'ining ajralish nuqtasidan keyin develop-da o'zgartirilgan fayllarga ta'sir qilsa, cherry-pick to'liq bo'lmagan o'zgarishlar to'plamini keltirishi mumkin. Bunday hollarda barcha bog'liq o'zgarishlar ham ko'chirilganligini tekshirish kerak, aks holda ilova yig'ilmasligi yoki noto'g'ri ishlashi mumkin. O'zgarishlarni umumiy tarmoqqa surishdan oldin har doim cherry-pick dan keyin yig'ilishni tekshiring.

Cherry-pick vs Merge vs Rebase

Git-da o'zgarishlarni integratsiya qilishning uchta asosiy vositasi — merge, rebase va cherry-pick — turli vazifalarni hal qiladi. Tanlov qancha o'zgarishlarni ko'chirish kerakligi va tarix qanday ko'rinishi kerakligiga bog'liq.

Merge — ikkala tarmoqni to'liq birlashtirish va tarmoqlanish haqidagi ma'lumotni saqlash kerak bo'lganda. Rebase — shaxsiy tarmoqni toza tarix bilan dolzarb holatga yangilash kerak bo'lganda. Cherry-pick — faqat bitta yoki bir nechta tanlangan kommit kerak bo'lganda.

Amalda bu vositalar birlashtiriladi: funksiya develop-ga davriy rebase bilan ishlab chiqiladi, keyin --no-ff merge orqali birlashtiriladi va boshqa tarmoqqa tuzatishni ko'chirish zarur bo'lganda cherry-pick ishlatiladi. Har bir vosita o'z bosqichida o'z vazifasini hal qiladi.

Cherry-pick risklari va cheklovlari

Cherry-pick — foydali, ammo noto'g'ri yoki haddan tashqari foydalanilganda potensial xavfli vosita. Asosiy risklar kommitlarning takrorlanishi, kontekst yo'qolishi va keyingi birlashtirishlardagi konfliktlar bilan bog'liq.

• Kommitlarning takrorlanishi — agar xuddi shu kommit keyinchalik merge orqali tarmoqqa kelsa, Git o'zgarishlar bo'yicha bir xil ikkinchi kommit yaratadi. Bu tarixni ifloslantiradi va git bisect ni qiyinlashtiradi
• Kontekst yo'qolishi — cherry-pick diff ni ko'chiradi, lekin ota-ona kommitlar va bog'liqliklar haqidagi ma'lumotni ko'chirmaydi. Agar cherry-pick A bog'liq bo'lgan B kommitisiz A kommitini qo'llasa, mantiqiy xatolar yuzaga kelishi mumkin
• Merge paytida konfliktlar — cherry-pick dan so'ng tarmoqlarni to'liq birlashtirishda Git bir xil o'zgarishlarni ikki marta ko'rishi va oddiy merge paytida oldini olish mumkin bo'lgan konfliktlar yaratishi mumkin
• Bog'liqlik yo'qligi -x bayrog'isiz kommitning boshqa tarmoqdan ko'chirilganligini tushunish mumkin emas. O'zgarishning kelib chiqishini qidirishda dasturchi kommitning kelib chiqishini aniqlash uchun soatlab vaqt sarflashi mumkin

Riskler ni minimallashtirish bo'yicha tavsiyalar: har doim asl SHA ni ko'rsatish uchun -x bayrog'idan foydalaning, cherry-pick sababini kommit xabarida hujjatlashtiring va imkon qadar kontekst ruxsat berganda cherry-pick o'rniga merge dan foydalaning. Agar cherry-pick lar ko'p bo'lsa — tarmoqlarni qayta tuzishni ko'rib chiqing.

Cherry-pick da tekshirishlarni avtomatlashtirish

CI quvurlari cherry-pick ni alohida stsenariy sifatida hisobga olishi kerak. Avtomatik tekshirishni sozlash tavsiya etiladi: cherry-pick kommiti yaratilganda CI o'zgartirilgan fayllar kutilgan to'plamga mos kelishini tekshiradi va ta'sirlangan modullar uchun testlarni ishga tushiradi. Bu tarmoqlar o'rtasida aniq o'zgarishlarni ko'chirishda regressiya xavfini kamaytiradi.