✅ Git ReBase против слияния - Топ-5 Сравнение Git ReBase и Merge

Разница между Git ReBase и Merge

Разница между Git ReBase и Merge

В этой статье мы обсудим два таких инструмента Rebase и Merge и их различие. GIT является одним из наиболее часто используемых распределенных контроллеров версий DVCS среди программистов из-за его динамической природы и широкой доступности инструментов для управления версиями. Есть два способа отправить наши изменения из одной ветки в другую. Одним из них является использование Rebase, а другим - Merge, который довольно популярен. Ниже мы узнаем лучшее сравнение между Git ReBase и Merge.

Личное сравнение между Git ReBase и Merge (Инфографика)

Ниже приведены 5 лучших сравнений между Git ReBase и Merge:

Ключевые различия между Git ReBase и Merge

Давайте обсудим ключевое различие между Git ReBase и Merge:

1. Git Rebase

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

Давайте представим, что у нас есть основная ветка и последний коммит в нее, как показано на скриншоте выше. Из этого коммита мы создаем ветку объектов и сделали некоторые изменения и зафиксировали сообщение f1. Теперь давайте рассмотрим, кто-то объединил свою работу с мастером, и теперь последний коммит мастера - это м3, а не м2, как показано ниже.

И мы также продолжаем работать над веткой feature, чтобы добавить ее последний коммит в f2, как показано ниже.

Как видно из скриншота выше, мы освоили последний коммит m3, и у нас есть функция, которая не соответствует мастеру, так как он был создан из моментального снимка коммита m2, который имеет последний коммит f3. Теперь объединить эти усилия с мастером для генерации показано ниже.

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

$ git checkout feature Switched to a new branch 'feature' $ git rebase master

В приведенной выше команде rebase мы попытаемся найти общий коммит как для master, так и для feature, и в этом случае это m2. И затем, так как нам нужно перебазировать master, он будет искать дополнения, которые были сделаны с master, и снимать снимок m3 и перебазировать функцию с m2 на m3. Так что теперь у нас есть функция с m3 (вместо m2), f1, f2 фиксирует. Теперь я могу подать заявку на ребазирование функции, чтобы обновлять основную ветку с изменениями функции. Одна вещь, которую нужно помнить, - любое изменение мастера должно быть проверено. Здесь я просто показываю для примера цель.

$ git checkout master Switched to a new branch 'master' $ git rebase feature

Теперь мы применим последнюю ветвь функции фиксации, f2, к мастеру, а последним моментальным снимком фиксации мастера будет f2. Вы можете получить список коммитов с помощью команды git log, но сначала нам нужно проверить, в какую ветку нам нужно посмотреть журнал, как показано ниже.

$ git checkout feature Switched to a new branch 'feature' $ git log

Теперь с rebase мы интегрировали обновления функции в master. Давайте попробуем достичь этого путем слияния.

2. Git Merge

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

Git merge фиксирует последний коммит, который был у нас в ветви функций, и здесь мы имеем дело с коммитом f2, который собирает все изменения и объединяет его с последним коммитом, который мы имеем в основной ветке, m3 здесь. Это выглядит сложно, но может быть легко выполнено командой слияния. Мы можем сделать прямое слияние или сквош-слияние и разницу в обоих.

$ git checkout master Switched to a new branch 'master' $ git merge feature

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

$ git checkout master Switched to a new branch 'master' $ git merge –squash feature

нужно быть осторожным при использовании git rebase и стараться избегать его. Золотое правило состоит в том, чтобы избегать этого, используя публичные ветки.

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

Сравнительная таблица Git ReBase против Merge

В таблице ниже приведены сравнения между Git ReBase и Merge:

Основа сравнения Rebase против Merge	Rebase	Объединить
Фиксации	Он изменяет и переписывает историю, создавая новый коммит для каждого коммита в исходной ветке.	Он включает в себя все изменения в источнике, но поддерживает происхождение каждой истории изменений, включает в себя все изменения в источнике, но поддерживает происхождение каждой истории изменений.
выбор	Здесь мы сначала проверяем ветку, которую нужно перебазировать, затем выбираем команду rebase добавить его обновления другим.	Здесь сначала проверьте ветку, которая должна быть объединена первой. Затем выполните операцию слияния и последний коммит источника будет объединен с последним коммитом мастера.
Урегулирование конфликтов	Поскольку история коммитов будет переписана, чтобы понять конфликт, будет трудно некоторые случаи.	С конфликтом слияния можно легко справиться, поняв ошибку, которая была допущена при слиянии.
Золотое правило	Следует использовать на общедоступных ветках, поскольку история коммитов может вызвать путаницу.	Никакого вреда при выполнении публичных веток.
достижимость	Коммиты, которые когда-то были доступны, больше не будут доступны после перебазирования, так как история изменений была изменена.	Коммиты останутся доступными из исходных веток.

Вывод

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

Git ReBase против слияния - Топ-5 Сравнение Git ReBase и Merge

Разница между Git ReBase и Merge

Личное сравнение между Git ReBase и Merge (Инфографика)