Когда вы мерджите пул-реквест на GitHub, у вас есть три опции: merge commit, squash или rebase.
Можно ли просто всегда делать merge commit? Конечно можно! Но применение других стратегий может принести вам некоторые преимущества.
От редакции Techrocks. О том, что такое пул-реквест, можно почитать в статье «Что такое пул-реквесты и зачем они нужны?». О том, как сделать пул-реквест на GitHub, — в статье «Как сделать первый пул-реквест на GitHub».
В следующем видео я подробно рассказываю обо всех трех подходах. Если вам интересно, я рекомендую посмотреть видео, в противном случае можно почитать полный текст ниже.
Закрываем пул-реквест на GitHub при помощи merge commit
Merge commit, вероятно, используется чаще всего, поскольку это опция по умолчанию на GitHub, а также поведение по умолчанию при использовании git merge вручную.
История всех ваших коммитов остается нетронутой, а в основной ветке вы видите дополнительный коммит, который объединяет все содержимое вашей ветки.
Самое большое преимущество merge commit заключается в том, что вы можете легко отследить коммит, в котором была изменена строка. Конечно, при условии, что коммитов не слишком много.
У этого подхода есть и недостаток. Когда несколько коммитов находятся в нескольких ветках, история быстро становится очень запутанной, и отследить путь изменения может быть довольно сложно.
Закрываем пул-реквест на GitHub при помощи squash merge
Вопрос в том, действительно ли вам нужно отслеживать каждый отдельный коммит? Включая исправление опечаток, добавление пропущенных файлов, форматирование… Если нет, то вам стоит рассмотреть вариант squash merge.
При таком подходе вы избавляетесь от всех коммитов в ветке и добавляете только один коммит со всем содержимым в main.
В результате история становится намного чище. Работая над веткой, вы можете делать любые коммиты, так как знаете, что со сквошем все ваши грехи будут забыты. Вроде как.
Противники squash merge обычно возражают, что вы теряете довольно большую часть истории коммитов. Но это вам решать, считаете ли вы коммиты в ветке ценными для просмотра в дальнейшем или это просто шум.
Закрываем пул-реквест на GitHub при помощи rebase
Третий вариант подходит для ситуаций, когда вы хотите иметь все коммиты на одной прямой линии, но вам не нужен коммит, указывающий на то, что произошло слияние.
От редакции Techrocks. О том, что такое rebase, можно почитать в статье «Простое объяснение Git Rebase».
Merge commit дает вам все запутанные линии плюс дополнительный коммит, squash — прямую линию, но с потерей истории. А вот rebase и историю сохраняет, и линию оставляет прямой, и не требует дополнительного коммита для слияния.
Делает ли это rebase самой лучшей стратегией? Не обязательно, потому что у такого подхода есть потенциально разрушительные побочные эффекты.
Если вы получите конфликт слияния во время ребейзинга, то можете довольно легко потерять части кода. А если вам нужно подхватить несколько коммитов, то в итоге может потребоваться разрешать конфликт слияния для каждого отдельного коммита, а не только для одного, как при других стратегиях.
От редакции Techrocks. О конфликтах слияния читайте в статье «Как разрешить конфликт слияния».
Мои пять копеек
На мой взгляд, если ветки не остаются открытыми в течение длительного времени, то squash merge — хороший вариант. Я не являюсь поклонником rebase, потому что слишком легко сделать огромные ошибки. Но прежде чем выбрать стратегию, нужно обдумать несколько моментов.
Например, как часто вам и вашей команде приходится возвращаться к старым коммитам? Сколько членов в команде? Нужна ли вашему CI полная история коммитов?
Подумайте об этом, обсудите с командой, и вы сможете вместе найти лучшую стратегию для вашего конкретного случая.
Настройки GitHub
Если вы хотите применять на GitHub только определенные стратегии слияния, зайдите в настройки вашего репозитория и прокрутите страницу немного вниз.
Здесь вы найдете три раздела, позволяющие разрешить merge commit, squash или rebase в ваших пул-реквестах.
Если выбрать только одну опцию, все пул-реквесты в вашем репозитории будут мерджиться с использованием этой конкретной стратегии.
Для первых двух вариантов вы также можете определить сообщение коммита по умолчанию. Оно может браться из пул-реквеста или из коммитов в ветке в случае squash.
Как видите, rebase не имеет этой опции, и причина проста. Rebase не создаёт дополнительный коммит для слияния, поэтому здесь ничего не нужно делать. Существующие коммиты просто перемещаются к head вашей ветки.
И раз уж вы зашли на эту страницу, прокрутите ее еще немного вниз. Возможно, вы также захотите установить этот флаг для автоматического удаления веток после мерджа пул-реквеста.
Спасибо, что прочитали эту статью, надеюсь, она показалась вам интересной!
Перевод статьи «How to Close a Pull Request — Merge Commit vs Squash vs Rebase on GitHub».
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]