Слияние Git или перебазирование git?

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

Вышеизложенное является хорошим резюме!

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

git rebase помещает список коммитов в ветвь поверх другой ветви. Таким образом, разрешение конфликтов выполняется для каждого коммита в порядке, который вы определяете (если использовать --interactive), и если у вас нет их чисто ортогональных, каждый ваш коммит может создавать конфликты (т. е.: коммиты могут быть неприменимы, потому что каждый из них применяется индивидуально). обратите внимание , что вы также можете объединить несколько коммиты в один - так называемый раздавливающий - при ребазинге.

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

• ours: Эта опция заставляет конфликтующие куски автоматически разрешаться чисто, отдавая предпочтение нашей версии.
• octopus: это разрешает случаи с более чем двумя головками, но отказывается делать комплекс слияние, которое требует ручного разрешения.
• subtree: это модифицированная рекурсивная стратегия. При слиянии деревьев A и B, если B соответствует поддереву A, B сначала настраивается в соответствии с древовидной структурой A, а не считывает деревья на одном уровне.

Как говорится, a rebase - это только вариант, когда никто не видел ваших изменений, поскольку это изменит хэши фиксации и слияние всегда применимо. Также обратите внимание, что если у вас есть процесс пересмотра перебазирования дает вам возможность изменить историю изменений, чтобы отразить ваши намерения в журналах.

Я думаю, что это эссе от Git Bucket даст вам ответ.

Слияния и перебазирования

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

Слияние-это хорошо, потому что это неразрушающая операция. Существующие ветви никак не меняются. Это позволяет избежать всего из потенциальных опасностей перебазировки (см. ниже).

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

Основное преимущество перебазирования является то, что вы получаете намного чище историю проекта. Во-первых, он устраняет ненужные коммиты слияния, необходимые для слияния git. Во-вторых, как вы можете видеть на приведенной выше диаграмме, перебазирование также приводит к совершенно линейной истории проекта-вы можете следовать подсказке функции до самого начала проекта без каких-либо развилок. Это упрощает навигацию по проекту с помощью таких команд, как git log, git bisect и gitk.

Но, есть два компромисса для этого первозданного история фиксации: безопасность и прослеживаемость. Если вы не будете следовать золотому правилу перебазирования, переписывание истории проекта может привести к катастрофическим последствиям для вашего рабочего процесса совместной работы. И, что менее важно, ребазинг теряет контекст, предоставляемый коммитом слияния-вы не можете видеть, когда в функцию были включены восходящие изменения.