Отслеживание слияния для выбора вишни в Git?

Также примечательно, что флаг -x для cherry-pick добавляет SHA исходного коммита в конец сообщения коммита.

Мне также нравится добавлять сокращенный SHA в конец сводки коммитов, чтобы было проще связать выбранный вишней коммит с оригиналом при просмотре журнала. Также может быть полезно указать, кто выбрал вишню, с помощью флажка -s.

Пример:

> git cherry-pick -sex 27d4985

#333: fixes all the things (27d4985)

- how it fixes all the things

(cherry picked from commit 27d49855238364d0184ad344884a366b5b16e)

Signed-off-by: Chuck Norris <chuck@example.com>

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

git merge, с другой стороны, создает коммит слияния; это средство, с помощью которого git осуществляет отслеживание слияний. Фиксация слияния отмечает точку, в которой две (или более) расходящиеся истории сошлись. Приемлемо вызывать git merge [commit-id] вместо git cherry-pick [commit-id] для явного создания коммита слияния, но это приводит не только к эффектам одного выбранного вишни коммита, но и ко всему набору изменений в расходящейся истории этой ветви.

Учитывая все сказанное, «двойное слияние» обычно не является проблемой в git. Если вы попытаетесь объединиться с историей, которая содержит набор изменений, который уже присутствует, он просто станет недоступным, когда истории будут склеены; git действительно заботится только о состоянии дерева в каждом коммите, а не об изменениях, которые привели его в это состояние.