git cherry-pick: перенести один коммит в текущую ветку

git cherry-pick <хеш> берёт изменения одного коммита из другой ветки и накладывает их на ту ветку, где ты стоишь сейчас.

Ситуация обычная. Нужная правка лежит в чужой ветке, а вливать её целиком рано: там ещё половина работы не доделана. Или срочная починка сделана не в той ветке и должна попасть в main прямо сейчас. Найди коммит в логе и назови его по хешу:

$ git log --oneline redesign
fe7883f header spacing
098f8d2 fix the wrong number in the report
f8b6906 new header layout

$ git switch main
Switched to branch 'main'
$ git cherry-pick 098f8d2
[main 3472870] fix the wrong number in the report
 Date: Mon Mar 3 14:22:10 2025 +0300
 1 file changed, 1 insertion(+), 1 deletion(-)

Хеш в ответе другой: 3472870 вместо 098f8d2. Это главное про команду. Cherry-pick не перемещает коммит, а создаёт новый коммит с теми же изменениями, но со своим родителем и своим хешем. Исходный коммит остаётся на месте в ветке redesign, его никто не трогал. Строка Date в выводе показывает, что дата авторства переехала вместе с изменениями, поэтому она и не совпадает с сегодняшней.

Несколько коммитов перечисляются через пробел, git применит их в указанном порядке:

$ git cherry-pick 098f8d2 fe7883f

Диапазон пишется через две точки: git cherry-pick f8b6906..fe7883f возьмёт всё, что идёт после f8b6906 и до fe7883f включительно.

Когда перенос остановился

Если та же строка успела измениться и в текущей ветке, git останавливается ровно так же, как при слиянии:

$ git cherry-pick 098f8d2
Auto-merging report.txt
CONFLICT (content): Merge conflict in report.txt
error: could not apply 098f8d2... fix the wrong number in the report

Дальше конфликт разбирается обычным способом: правишь файл, убираешь маркеры, кладёшь результат в индекс через git add. Завершает перенос не git commit, а отдельная команда:

$ git cherry-pick --continue     # дописать коммит после разбора конфликта
$ git cherry-pick --abort        # отменить всё и вернуться в исходное состояние

Частые ошибки

Дубли в истории. Если ветка redesign всё равно потом вольётся в main через git merge, перенесённая правка окажется там дважды: своим коммитом и в составе слияния. Содержимое git обычно сведёт без конфликта, но в логе останутся два похожих коммита с разными хешами, и разбираться в такой истории неприятно. Cherry-pick - для случая «надо только это и сейчас», а не замена слиянию.

Коммит, вырванный из контекста. Правка, которая опирается на предыдущий коммит той же ветки, применится без единой жалобы и оставит сломанный код: git сравнивает текст, а не смысл. Перед переносом посмотри коммит целиком через git show <хеш> и проверь, не тянет ли он за собой соседа.

Где это в учебнике

Откуда берутся отдельные коммиты в чужих ветках, разобрано здесь: Глава 5. Ветки: параллельные версии проекта.