Часто у разработчиков есть выбор между Merge и Rebase. В Google вы увидите разные мнения, многие советуют не использовать Rebase, поскольку это может вызвать серьезные проблемы.
В этой статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) их использовать и как это сделать.
Git Merge и Git Rebase преследуют одну и ту же цель.
Они предназначены для интеграции изменений из одной ветки в другую.
Хотя конечная цель одна и та же, принципы работы разные.
Некоторые считают, что всегда следует использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.
Git-слияние
Слияние — обычная практика для разработчиков, использующих системы контроля версий.Независимо от того, создаются ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте.
Слияние берет содержимое исходной ветки и объединяет его с целевой веткой.
В этом процессе изменяется только целевая ветвь.
История первоначальных ветвей осталась неизменной.
Плюсы:
- простота;
- сохраняет полную историю и хронологический порядок;
- поддерживает контекст ветки.
- История коммитов может быть заполнена (загрязнена) множеством коммитов;
- Отладка с помощью git bisect может стать более сложной.
Это создаст новую «фиксацию слияния» в ветке функции, содержащую историю обеих ветвей.$ git checkout feature $ git merge master (or) $ git merge master feature
Git перебазировать
Rebase — это еще один способ перемещения изменений из одной ветки в другую.Rebase сжимает все изменения в один «патч».
Затем он интегрирует патч в целевую ветку.
В отличие от слияния, ход переписывает историю, поскольку завершенная работа переносится из одной ветки в другую.
При этом нежелательная история удаляется.
Плюсы:
- Упростите потенциально сложную историю
- Упрощение манипуляций с одним коммитом
- Как избежать слияния коммитов в загруженных репозиториях и ветках
- Очищает промежуточные коммиты в один, что полезно для команд DevOps.
- Сжатие функций в несколько коммитов может скрыть контекст.
- Перемещение публичных репозиториев может быть опасным при работе в команде
- Появляется больше работ
- Восстановление с удаленными ветками требует принудительного нажатия.
Это приводит к тому, что все ветки с одинаковым именем обновляются как локально, так и удаленно, и это ужасно.
$ git checkout feature
$ git rebase master
Это перемещает всю ветку функций в главную ветку.
История проекта меняется, создавая новые коммиты для каждого коммита в основной ветке.
Интерактивное движение
Это позволяет изменять коммиты при их перемещении в новую ветку.Это лучше, чем автоматическое перемещение, поскольку дает вам полный контроль над историей коммитов.
Обычно используется для очистки истории перед объединением функциональной ветки с основной.
$ git checkout feature
$ git rebase -i master
Откроется редактор со списком всех коммитов, которые будут перемещены.
pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3
Это точно определяет, как будет выглядеть ветка после завершения перемещения.
Расставляя предметы, вы можете сделать историю такой, какой захотите.
Вы можете использовать команды исправить , давить , редактировать , и так далее.
Какой из них мне следует использовать?
Так что же лучше? Что рекомендуют эксперты? Принять единое правильное решение о том, что лучше использовать, сложно, так как все команды разные.Все зависит от потребностей и традиций внутри коллектива.
Принимайте решения на основе компетентности команды в Git. Для вас важна простота или переписывание истории, а может быть, что-то еще? Что я рекомендую? По мере роста команды становится сложнее управлять или отслеживать изменения в процессе разработки с помощью слияния.
Чтобы иметь чистую и понятную историю коммитов, разумно использовать Rebase. Преимущества перебазирования:
- Вы разрабатываете локально: если вы не поделились своей работой с кем-либо еще.
На данный момент вам следует выбрать перемещение, а не слияние, чтобы сохранить вашу историю в порядке.
Если у вас есть личная вилка репозитория, которая не используется совместно с другими разработчиками, вы можете выполнить перебазирование даже после того, как перешли в свою собственную ветку.
- Ваш код готов к проверке: вы создали запрос на включение.
Другие анализируют вашу работу и, возможно, отправляют ее на локальное рассмотрение.
В это время вам не следует перемещать свою работу.
Вы должны создать коммит «повторить» и обновить ветку.
Это помогает отслеживать запросы на включение и предотвращает случайное повреждение истории.
- Проверка завершена и готова к интеграции в целевую ветку.
Поздравляем! Вы собираетесь удалить свою ветку функций.
Учитывая, что отныне другие разработчики не будут объединять эти изменения, это ваш шанс изменить свою историю.
На этом этапе вы можете переписать историю и сбросить исходные коммиты, и эти надоедливые «переделки» и «слияния» сольются в небольшой набор целенаправленных коммитов.
Выполнение явного слияния для этих коммитов не является обязательным, но имеет значение.
Он записывает, когда функция достигла ведущего устройства.
Не забудь: code = coffee + developer
Теги: #git #merge #rebase #система контроля версий
-
Компьютерная Мышь От Bmw.
19 Oct, 24 -
О Летней Стажировке В Jetbrains
19 Oct, 24
