Учебник по Git Rebase

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

Git Rebase: определения

Согласно документации git, команда rebase повторно применяет коммиты поверх другой базовой подсказки. Это определение может показаться немного сложным. Проще объяснить rebase как процедуру, которая добавляет изменения текущей ветки в хвост другой ветки. Давайте рассмотрим пример, чтобы лучше понять, что происходит.

Пример изменения базы данных Git

В этом примере мы сначала создадим тестовый пример с ветвями master и feature. Затем сделаем стандартное слияние. Затем мы воссоздадим тестовый пример и выполним перебазирование и слияние.

1. Создание основных и функциональных ветвей

Вот сценарий, который мы создадим:

A - B - C (мастер) \ E - F (функция) 

В приведенном выше примере мы идем по следующему пути:

1. Коммит A: мы добавляем.txt в ветке master

2. Коммит B: добавляем b.txt в ветке master

3. На этом этапе мы создаем ветку 'feature', что означает, что она будет иметь.txt и b.текст

4. Коммит C: добавляем c.txt в ветке master

5. Заходим в ветку 'особенность'

6. Коммит E: мы изменяем.txt в ветке 'feature'

7. Коммит F: модифицируем b.txt в ветке 'feature'

Вы можете создать папку и запустить следующий код внутри папки, чтобы создать описанную выше ситуацию:

git init коснитесь.txt git add -A git commit -m "Commit A: добавлен.txt "коснитесь b.txt git add -A git commit -m "Commit B: добавлено b.txt "git branch feature touch c.txt git add -A git commit -m "Commit C: добавлено c.txt "git status git checkout feature echo aaa> a.txt git add -A git commit -m "Commit E: изменен.txt "echo bbb> b.txt git add -A git commit -m "Commit F: изменено b.текст" 

2. Простое слияние

Давайте воспользуемся командой log, чтобы проверить обе ветки.

Результаты для 'master':

$ git checkout master Перешел на ветку master $ git log --oneline 2bbde47 Коммит C: добавлен c.txt b430ab5 Коммит B: добавлен b.txt 6f30e95 Коммит A: добавлен.txt $ ls a.txt b.txt c.текст 

Результаты по запросу "функция":

Функция $ git checkout переключена на ветку 'feature' $ git log --oneline 0286690 Commit F: изменено b.txt 7c5c85e Коммит E: изменен.txt b430ab5 Коммит B: добавлен b.txt 6f30e95 Коммит A: добавлен.txt $ ls a.txt b.текст 

Обратите внимание, что в функциональной ветке нет фиксации C

Теперь давайте запустим ветку слияния 'feature' с веткой 'master'. Вам будет предложено ввести комментарий. В начале комментария добавьте «Commit G:», чтобы упростить отслеживание.

$ git checkout master Переключился на ветку master. $ git merge. Слияние с помощью рекурсивной стратегии. а.txt | 1 + б.txt | 1 + 2 файла изменено, 2 прошивки (+) 

Результаты для 'master':

 $ git checkout master Уже в 'master' $ git log --oneline d086ff9 Commit G: слияние ветки 'feature' 0286690 Commit F: изменено b.txt 7c5c85e Коммит E: изменен.txt 2bbde47 Коммит C: добавлен c.txt b430ab5 Коммит B: добавлен b.txt 6f30e95 Коммит A: добавлен.txt $ ls a.txt b.txt c.текст 

Результаты по запросу "функция":

Функция $ git checkout переключена на ветку 'feature' $ git log --oneline 0286690 Commit F: изменено b.txt 7c5c85e Коммит E: изменен.txt b430ab5 Коммит B: добавлен b.txt 6f30e95 Коммит A: добавлен.txt $ ls a.txt b.текст 

В ветке 'master' вы заметите, что есть новый коммит G, который объединил изменения из ветки 'feature'. В основном произошло следующее действие:

A - B - C - G (мастер) \ / E - F (особенность) 

В коммите G все изменения из ветки 'feature' были перенесены в главную ветку. Но сама ветка 'feature' осталась нетронутой из-за процесса слияния. Обратите внимание на хеш каждого коммита. После слияния коммиты E (7c5c85e) и F (0286690) имеют одинаковый хэш в ветке feature и master.

3. Слияние с ребейзингом

Повторим шаг 1, чтобы снова создать ветки master и feature.

Результаты для 'master':

$ git checkout master Перешел на ветку master $ git log --oneline 7f573d8 Commit C: добавлено c.txt 795da3c Коммит B: добавлен b.txt 0f4ed5b Commit A: добавлен.txt $ ls a.txt b.txt c.текст 

Результаты по запросу "функция":

Функция $ git checkout переключена на ветку 'feature' $ git log --oneline 8ed0c4e Commit F: изменено b.txt 6e12b57 Коммит E: изменен.txt 795da3c Коммит B: добавлен b.txt 0f4ed5b Commit A: добавлен.txt $ ls a.txt b.текст 

Давайте перебазируем из ветки 'feature'.

Функция $ git checkout Переключена на ветку 'feature' $ git rebase master Сначала перематываем голову, чтобы воспроизвести вашу работу поверх нее ...txt Применение: Фиксация F: изменена b.текст 

Затем объедините "объект" в "мастер".

$ git checkout master Переключился на ветку master. $ git merge feature Обновление 7f573d8… 9efa1a3 Быстрая перемотка вперед.txt | 1 + б.txt | 1 + 2 файла изменено, 2 прошивки (+) 

Результаты для ветки master:

$ git checkout master Уже в 'master' $ git log --oneline 9efa1a3 Commit F: изменено b.txt 8710174 Коммит E: изменен.txt 7f573d8 Коммит C: добавлен c.txt 795da3c Коммит B: добавлен b.txt 0f4ed5b Commit A: добавлен.txt $ ls a.txt b.txt c.текст 

Результаты для ветки 'feature':

Функция $ git checkout переключена на ветку 'feature' $ git log --oneline 9efa1a3 Commit F: изменено b.txt 8710174 Коммит E: изменен.txt 7f573d8 Коммит C: добавлен c.txt 795da3c Коммит B: добавлен b.txt 0f4ed5b Commit A: добавлен.txt $ ls a.txt b.txt c.текст 

Обратите внимание, что после перебазирования и слияния обе ветки одинаковы. Кроме того, хеши для E и F изменились в обеих ветвях. По сути, в сценарии перебазирования произошло следующее:

A - B - C \ E '- F' (особенность, мастер) 

Вот почему нет нового коммита. Коммиты E и F были пересчитаны и зафиксированы в конце ветки master.

Ребазинг - полезный инструмент, когда вы хотите очистить историю своей работы. Однако есть опасность, породившая золотое правило.

Золотое правило ребейзинга

Золотое правило перебазирования:

Никогда не переустанавливайте публичную ветку.

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

В заключении:

Ребазинг - уникальная особенность Git. Но используйте его с осторожностью.

Больше информации:

Вот несколько ссылок для дальнейшего изучения:

Документация по Git Rebase
Atlassian Merging vs Rebasing

Рекомендации:

• https: // www.атласский.com / git / tutorials / слияние-против-ребазинг
• Контроль версий с помощью Git - 07 - Rebase [https: // www.YouTube.com / watch?v = cSf8cO0WB4o]
• https: // git-scm.com / docs / git-rebase
• Что такое Git rebase? [https: // www.YouTube.com / watch?v = TymF3DpidJ8]
• https: // средний.freecodecamp.org / git-rebase-and-the-золотое-правило-объяснение-70715eccc372