Сохранение красивой истории коммитов. Зачем?

Если вопрос звучит как "зачем пользоваться cherry-pick, когда есть merge?", то ответ: незачем. Обычно ветки создают для изоляции работы над какой-нибудь фичей, и нет особого смысла "сплющивать" историю коммитов по окончании работы. Это скорее даже вредно, так как мешает отслеживать динамику разработки.

Если же вопрос звучит как "какие практические применения есть у cherry-pick?", то вот вам пару вариантов. Во-первых, можно случайно сделать коммит не в ту ветку, тогда cherry-pick поможет быстро и красиво исправить ситуацию. Во-вторых, предположим такую ситуацию: разработка ведётся одновременно в двух ветках, которые по каким-либо причинам пока нельзя смерджить, и нужно одновременно пофиксать баг в обеих. В этой ситуации cherry-pick снова выручает разработчика.

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

Git хорош тем, что позволяет решать одни и те же задачи различными путями, подстраивающимися под потребности и вкусы разработчика. Конкретная политика использования merge/cherry-pick/rebase может отличаться в разных проектах, поэтому чёткого ответа на ваш вопрос быть не может.

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

Что касается cherry-pick и rebase побочных веток перед слиянием - на мой взгляд это не лучший выбор, т.к. в угоду "красоте", теряется реальная история. Т.е подобным образом уменьшается возможность полноценного анализа причины и последовательности изменений.

Одна из причин для "причёсывания" коммитов - соблюдение некоего общего уровня гранулярности. Это даёт возможность отследить историю разработки с одной высоты обзора.

Удобство это примерно того же сорта, что и удобство от одинаковой глубины вызовов в коде в рамках одного метода. Или удобство от одинаковой гранулярности классов в пакете. Кажется, в программировании это называется принципом минимальной информированности.

В целом, история коммитов должна линейно провести нас по истории развития проекта от начала до текущего коммита. Или вопрос в том, какие именно практические задачи с помощью этой истории можно решить?

UPD. Кстати говоря, с переписыванием истории коммитов связана одна концептуальная проблема. И проблема эта - с корректностью переписанных коммитов. Предположим, навели красоту и сребэйзили ветку фичи с десятком коммитов в основную. В итоге может так оказаться, что попытка сборки каких-то коммитов из этого десятка закончится неудачей, несмотря на то, что головной коммит проходит всю интеграцию. В этом случае выходит не такая уж и красивая история. Вот что с этим делать?

По поводу целесообразности красивой истории коммитов в принципе: это дает ряд преимуществ:

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

2) уменьшить количество конфликтов при слиянии

Далее по поводу cherry-pick - обычно он служит для того чтобы выдернуть одиночный коммит из одной ветки в другую. Для обеспечения красивой истории чаще используется rebase, ну или его разновидность в купе с pull: git pull -r