Кто-нибудь может объяснить, что делает git cherry-pick ‹sha›?

Меня беспокоит то, что у меня есть старая фиксация в моей другой локальной ветке [содержит abc.cpp, def.cpp].

Теперь, через несколько месяцев, я хочу использовать эти изменения, но в моей текущей ветке обновлен abc.cpp. То есть, если я выберу вишню, он интегрирует изменения старого abc.cpp в новый abc.cpp [последняя копия рабочего каталога]?


person Rohan Nemaro    schedule 28.06.2012    source источник
comment
Примечание. git cherry-pick скоро (git 1.8.5/1.9) сможет выбирать из предыдущей ветки: см. мой ответ ниже.   -  person VonC    schedule 23.09.2013


Ответы (3)


Страница руководства git-cherry-pick(1) говорит:

Учитывая один или несколько существующих коммитов, примените изменения, которые вносит каждый, записывая новый коммит для каждого. Это требует, чтобы ваше рабочее дерево было чистым (без изменений из фиксации HEAD).

Проще говоря, это означает, что git cherry-pick применяет коммиты из одной ветки в другую, но не сохраняет исходную историю или родословную из другой ветки, как это сделало бы правильное слияние.

Думайте об этом как о применении серии выбранных исправлений, а не о полном слиянии двух ветвей истории. Очевидно, что если вы склонны делать очень маленькие, атомарные коммиты, то выбор вишни выглядит точно так же, как применение хорошо написанного патча. Однако, поскольку у вас нет общих предков, как при слиянии или перебазировании, у вас может быть гораздо больше конфликтов для разрешения, если ваши коммиты не маленькие и не изолированные.

Является ли выбор вишни хорошей идеей, во многом зависит от того, как вы структурируете свои коммиты. Если это не работает для вас, вы всегда можете сделать что-то вручную с помощью git format-patch и git apply.

person Todd A. Jacobs    schedule 28.06.2012

Да, это то, что он делает. cherry-pick применяет фиксацию (или их диапазон) в качестве исправления к вашей ветке (ну, почти как патч).

У вас могут возникнуть конфликты (например, при объединении веток), поскольку в ваших ветках произошли независимые модификации.

person CharlesB    schedule 28.06.2012
comment
Эм-м-м? Как слияние? Но он не записывает слияние, как это делает классическое слияние, поскольку это больше похоже на применение патча. См. предупреждение в stackoverflow.com/questions/881092/ - person VonC; 28.06.2012
comment
Я согласен, что сравнение некорректно, я хотел подчеркнуть, что вишневый выбор может иметь дело с двумя несвязанными модификациями, например, при слиянии. - person CharlesB; 28.06.2012
comment
Кроме того, вишневый выбор может использовать диапазон коммитов;) - person VonC; 28.06.2012
comment
Почти: вы можете упомянуть, что вишневый выбор не является точно патчем: stackoverflow.com/questions/5156459/ - person VonC; 28.06.2012

Обратите внимание, что с git1.8.5/1.9 (четвертый квартал 2013 г.), git cherry-pick теперь может легко выбирать вишни из предыдущей ветки:

Точно так же, как git checkout - знает, что нужно проверить, а git merge - знает, что нужно объединить ветку, в которой вы были ранее, git cherry-pick теперь понимает, что git cherry-pick - нужно выбрать из предыдущей ветки.

См. коммит 182d7d из Хирошиге Умино (яотти):

cherry-pick: разрешить - как сокращение от '@{-1}'

Аббревиатура - удобна для cherry-pick, например checkout и merge.

Для единообразия также полезно, чтобы - обозначало имя предыдущей ветки, где принимается имя ветки, и оно не может означать никаких других вещей, таких как стандартный ввод.

person VonC    schedule 23.09.2013