git-cherry-pick

Имя

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

Когда непонятно, как применить изменение, происходит следующее:

Текущая ветвь и указатель HEAD остаются на последнем успешно созданном коммите.
Ссылка CHERRY_PICK_HEAD устанавливается на коммит, который внёс изменение, которое сложно применить.
Пути, в которых изменение было применено без проблем, обновляются как в файле индекса, так и в рабочей области.
Для путей с конфликтами, файл индекса записывает до трёх версий, как описано в разделе «ИСТИННОЕ СЛИЯНИЕ» в git-merge[1]. Файлы рабочей области будут содержать описание конфликта, заключённое в обычные маркеры конфликта <<<<<<< и >>>>>>>.
Другие модификации не производятся.

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

Параметры

<commit>…

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

-e

--edit

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

--cleanup=<mode>

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

-x

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

-r

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

-m <parent-number>

--mainline <parent-number>

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

-n

--no-commit

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

Это полезно при подхвате влияния нескольких коммитов в вашем индексе подряд.

-s

--signoff

Добавить Signed-off-by трейлер в конце сообщения коммита. См. параметр signoff в git-commit[1] для получения более подробной информации.

-S[<keyid>]

--gpg-sign[=<keyid>]

--no-gpg-sign

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

--ff

Если текущий HEAD совпадает с родителем коммита, который подхватывается, будет выполнена быстрая переадресация к этому коммиту.

--allow-empty

По умолчанию подхват пустого коммита завершается ошибкой, указывая на необходимость явного вызова git commit --allow-empty. Этот параметр переопределяет это поведение, позволяя автоматически сохранять пустые коммиты при подхвате. Обратите внимание, что при использовании "--ff" пустые коммиты, удовлетворяющие условиям «быстрой переадресации», будут сохранены даже без этого параметра. Также обратите внимание, что использование этого параметра сохраняет только коммиты, которые изначально были пустыми (т. е. коммит записал тот же дерево, что и его родительский). Коммиты, которые становятся пустыми из-за предыдущего коммита, приведут к завершению подхвата ошибкой. Чтобы принудительно включить эти коммиты, используйте --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 — хороший способ проверить, что rerere сделал, и предотвратить потенциальные ошибки слияния перед записью результата в индекс с помощью отдельного git add.

Подкоманды последователя

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

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

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

применить изменение, которое было бы показано git show topic^. В этом примере патч не применяется без проблем, поэтому информация о конфликте записывается в индекс и рабочую область, и новый коммит не создаётся.
сводка изменений для согласования
отмена cherry-pick. Другими словами, возврат к состоянию до cherry-pick, сохраняя любые локальные изменения, которые были в рабочей области.
повторная попытка применить изменение, внесённое topic^, потратив больше времени, чтобы избежать ошибок, связанных с некорректным сопоставлением строк контекста.

См. также

git-revert[1]

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-cherry-pick