Учебник по Git Rebase

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

Git Rebase: Definitions

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

Пример Git Rebasing

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

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

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

 A - B - C (master)  E - F (feature)  

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

  1. Commit A: мы добавляем файл .txt в ветку master.
  1. Коммит B: мы добавляем файл b.txt в ветку master
  1. На этом этапе мы создаем ветку ‘feature’, что означает, что она будет иметь a.txt и b.txt
  1. Зафиксировать C: мы добавляем c.txt файл в ветке ‘master’
  1. Переходим в ветку ‘feature’
  1. Commit E: мы изменяем a.txt в ветке ‘feature’
  1. Commit F: мы изменяем b.txt в ветке ‘feature’

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

 git inittouch a.txtgit add -Agit commit -m "Commit A  : добавлен a.txt "touch b.txtgit add -Agit commit -m" Commit B: добавлен b.txt "git branch featuretouch c.txtgit add -A  git commit -m "Commit C: добавлен c.txt" git statusgit checkout featureecho aaa> a.txtgit add -Agit commit -m "Commit E: modified a.txt" echo bbb> b.txtgit add -Agit commit -m "  Фиксация F: измененный b.txt "

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

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

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

 $ git checkout master Переключился на ветку 'master' $ git log --oneline2bbde47 Фиксация C: добавлена ​​c.txtb430ab5 Фиксация B: добавлена ​​b.txt6f30e95 Фиксация A: добавлен a.txt $ lsa.txt b.  txt c.txt 

Результаты для ‘feature’:

 $ git checkout feature Переключен на ветвь 'feature' $ git log -  -oneline0286690 Фиксация F: изменена b.txt7c5c85e Фиксация E: изменена a.txtb430ab5 Фиксация B: добавлен b.txt6f30e95 Фиксация A: добавлен a.txt $ lsa.txt b. txt 

Обратите внимание на то, что ветка feature не имеет фиксации C

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

 $ git checkout masterSwitched to branch 'master' $ git merge featureMerge made by 'recursive' strategy.  a.txt |  1 + b.txt |  1 + 2 файла изменены, 2 вставки (+) 

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

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

Результаты для ‘feature’:

 $ git checkout feature Переключен на ветку 'feature' $ git log --oneline0286690 Commit F: изменено b.txt7c5c85e Commit E: изменено a.txtb430ab5 Commit B: добавлено b.txt6f30e95 Commit A: добавлен a.txt $ lsa.txt b  .txt 

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

 A - B - C - G (master) /E - F (feature) 

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


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

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

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

 $ git checkout master Переключился на ветку' master '$ git log --oneline7f573d8 Commit C: добавлен c.txt795da3c Commit B: добавлен b.txt0f4ed5b Commit A: добавлен a  .txt $ lsa.txt b.txt c.txt 

Результаты для ‘feature’:

 $ git checkout feature  ветка 'feature' $ git log --oneline8ed0c4e Commit F: изменено b.txt6e12b57 Commit E: изменено a.txt795da3c Commit B: добавлено b.txt0f4ed5b Commit A: добавлено a.txt $ lsa.txt b.txt 

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

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

Затем объедините ‘feature’ в ‘master’.

 $ git checkout master переключился на ветку 'master' $ git  функция слияния Обновление 7f573d8..9efa1a3Fast-forward a.txt |  1 + b.txt |  1 + 2 файла изменены, 2 вставки (+) 

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

 $ git checkout master  'master' $ git log --oneline9efa1a3 Commit F: изменено b. txt8710174 Фиксация E: изменена a.txt7f573d8 Фиксация C: добавлена ​​c.txt795da3c Фиксация B: добавлена ​​b.txt0f4ed5b Фиксация A: добавлен a.txt $ lsa.txt b.txt c.txt 

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

 $ git checkout feature Переключен на ветвь 'feature' $ git log --oneline9efa1a3 Commit F: изменено b.txt8710174 Commit E: изменено a  .txt7f573d8 Фиксация C: добавлена ​​c.txt795da3c Фиксация B: добавлена ​​b.txt0f4ed5b Фиксация A: добавлен a.txt $ lsa.txt b.txt c.txt 

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

 A - B - C  E '- F' (feature, master) 

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

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


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

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

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

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

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

Перебазирование — уникальная функция из Git. Но используйте его осторожно.

Дополнительная информация:

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

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

Ссылки:

  • https ://www.atlassian.com/git/tutorials/merging-vs-rebasing
  • Контроль версий с 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://medium.freecodecamp.org/git-rebase-and-the-golden-rule-explained- 70715eccc372
Оцените статью
nanomode.ru
Добавить комментарий