Русский ▾ Topics ▾ Latest version ▾ git-cherry-pick last updated in 2.54.0

НАЗВАНИЕ

git-cherry-pick - Применение изменений, внесённых некоторыми существующими коммитами

ОБЗОР

git cherry-pick [--edit] [-n] [-m <номер-родителя>] [-s] [-x] [--ff]
		  [-S[<id-ключа>]] <коммит>…​
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]. Обратите внимание, что указание диапазона передаст все аргументы <коммит>…​ в один обход редакций (см. пример ниже, использующий maint master..next).

-e
--edit

С этой опцией git cherry-pick позволит вам редактировать сообщение коммита перед фиксацией.

--cleanup=<режим>

Этот параметр определяет, как сообщение коммита будет очищено перед передачей механизму фиксации. Дополнительные сведения см. в git-commit[1]. В частности, если <режиму> присвоено значение scissors, в случае конфликта к MERGE_MSG будет добавлен разделитель scissors перед передачей.

-x

При записи коммита добавляет строку «(cherry picked from commit …​)» к исходному сообщению коммита, чтобы указать, из какого коммита было скопировано это изменение. Это делается только для копирования без конфликтов. Не используйте эту опцию, если вы копируете из своей личной ветки, потому что эта информация бесполезна для получателя. Если, с другой стороны, вы копируете между двумя публично видимыми ветками (например, переносите исправление в ветку сопровождения для более старого выпуска из ветки разработки), добавление этой информации может быть полезным.

-r

Раньше команда по умолчанию выполняла -x, как описано выше, а -r отключал это. Теперь по умолчанию -x не выполняется, поэтому эта опция ничего не делает.

-m <номер-родителя>
--mainline <номер-родителя>

Обычно вы не можете скопировать слияние, потому что не знаете, какая сторона слияния должна считаться основной линией. Эта опция указывает номер родителя (начиная с 1) основной линии и позволяет cherry-pick воспроизвести изменение относительно указанного родителя.

-n
--no-commit

Обычно команда автоматически создаёт последовательность коммитов. Этот флаг применяет изменения, необходимые для копирования каждого указанного коммита в ваш рабочий каталог и индекс, без создания какого-либо коммита. Кроме того, при использовании этой опции ваш индекс не должен соответствовать коммиту HEAD. Копирование выполняется относительно начального состояния вашего индекса.

Это полезно при последовательном копировании эффектов более чем одного коммита в ваш индекс.

-s
--signoff

Добавляет завершитель (trailer) Signed-off-by в конец сообщения коммита. Дополнительную информацию см. в описании опции signoff в git-commit[1].

-S[<id-ключа>]
--gpg-sign[=<id-ключа>]
--no-gpg-sign

Подписывать коммиты с помощью GPG. Аргумент id-ключа необязателен, и если не указан, в качестве значения по умолчанию будет использоваться личное имя коммиттера; если аргумент указан, он должен следовать сразу после параметра, без пробела. Параметр --no-gpg-sign полезен, если нужно отменить переменную конфигурации commit.gpgSign или параметр --gpg-sign, заданный ранее.

--ff

Если текущий HEAD совпадает с родителем скопированного коммита, то будет выполнена перемотка вперёд (fast-forward) до этого коммита.

--allow-empty

По умолчанию копирование пустого коммита завершится ошибкой, указывая на то, что требуется явный вызов git commit --allow-empty. Эта опция отменяет это поведение, позволяя автоматически сохранять пустые коммиты при копировании. Обратите внимание, что когда действует «--ff», пустые коммиты, удовлетворяющие требованию «fast-forward», будут сохранены даже без этой опции. Также обратите внимание, что использование этой опции сохраняет только те коммиты, которые были изначально пустыми (т.е. коммит записал то же дерево, что и его родитель). Коммиты, которые стали пустыми из-за предыдущего коммита, вызовут ошибку копирования. Чтобы принудительно включить эти коммиты, используйте --empty=keep.

--allow-empty-message

По умолчанию копирование коммита с пустым сообщением завершится ошибкой. Эта опция отменяет это поведение, позволяя копировать коммиты с пустыми сообщениями.

--empty=(drop|keep|stop)

Как обрабатывать коммиты, которые копируются и являются избыточными по отношению к изменениям, уже существующим в текущей истории.

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].

ПОДКОМАНДЫ ПОСЛЕДОВАТЕЛЯ (SEQUENCER)

--continue

Продолжить выполняющуюся операцию, используя информацию в .git/sequencer. Может использоваться для продолжения после разрешения конфликтов в неудачном копировании коммита или отмене.

--skip

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

--quit

Забыть о текущей выполняющейся операции. Может использоваться для очистки состояния механизма последовательности после неудачного копирования коммита или отмены.

--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, чтобы результат можно было проверить и, если необходимо, превратить в один новый коммит.

Следующая последовательность пытается перенести патч (backport), прерывается, потому что код, к которому применяется патч, слишком сильно изменился, а затем пытается снова, на этот раз проявляя больше осторожности при сопоставлении строк контекста.

$ 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]