Cherry-pick — bu Git buyrug'i bo'lib, ko'rsatilgan commitdagi o'zgarishlarni joriy filialga qo'llaydi, asl filialning butun tarixini ko'chirmagan holda. merge yoki rebase'dan farqli o'laroq, cherry-pick har bir commit bilan alohida ishlaydi: dasturchi xesh bo'yicha aniq commitni tanlaydi va faqat uning o'zgarishlarini ko'chiradi. Git hujjatlariga (2026) ko'ra, cherry-pick reliz filiallari o'rtasida tuzatishlarni aniq ko'chirish uchun ayniqsa foydali, butun merge ortiqcha yoki xavfli bo'lganda. Buyruq yangi xesh bilan yangi commit yaratadi, lekin asl xabarni va muallifni saqlaydi.
Muhim
Cherry-pick — bu git cherry-pick buyrug'i bo'lib, mavjud commitdagi o'zgarishlarni oladi va ularni joriy filialda yangi commit sifatida qo'llaydi. Asl commit o'z filialida joyida qoladi, maqsadli filialda esa o'zgarishlar nusxasi yaratiladi. Buyruq butun filialni ko'chirmasdan aniq tuzatishni ko'chirish kerak bo'lganda foydali.
Sintaksis: git cherry-pick <commit-hash>. Git ko'rsatilgan commitning ota-commiti bilan farqini (diff) tahlil qiladi va bu farqni joriy filialga qo'llaydi. Agar bir nechta fayl o'zgargan bo'lsa — barchasi birga ko'chiriladi. Buyruq shuningdek diapazonlarni qabul qiladi: git cherry-pick A..B — A dan B gacha bo'lgan barcha commitlar, A ni hisobga olmaganda.
Bayroqlar imkoniyatlarni kengaytiradi: -n (--no-commit) o'zgarishlarni commit yaratmasdan ishchi katalog va indeksga qo'llaydi — bir nechta commit o'zgarishlarini bitta commitga birlashtirish kerak bo'lganda foydali. -x bayrog'i commit xabariga (cherry picked from commit ...) qatorini qo'shadi, bu tarixdagi o'zgarishlarning kelib chiqishini kuzatishni osonlashtiradi.
# Commitni xesh bo'yicha cherry-pick qilish
git cherry-pick a1b2c3d
# Bir nechta commitlarni cherry-pick qilish (ketma-ket)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l
# Avtomatik commitsiz cherry-pick
git cherry-pick -n a1b2c3d
# -x bayrog'i asl commitga havola qo'shadi
git cherry-pick -x a1b2c3d
Asosiy stsenariy — tuzatishlarni reliz filiallari o'rtasida ko'chirish. Tasavvur qiling: develop'da kritik xato topildi va tuzatildi. release/v2.1 reliz filiali allaqachon ajratilgan va unda ham bu xato mavjud. Butun develop'ni release'ga merge qilish juda ko'p tayyor bo'lmagan kodni ko'chiradi, bitta tuzatuvchi commitni cherry-pick qilish esa — xavfsiz va aniq yechim.
Ikkinchi stsenariy — o'zgarishlarni bekor qilish (revert) keyinchalik tiklash bilan. Agar commit git revert orqali bekor qilingan bo'lsa, keyin esa bekor qilish xato bo'lgani ma'lum bo'lsa — bekor qilingan commitni cherry-pick qilish o'zgarishlarni tiklaydi. Bu revert'ni bekor qilishdan ko'ra to'g'riroq, chunki qayta konfliktlar yaratmaydi.
Uchinchi stsenariy — turli feature filiallardan commitlarni birlashtirish bitta test filialiga integratsion testlash uchun. Bir nechta tugallanmagan filiallarni (tugallanmagan kod bilan) birlashtirish o'rniga, har biridan faqat tayyor commitlarni tanlab, ularning birgalikdagi ishlashini sinash mumkin.
Cherry-pick rebase va merge'dan farq qiladi, chunki butun filiallar emas, balki alohida commitlar darajasida ishlaydi. Agar rebase filialning barcha commitlarini ko'chirsa, merge esa ikkita filialni birlashtirsa, cherry-pick faqat keraklilarini tanlaydi. Bu uni aniqroq, ammo qo'lda boshqariladigan vositaga aylantiradi.
Yana bir farq — mualliflik. Cherry-pick'da Git sukut bo'yicha asl commit muallifini (Author) saqlaydi, ammo commit qiluvchi (Committer) joriy foydalanuvchi bo'ladi. Commit xabarida kelib chiqishni -x bayrog'i orqali kuzatish mumkin. Rebase'da muallif ham, commit qiluvchi ham — yangi xeshli joriy foydalanuvchi bo'ladi.
Unumdorlik: bitta commitni cherry-pick qilish ko'p commitli ikki filialni merge qilishdan tezroq bajariladi. Ammo o'nlab commitlarni ko'chirish kerak bo'lsa, vaqtinchalik filial yaratib rebase qilish yaxshiroq — bu samaraliroq bo'ladi va o'nlab xeshlarni ko'rsatishni talab qilmaydi.
| Operatsiya | Qo'llanish sohasi | Yon ta'sirlar |
|---|---|---|
| Cherry-pick | Alohida commitlar | Yangi xesh, kodni takrorlash |
| Rebase | Filialning barcha commitlari | Tarixni qayta yozish, yangi xeshlar |
| Merge | Filiallarni to'liq birlashtirish | Merge commit, tarixni saqlash |
Bir nechta commitlarni bitta buyruq bilan ko'chirish mumkin, ularning xeshlarini bo'sh joy bilan sanab: git cherry-pick A B C. Git commitlarni ko'rsatilgan tartibda ketma-ket qo'llaydi. Agar commitlardan biri konflikt keltirsa, cherry-pick to'xtaydi va dasturchi konfliktni hal qilishi kerak, shundan so'ng git cherry-pick --continue buyrug'i bilan davom etadi.
Commitlar diapazoni: git cherry-pick A..B (A'dan keyingi B gacha bo'lgan barcha commitlar, A ni hisobga olmaganda) va git cherry-pick A^..B (A dan B gacha barcha commitlar, A ni hisobga olgan holda). Diapazonlar bitta filialdagi barcha commitlarni ota-aloqa holda ko'chirish kerak bo'lganda qulay — masalan, tayyor featuri eski filialdan yangisiga ko'chirishda.
--strategy bayrog'i Git o'zgarishlarni qanday qo'llashini aniqlaydi. Sukut bo'yicha recursive strategiya qo'llaniladi, ammo konflikt tomonini avtomatik tanlash uchun ours yoki theirs ko'rsatilishi mumkin. --mainline bayrog'i merge commitni cherry-pick qilishda qo'llaniladi — diff hisoblanadigan ota-ona raqamini (1 yoki 2) ko'rsatadi.
# Commitlar diapazonini cherry-pick qilish
git cherry-pick develop~5..develop~2
# Merge commitni cherry-pick qilish (ota-onani ko'rsating)
git cherry-pick -m 1 m9n0o1p
# theirs strategiyasidan foydalanish
git cherry-pick --strategy=recursive \
--strategy-option=theirs a1b2c3d
# Konflikt hal qilinganidan keyin davom eting
git cherry-pick --continue
Cherry-pick'dagi konfliktlar ko'chirilayotgan commit o'zgarishlari maqsadli filialda o'zgartirilgan qatorlarga tegishli bo'lganda yuzaga keladi. Git bajarishni to'xtatadi, konfliktli fayllarni belgilaydi va hal qilishni kutadi. Statusda bunday fayllar both modified deb ko'rsatiladi.
Konfliktda harakatlar tartibi: konfliktli faylni ochish, konflikt markerlarini topish (<<<<<<<, =======, >>>>>>>), tarkibni tahrirlash, markerlarni olib tashlash, hal qilingan fayllar uchun git add bajarish va git cherry-pick --continue ishga tushirish. Agar konflikt hal qilib bo'lmasa — git cherry-pick --abort butun cherry-pick'ni bekor qiladi, filialni dastlabki holatga qaytaradi.
Tez-tez uchraydigan muammo: commit allaqachon mavjud o'zgarishlarga ekvivalent o'zgarishlarni o'z ichiga oladi. Bunday holda Git cherry-pick'da “nothing to commit“ yoki “empty commit“ deb xabar beradi. --keep-redundant-commits va --empty=keep bayroqlari Gitni ketma-ketlikni saqlash uchun bo'sh commit yaratishga majbur qiladi, --skip esa bunday commitni o'tkazib yuborishga imkon beradi.
# Cherry-pick paytida konflikt — to'xtatish
git cherry-pick a1b2c3d
# xato: a1b2c3d... commit xabari qo'llanilmadi
# Konfliktni hal qiling → indeksga qo'shing
git add src/conflicted_file.swift
git cherry-pick --continue
# Bo'sh commitni o'tkazib yuborish (allaqachon qo'llangan)
git cherry-pick --skip
# To'liq bekor qilish (abort)
git cherry-pick --abort
Birinchi qoida: ko'chirilayotgan commit o'z-o'zini ta'minlaganligini doim tekshiring. Agar A commiti ko'chirilmaydigan B commitidagi o'zgarishlarga bog'liq bo'lsa, A ni cherry-pick qilish buildni buzishi mumkin. Cherry-pick'dan oldin commit qaysi fayllarni o'zgartirganini git show --stat <hash> orqali tekshirish foydali.
Ikkinchi qoida: cherry-pick'ni hujjatlashtiring. Commit xabarida asl commitga havola saqlanishi uchun -x bayrog'ini qo'llang. Bu tarixni keyingi tahlil qilishda o'zgarish qayerdan kelganini tushunishga yordam beradi. -x'siz cherry-pick oddiy commitga o'xshaydi va uning kelib chiqishini faqat git log --graph orqali aniqlash mumkin.
Uchinchi qoida: juda ko'p tarqalgan filiallar o'rtasida cherry-pick'dan saqlaning. Commit yaratilganidan beri ko'p vaqt o'tgan va kod bazasi sezilarli o'zgargan bo'lsa, konfliktlar ko'p va murakkab bo'ladi. Bunday hollarda maqsadli filialda tuzatishni qaytadan qilish yaxshiroq — o'nlab konfliktlarni hal qilishdan ko'ra kamroq vaqt oladi.
Tez-tez so'raladigan savollar
Cherry-pick qilish — ko'rsatilgan commit o'zgarishlarini git cherry-pick orqali joriy filialga qo'llash. Buyruq bir xil o'zgarishlar bilan, ammo yangi xeshli yangi commit yaratadi. Asl commit o'z filialida o'zgarishsiz qoladi. Bu butun filialni birlashtirishga alternativa, faqat bitta aniq commit kerak bo'lganda.
Cherry-pick butun filialni ko'chirmasdan bir yoki bir nechta aniq commitlarni ko'chirish kerak bo'lganda tanlanadi. Merge filiallarni to'liq birlashtirish uchun qo'llaniladi. Cherry-pick'ning odatiy stsenariysi — ishlab chiqish filialidan reliz filialiga bugfiksni ko'chirish, unda boshqa o'zgarishlar hali tayyor emas.
Tugashidan oldin — git cherry-pick --abort operatsiyani to'liq bekor qiladi. Muvaffaqiyatli tugaganidan keyin — git revert <hash> cherry-pick o'zgarishlarini bekor qiluvchi commit yaratadi. --abort'dan farqi: revert commitni tarixdan o'chirmaydi, balki bekor qiluvchi yangi commit yaratadi.
Bo'sh commit o'zgarishlar maqsadli filialda allaqachon mavjud bo'lganda yuzaga keladi. git cherry-pick --skip dan bunday commitni o'tkazib yuborish uchun foydalaning yoki xeshlar ketma-ketligini saqlash uchun git cherry-pick --keep-redundant-commits bilan bo'sh commit yarating.
Cherry-pick tanlangan commitlarni (bittadan yoki ro'yxat bo'yicha) joriy filialga ko'chiradi. Rebase filialning barcha commitlarini yangi bazaga ko'chiradi. Cherry-pick asl filialni o'zgartirmaydi, rebase tarixni qayta yozadi. Cherry-pick aniq, lekin qo'lda boshqariladi; rebase avtomatik, lekin ommaviy filiallar uchun xavfli.
Xulosalar
Biz kalit topshirig'i bilan mobil ilovani ishlab chiqamiz
IT Sectr 2017-yildan beri startaplar va korxonalar uchun iOS va Android ilovalarini yaratadi. Biz sizga maslahat beramiz va eng yaxshi yechimni taklif qilamiz.
Shuningdek o'qing