Ответ 1
Оба rebase (и cherry-pick) и merge имеют свои преимущества и недостатки. Я утверждаю, что здесь merge, но стоит понять и то, и другое. (Посмотрите здесь альтернативный, хорошо аргументированный ответ , перечисляющий случаи, когда rebase является предпочтительным.)
merge предпочтительнее cherry-pick и rebase по нескольким причинам.
- грубости. Идентификатор SHA1 фиксации идентифицирует его не только сам по себе, но и по отношению ко всем другим коммитам, которые предшествуют ему. Это дает вам гарантию того, что состояние репозитория в данном SHA1 идентично для всех клонов. Существует (теоретически) отсутствие шансов, что кто-то сделал то, что похоже на одно и то же изменение, но на самом деле искажает или захватывает ваш репозиторий. Вы можете вишнево выбирать в индивидуальных изменениях, и они, вероятно, одинаковы, но у вас нет никакой гарантии. (В качестве второстепенной вторичной проблемы новые захваченные вишни коммиты будут занимать дополнительное место, если кто-то еще вишневый выбирает в том же комманде снова, поскольку они оба будут присутствовать в истории, даже если ваши рабочие копии в итоге совпадают.)
- Простота использования. Люди склонны легко понимать рабочий процесс
merge.rebaseимеет тенденцию считаться более продвинутым. Лучше всего понять и то, и другое, но люди, которые не хотят быть экспертами в области контроля версий (которые по моему опыту включали многих коллег, которые чертовски хороши в том, что они делают, но не хотят тратить дополнительное время), легче время просто сливается.
Даже в случае слияния с тяжелыми рабочими потоками rebase и cherry-pick все еще полезны для конкретных случаев:
- Один недостаток
merge- загроможденная история.rebaseпредотвращает разброс длинной серии коммитов в вашей истории, как если бы вы периодически сливались в другие изменения. Это и есть его основная цель, поскольку я использую ее. То, что вы хотите быть очень осторожным, никогда не относится к кодуrebase, который вы поделили с другими репозиториями. После фиксацииpushed кто-то еще мог бы сделать это поверх нее, а перезагрузка в лучшем случае приведет к описанному выше дублированию. В худшем случае у вас может быть очень запутанный репозиторий и тонкие ошибки, на которые уходит много времени, чтобы выведать. -
cherry-pickполезен для отбора небольшого подмножества изменений из ветки темы, которую вы в основном решили отбросить, но понял, что есть несколько полезных фрагментов.
Что касается предположения о слиянии многих изменений над одним: это намного проще. Может быть очень утомительно делать слияния отдельных наборов изменений после того, как вы начнете их много. Разрешение слияния в git (и в Mercurial, и на Bazaar) очень хорошее. Вы не столкнетесь с серьезными проблемами слияния даже длинных ветвей большую часть времени. Я вообще объединяю все все сразу, и только если я получаю большое количество конфликтов, я возвращаюсь и повторно запускаю слияние по частям. Даже тогда я делаю это в больших кусках. В качестве очень реального примера у меня был коллега, у которого было 3 месяца изменений, чтобы объединиться, и получил около 9000 конфликтов в 250000 строк кода. То, что мы сделали, чтобы исправить, заключается в том, чтобы объединить один месяц за раз: конфликты не растут линейно, а в результате получается намного меньше, чем 9000 конфликтов. Это была еще большая работа, но не так много, как попытка сделать это за один раз.