українська мова ▾ Topics ▾ Latest version ▾ git-cherry-pick last updated in 2.54.0

НАЗВА

git-cherry-pick — Застосування змін, внесених у деяких наявних комітах

СИНОПСИС

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
		  [-S[<keyid>]] <commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

ОПИС

Якщо є один або кілька наявних комітів, застосовує зміни, внесені кожним із них, створюючи для кожного новий коміт. Для цього робоче дерево має бути чистим (без змін порівняно з комітом HEAD).

Коли незрозуміло, як застосувати зміни, відбувається таке:

  1. Поточна гілка та вказівник HEAD залишаються на останньому успішно зробленому коміті.

  2. Посилання CHERRY_PICK_HEAD встановлено так, щоб воно вказувало на коміт, у якому було внесено зміну, яку важко застосувати.

  3. Шляхи, в яких зміни застосовано чисто, оновлюються як у файлі індексу, так і у вашому робочому дереві.

  4. У разі конфлікту шляхів індексний файл фіксує до трьох версій, як описано в розділі «СПРАВЖНЄ ЗЛИТТЯ» документації git-merge[1]. Файли робочого дерева міститимуть опис конфлікту, який буде виділено звичайними маркерами конфлікту <<<<<<< та >>>>>>>.

  5. Жодних інших модифікацій не вноситься.

Дивіться git-merge[1] для отримання деяких підказок щодо вирішення таких конфліктів.

ОПЦІЇ

<commit>…​

Коміти для вибіркового додавання (cherry-pick). Більш повний перелік варіантів запису комітів див. у gitrevisions[7]. Набори комітів можна передавати, але в стандартному режимі обхід не виконується, нібито вказано опцію --no-walk, див. git-rev-list[1]. Зверніть увагу, що вказання діапазону передасть усі аргументи <commit>…​ до одного обходу ревізій (див. приклад далі, де використовується maint master..next).

-e
--edit

З цією опцією, git cherry-pick дозволить вам редагувати повідомлення коміту перед його створенням.

--cleanup=<mode>

Цей параметр визначає, як повідомлення коміту буде очищено перед передачею на механізм комітів. Див. git-commit[1] для отримання додаткової інформації. Зокрема, якщо для <mode> надано значення scissors, scissors буде додано до MERGE_MSG перед передачею у разі конфлікту.

-x

Під час запису коміту додайте до оригінального повідомлення про коміт рядок «(вибрано з коміту …​)», щоб вказати, з якого саме коміту було вибрано цю зміну. Це робиться лише для вибраних змін без конфліктів. Не використовуйте цю опцію, якщо ви вибираєте зміни з вашої приватної гілки, оскільки ця інформація є марною для одержувача. Якщо ж ви вибираєте зміни між двома загальнодоступними гілками (наприклад, переносите виправлення з гілки розробки до гілки обслуговування для старішого випуску), додавання цієї інформації може бути корисним.

-r

Раніше команда автоматично виконувала описану вище дію -x, а опція -r призначалася для її відключення. Тепер стандартним варіантом є відмова від виконання -x, тому ця опція не виконує жодних дій.

-m <parent-number>
--mainline <parent-number>

Зазвичай ви не можете вибрати злиття за допомогою cherry-pick, оскільки не знаєте, яку сторону злиття слід вважати основною лінією. Ця опція вказує номер батьківського елемента (починаючи з 1) основної лінії та дозволяє cherry-pick відтворити зміну відносно зазначеного батьківського елемента.

-n
--no-commit

Зазвичай ця команда автоматично створює послідовність комітів. Цей прапорець застосовує зміни, необхідні для вибіркового додавання кожного вказаного коміту до робочого дерева та індексу, не створюючи при цьому жодного коміту. Крім того, при використанні цієї опції індекс не обов’язково має збігатися з комітом HEAD. Вибіркове додавання виконується відносно початкового стану індексу.

Це корисно, коли потрібно послідовно додати до індексу зміни з декількох комітів.

-s
--signoff

Додає трейлер Signed-off-by в кінці повідомлення коміту. Дивіться опцію підписання в git-commit[1] для отримання додаткової інформації.

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

Підписувати коміти за допомогою GPG. Аргумент keyid є необов’язковим, а стандартним значенням є ідентифікатор автора коміту; якщо його вказано, він повинен бути вказаний безпосередньо після опції без пробілу. Опція --no-gpg-sign дозволяє скасувати дію як конфігураційної змінної commit.gpgSign, так і раніше вказаної опції --gpg-sign.

--ff

Якщо поточний HEAD збігається з батьківським комітом обраного методом cherry-pick, то буде виконано перемотування вперед до цього коміту.

--allow-empty

Зазвичай вибір окремих змін (cherry-pick) з порожнього коміту завершиться невдачею, що вказує на необхідність явного виклику команди git commit --allow-empty. Ця опція змінює таку поведінку, дозволяючи автоматично зберігати порожні коміти під час вибору окремих змін. Зверніть увагу, що коли діє опція «--ff», порожні коміти, які відповідають вимогам «fast-forward», зберігатимуться навіть без цієї опції. Також зверніть увагу, що використання цієї опції зберігає лише ті коміти, які спочатку були порожніми (тобто коміт записав те саме дерево, що й його батько). Коміти, які стали порожніми внаслідок попереднього коміту, призведуть до невдачі вибору. Щоб примусово включити ці коміти, використовуйте --empty=keep.

--allow-empty-message

Стандартно копіювання окремого коміту з порожнім повідомленням завершиться невдачею. Ця опція змінює цю поведінку, дозволяючи копіювати окремі коміти з порожніми повідомленнями.

--empty=(drop|keep|stop)

Як поводитися з комітами, які вибираються окремо (cherry-pick) і дублюють зміни, що вже містяться в поточній історії.

drop

Коміт буде відкинуто.

keep

Коміт буде збережено. Має на увазі --allow-empty.

stop

Вибірка припиниться після застосування коміту, що дозволить вам переглянути його. Це стандартна поведінка.

Зверніть увагу, що --empty=drop та --empty=stop вказують лише на те, як обробляти коміт, який спочатку не був порожнім, а став порожнім через попередній коміт. Коміти, які спочатку були порожніми, все одно призведуть до невдалого вибору коміту, якщо не вказано один з параметрів --empty=keep або --allow-empty.

--keep-redundant-commits

Застарілий синонім для --empty=keep.

--strategy=<strategy>

Використовувати вказану стратегію злиття. Слід використовувати лише один раз. Див. розділ СТРАТЕГІЇ ЗЛИТТЯ в git-merge[1] для отримання детальної інформації.

-X<option>
--strategy-option=<option>

Передайте параметр, повʼязаний із стратегією злиття, безпосередньо до стратегії злиття. Детальніше див. git-merge[1].

--rerere-autoupdate
--no-rerere-autoupdate

Після того як механізм rerere повторно використає збережене рішення поточного конфлікту для оновлення файлів у робочому дереві, дозвольте йому також оновити індекс результатом вирішення. Параметр --no-rerere-autoupdate — це хороший спосіб ще раз перевірити, що зробив git-rerere[1], і виявити можливі помилки злиття, перш ніж зафіксувати результат в індексі за допомогою окремої команди git-add[1].

СУБКОМАНДИ СЕКВЕНСОРА

--continue

Продовжити поточну операцію, використовуючи інформацію з теки .git/sequencer. Цю функцію можна використовувати для продовження роботи після усунення конфліктів, що виникли під час невдалого вибору змін або відкату (cherry-pick або revert).

--skip

Пропустити поточний коміт та продовжити решту послідовності.

--quit

Забути про поточну операцію, що виконується. Може використовуватися для очищення стану секвенсора після невдалого вибіркового відновлення або відкату (cherry-pick або revert.).

--abort

Скасувати операцію та повернутися до попереднього стану.

ПРИКЛАДИ

git cherry-pick master

Застосувати зміни, внесені комітом, що знаходиться на вершині гілки master, і створити новий коміт із цими змінами.

git cherry-pick ..master
git cherry-pick ^HEAD master

Застосувати зміни, внесені всіма комітами, що є предками master, але не HEAD, для створення нових комітів.

git cherry-pick maint next ^master
git cherry-pick maint master..next

Застосувати зміни, внесені всіма комітами, що є предками maint або next, але не master або будь-якого з його предків. Зверніть увагу, що останнє не означає maint та все, що знаходиться між master та next; зокрема, maint не використовуватиметься, якщо він включений до master.

git cherry-pick master~4 master~2

Застосувати зміни, внесені пʼятим та третім останнім комітами, на які вказує master, та створити 2 нових коміти з цими змінами.

git cherry-pick -n master~1 next

Застосувати до робочого дерева та індексу зміни, внесені передостаннім комітом, на який вказує master, та останнім комітом, на який вказує next, але не створювати жодного коміту з цими змінами.

git cherry-pick --ff ..next

Якщо історія лінійна, а HEAD є предком next, оновити робоче дерево та змістити вказівник HEAD, щоб він відповідав next. В іншому випадку застосувати зміни, внесені тими комітами, які знаходяться в next, але не в HEAD, до поточної гілки, створюючи новий коміт для кожної нової зміни.

git rev-list --reverse master -- README | git cherry-pick -n --stdin

Застосувати зміни, внесені всіма комітами в гілці master, що стосувалися README, до робочого дерева та індексу, щоб результат можна було перевірити та, за потреби, перетворити на один новий коміт.

Наведена нижче послідовність намагається перенести латку, завершує роботу, оскільки код, до якого застосовується латка, занадто сильно змінився, а потім намагається знову, цього разу приділяючи більше уваги збігу рядків контексту.

$ git cherry-pick topic^             (1)
$ git diff                           (2)
$ git cherry-pick --abort            (3)
$ git cherry-pick -Xpatience topic^  (4)

  1. застосує зміни, які будуть показані командою git show topic^. У цьому прикладі латка застосовується не повністю, тому інформація про конфлікт записується в індекс та робоче дерево, і нові зміни не створюються.

  2. узагальнення змін, що підлягають узгодженню

  3. скасувати вибірку. Іншими словами, повернутися до стану до вибору, зберігаючи будь-які локальні зміни, які ви мали в робочому дереві.

  4. спробувати застосувати зміну, внесену topic^, ще раз, витративши додатковий час, щоб уникнути помилок, повʼязаних з неправильно зіставленими рядками контексту.

ДИВ. ТАКОЖ

git-revert[1]

GIT

Частина набору git[1]