Зміст курсу
Основи GitHub
Основи GitHub
Основи Ребейзу
Створення коміту в гілці main
Почнемо зі створення коміту безпосередньо у віддаленій гілці main, відредагувавши файл README.md у віддаленому репозиторії. Це призведе до розбіжності історії комітів між гілками main та feature/payment.
Ось рядок, доданий до файлу:
Ось відповідне повідомлення коміту:
Розуміння ребейзу
Як ми згадували у попередньому розділі, після того як гілка feature була перевірена та протестована, її можна і слід об'єднати назад у гілку main. До цього моменту ми використовували для цього лише команду git merge. Однак існує й інший підхід — використання команди git rebase.
Ребейз — це процес переміщення або об'єднання послідовності комітів до нової базової точки. Це здійснюється шляхом повторного застосування змін з однієї гілки на іншу, що призводить до лінійної історії комітів.
Коли ми створюємо гілку, Git відстежує останній коміт на обох гілках. Якщо нові зміни є лише в одній гілці, Git може виконати fast-forward і застосувати зміни. Однак якщо нові зміни є в обох гілках, Git створює новий коміт злиття, що призводить до тристороннього злиття.
Ось як виглядатиме тристороннє злиття у нашому випадку, де C4 був останнім комітом у гілці feature/payment перед злиттям:
Однак трьохстороннє злиття може ускладнити налагодження через розгалужену, нелінійну історію. За допомогою ребейзу ми змінюємо базу наших комітів і відтворюємо їх поверх нової бази, дозволяючи Git виконати швидке пряме злиття та підтримувати лінійну історію.
Нижче наведено анімацію, яка ілюструє, як можна виконати ребейз у нашому випадку (ідентифікатори комітів тут не відповідають реальним):
Коли ви виконуєте ребейз гілки, ви фактично переписуєте її історію. Це означає, що старі коміти замінюються новими, які мають інші ідентифікатори (хеш-суми), оскільки вони базуються на інших знімках коду. Як показано на анімації вище, ідентифікатор коміту у гілці feature/payment змінився після ребейзу.
Дякуємо за ваш відгук!
