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