Git Cherry-pick против Merge Workflow

Question

Предполагая, что я поддерживаю репо, и я хочу получить изменения от участника, существует несколько возможных рабочих процессов:

1. I cherry-pick каждый коммит с пульта (по порядку). В этом случае git записывает коммит как не связанный с удаленной веткой.
2. I merge ветвь, извлекающая все изменения и добавляющая новую «конфликтную» фиксацию (при необходимости).
3. I merge каждый коммит из удаленной ветви по отдельности (снова по порядку), позволяющий записывать конфликты для каждого коммита, а не группировать все вместе как один.
4. Для полноты вы можете сделать rebase (тоже самое, что и cherry-pick опция?), Однако, насколько я понимаю, это может привести к путанице для участника. Может быть, это исключает вариант 1.

В обоих случаях 2 и 3 git записывает историю ветвлений коммитов, в отличие от 1.

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

Answer 1

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

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

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

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

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

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

Answer 2

По моему мнению, сбор вишни должен быть зарезервирован для редких ситуаций, когда это необходимо, например, если вы сделали какое-то исправление непосредственно в ветке 'master' (ствол, основная ветка разработки), а затем поняли, что это также следует на «обслуживание». Вы должны основывать рабочий процесс либо на слиянии, либо на rebase (или "git pull --rebase").

Пожалуйста, помните, что выбранный или перебазированный коммит отличается с точки зрения Git (имеет другой идентификатор SHA-1) от оригинала, поэтому он отличается от коммита в удаленном репозитории. (Обычно Rebase может справиться с этим, так как он проверяет идентификатор патча, т.е. изменения, а не идентификатор фиксации).

Также в git вы можете объединить сразу несколько веток: так называемое объединение осьминога . Обратите внимание, что слияние осьминога должно быть успешным без конфликтов. Тем не менее это может быть полезно.

НТН.

Answer 3

Rebase и Cherry-pick - единственный способ сохранить чистую историю коммитов. Избегайте использования слияния и избегайте конфликта слияния. Если вы используете Gerrit, установите один проект на Merge, если необходимо, и один проект в режиме cherry-pick и попробуйте сами.