Руководство по закрытию запроса на слияние — Merge Commit vs Squash vs Rebase на GitHub
git github pull-requests merge

Руководство по закрытию запроса на слияние — Merge Commit vs Squash vs Rebase на GitHub

11 января 2023 г.

При объединении запроса на слияние на GitHub у вас в основном есть три варианта: с фиксацией слияния, сквошом или перебазированием.

Pull Request Options: Merge, Squash and Rebase

Есть ли что-то неправильное в том, чтобы всегда делать фиксацию слияния? Что ж, здесь нет правильного или неправильного, но рассмотрение других стратегий может принести вам некоторые преимущества. Позвольте мне объяснить вам, почему.

https://youtu.be/rFRtsiQEJZw?embedable=true

:::подсказка В видео я подробно расскажу о трех стратегиях, а также сделаю «живую демонстрацию» со стикерами GitHub и пинами JS. Если вам интересно, я рекомендую вам посмотреть видео, в противном случае вы можете найти полный текст здесь ниже.

:::

Объединить фиксацию

Коммит слияния, вероятно, является наиболее распространенным, так как это вариант по умолчанию на GitHub, а также поведение по умолчанию, когда вы вручную используете git merge.

История всех ваших коммитов остается нетронутой, а в основной ветке вы видите дополнительную фиксацию, которая объединяет все содержимое вашей ветки.

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

Недостатком является то, что когда несколько коммитов находятся в нескольких ветвях, история быстро становится действительно запутанной, и отслеживание пути изменения может быть довольно сложной задачей.

Merge demo (all commits are kept + 1 merge commit)

Слияние сквоша

Вопрос в том, действительно ли вам нужно отслеживать каждую фиксацию? Включая опечатки, отсутствующие файлы и форматирование... если ответ отрицательный, вам следует подумать о слиянии Squash.

При сжатии слияния вы избавляетесь от всех коммитов в ветке и добавляете только один коммит на основной со всем содержимым.

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

Кто не любит сквош-слияние, обычно упоминает тот факт, что вы теряете много истории коммитов, но вам решать, считаете ли вы коммиты в ветке ценными при просмотре старой активности или, скорее, просто шумом.

Squash Demo (all commits from the feature branch are merged into one commit on main)

Перебазировать

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

В коммите слияния есть все запутанные строки плюс дополнительная фиксация, Squash — это прямая линия, но теряет историю, поэтому здесь появляется Rebase, который сохраняет историю И прямую линию И не требует дополнительной фиксации для слияния.

Делает ли это Rebase лучшей стратегией? Ну... на самом деле не обязательно, потому что это может иметь некоторые потенциально разрушительные побочные эффекты.

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

Rebase demo (all commits from the feature branch are moved to main)

Мои два цента

Что вы думаете после этого обзора? Дайте мне знать в комментариях!

На мой взгляд, если ветки не остаются открытыми в течение длительного времени, сквош-слияние — хороший вариант, также я не сторонник перебазирования, потому что слишком легко сделать огромные ошибки. Но прежде чем решить, какую стратегию применить, следует принять во внимание некоторые соображения.

Например, как часто вам и вашей команде приходится оглядываться на старые коммиты? Сколько участников в команде? Нужна ли вашему CI полная история коммитов?

Подумайте об этом, поговорите со своей командой, и вместе вы сможете найти наилучшую стратегию для своего варианта использования.

На самом деле, хорошей стратегией может быть подписка на мой канал YouTube, если вам нравится мой контент!

Конфигурация

Если вы хотите применить только некоторые стратегии слияния на GitHub, перейдите к настройкам своего репозитория и немного прокрутите вниз.

Здесь вы найдете три раздела, позволяющие разрешить слияние, сквош или перебазирование в ваших запросах на вытягивание.

GitHub Pull Requests settings with merge options

Если вы оставите выбранным только один, все PR в вашем репозитории будут объединены с этой конкретной стратегией.

Для первых двух вы также можете определить сообщение коммита по умолчанию, которое может брать информацию из PR или коммитов в ветке в случае сквоша.

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

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

GitHub setting to delete a branch once the Pull Request is merged

Закрытие

Заинтересованы в фотографиях со значками и значками? Живая демонстрация находится в этом видео на YouTube.

Но как насчет вас и вашей команды, как вы закрываете свои запросы на слияние? Если у вас есть какие-либо предпочтения или вы хотите поделиться своим опытом, оставьте комментарий, я буду очень рад услышать от вас!

:::информация Также опубликовано здесь.

:::

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE