Избирательный подход мерзавца по сравнению с рабочим процессом слияния

Как rebase (и cherry-pick ), так и объединить имеют свои преимущества и недостатки. Я выступаю за merge здесь, но стоит понимать и то, и другое. (Здесь можно найти альтернативный, хорошо аргументированный ответ с перечислением случаев, когда rebase предпочтительнее.)

merge предпочтительнее cherry-pick и перебазировать по нескольким причинам:

1. Надежность . Идентификатор SHA1 коммита идентифицирует его не только сам по себе, но также по отношению к всем другим коммитам, которые ему предшествуют. Это дает вам гарантию того, что состояние репозитория для данного SHA1 идентично для всех клонов. Нет (теоретически) шансов, что кто-то сделал то же самое изменение, но на самом деле повредил или захватил ваш репозиторий. Вы можете выбрать отдельные изменения, и они, вероятно, будут одинаковыми, но у вас нет гарантии. (В качестве второстепенной второстепенной проблемы новые выбранные коммиты займут дополнительное место, если кто-то еще раз выберет вишню в том же коммите, поскольку они оба будут присутствовать в истории, даже если ваши рабочие копии в конечном итоге будут идентичными.)
2. Простота использования . Люди обычно довольно легко понимают рабочий процесс слияние . rebase обычно считается более продвинутым. Лучше понять и то, и другое, но люди, которые не хотят быть экспертами в области контроля версий (в том числе, по моему опыту, было много коллег, чертовски хороших в том, что они делают, но не не хочу тратить лишнее время) проще просто слияние.

Даже с тяжелым рабочим процессом слияния rebase и cherry-pick по-прежнему полезны в определенных случаях:

1. Обратной стороной слияния является загроможденная история. rebase предотвращает разброс длинных серий коммитов по вашей истории, как это было бы, если бы вы периодически сливали изменения с другими. Фактически, это его основная цель, поскольку я его использую. Вы хотите быть очень осторожным: никогда не перебазировать код, которым вы поделились с другими репозиториями. Как только фиксация push ed, кто-то другой мог выполнить фиксацию поверх нее, и перебазирование в лучшем случае вызовет вид дублирования, описанный выше. В худшем случае вы можете получить очень запутанный репозиторий и скрытые ошибки, на поиск которых у вас уйдет много времени.
2. cherry-pick полезен для выборки небольшого подмножества изменений из тематической ветки, которую вы ' По сути, я решил отказаться, но понял, что есть пара полезных вещей.

Что касается предпочтения слияния нескольких изменений вместо одного: это намного проще. Слияние отдельных ревизий может оказаться очень утомительным, если у вас их много. Разрешение слияния в git (и в Mercurial, и в Bazaar) очень хорошее. В большинстве случаев вы не столкнетесь с серьезными проблемами при объединении даже длинных ветвей. Обычно я объединяю все сразу и только , если я получаю большое количество конфликтов, я создаю резервную копию и повторно запускаю слияние по частям. Даже тогда я делаю это большими кусками. В качестве очень реального примера у меня был коллега, у которого было 3 месяца внесения изменений для слияния, и он получил около 9000 конфликтов в 250000 строк кода. Что мы сделали, чтобы исправить, так это сделать слияние ежемесячно: конфликты не накапливаются линейно, а выполнение его по частям приводит к гораздо менее чем 9000 конфликтов. Работы по-прежнему требовалось много, но не настолько, чтобы пытаться делать это по одной за раз.