Git Cherry-pick vs Merge Workflow

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

merge предпочтительнее cherry-pick и rebase по нескольким причинам.

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

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

1. один недостаток merge суматоху истории. rebase предотвращает рассеивание длинной серии коммитов в вашей истории, как это было бы, если бы вы периодически сливались с изменениями других. Это и есть его главная цель, как я ее использую. Что ты хочешь? будь очень осторожно, никогда не rebase код, который вы поделились с другими репозиториями. После фиксации pushed кто-то другой мог совершить поверх него, и перебазирование в лучшем случае вызовет дублирование, о котором говорилось выше. В худшем случае вы можете получить очень запутанный репозиторий и тонкие ошибки, которые вам потребуется много времени, чтобы выследить.
2. cherry-pick полезно для выборки небольшого подмножества изменений из ветви темы, которую вы в основном решил отказаться, но понял, что есть пара полезных штук на.

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