Должен ли я сжать и объединить, перебазировать и объединить или просто сделать фиксацию слияния?
Создать коммит слияния?
Сквош и слияние?
Изменить базу и объединить?
Что все они означают? Когда я должен использовать одно вместо другого?
Если вы похожи на меня, вам приходилось сталкиваться с разными репозиториями на GitHub, где разработчики работают по-разному. Некоторые люди очень придерживаются мнения о том, как следует объединять запросы на включение, в то время как другие - нет, если работа хорошо документирована.
Я собираюсь разобрать каждый доступный метод слияния, предлагаемый в GitHub. Надеюсь, мы сможем уменьшить путаницу и конфликты из-за двух сторон объединяющей ограды.
Давайте рассмотрим некоторые плюсы и минусы.
Создать коммит слияния
Это параметр слияния GitHub по умолчанию при открытии запроса на перенос. Этот метод берет все коммиты внутри вашей ветки и объединяет их, создавая еще один новый коммит, называемый «коммит слияния».
Этот метод создаст совершенно новую фиксацию в истории фиксации ветки, в которую вы выполняете слияние. По умолчанию фиксация будет выглядеть довольно обобщенно, говоря что-то вроде merging pull request <pr>. Не очень наглядно.
Да, вы можете посмотреть исходный запрос на перенос, чтобы увидеть коммиты внутри него, но это требует дополнительных действий. Если есть что-то, что ненавидят разработчики, так это дополнительные шаги.
Этот метод полезен, если у вас очень активная ветка, с которой вы выполняете слияние. Возможность заключить коммиты в один коммит имеет преимущества при работе с большим объемом коммитов, но скрывает основные изменения.
Это эквивалент этого метода слияния в командной строке:
git merge --no-ff
Сквош и слияние
Этот метод принимает коммиты внутри вашего запроса на вытягивание и «сжимает» их в одну фиксацию. У вас есть возможность отредактировать сообщение о фиксации и включить детали, которые вы хотите из сжатых коммитов.
Этот метод более понятен в истории Git, чем создание коммитов слияния, но он по-прежнему полагается на слияние одного комбинированного коммита. Сжатие полезно, когда у вас есть много мелких или произвольных коммитов, которые могут не требовать полноценного сообщения о фиксации. Сжатие не так полезно, когда у вас есть более крупная функция, фиксирующая ветку, которую вы можете захотеть объединить по отдельности.
Эквивалент этого метода слияния в командной строке:
git merge --ff-only
Перебазировать и объединить
Это то, чего вы ждали (возможно). С Rebase и merge вы можете взять все эти прекрасные коммиты в свою ветку и объединить их один за другим в целевую ветку. Никаких коммитов слияния, никаких сжатий - просто возьмите все существующие коммиты и примените их к ветке.
Этот метод полезен, когда вы хотите поддерживать более чистую историю git с полной информацией обо всех коммитах в вашем запросе на перенос. Если вы делаете значительные коммиты с подробными сообщениями в ветке и хотите, чтобы они были элегантно объединены для сохранения деталей, это метод, который следует использовать.
Чтобы выполнить этот тип слияния в командной строке, вы должны сделать что-то подобное:
git checkout <feature_branch> git rebase <target_branch>
Заключение
Слияние кода может быть запутанным, сложным и временами очень напряженным. Git - не самый простой инструмент в мире, и иногда он снова укусит вас, когда вы не будете осторожны. GitHub предлагает разные методы слияния для разных вариантов использования. Надеюсь, после изучения каждого из этих методов вы сможете лучше определить лучший метод для вашей среды.
Если вам нужна более подробная информация о каждом из методов слияния, GitHub предлагает их фантастический обзор на своем сайте поддержки. Кроме того, применить эти методы с административной точки зрения на GitHub очень просто. Ознакомьтесь с разделом Требование линейной истории коммитов для получения дополнительной информации о том, как настроить.
Спасибо за внимание! Я надеюсь, что я немного избавился от путаницы, связанной с этими методами слияния, и вы почувствуете себя более уверенно, выбирая один из них для своих собственных репозиториев.
