✅ Git ReBase проти об’єднання - Топ-5 порівняння Git ReBase і Merge

Різниця між Git ReBase і Merge

Різниця між Git ReBase і Merge

У цій статті ми розглянемо два таких інструменти Rebase і Merge та їх різницю. GIT - один з найпоширеніших контролерів розподілених версій DVCS серед програмістів через його динамічний характер та велику доступність інструментів для обробки версій. Є два способи, за допомогою яких ми можемо пересилати свої зміни з однієї гілки в іншу. Один використовується Rebase, а другий - об'єднання, яке є досить популярним. Нижче ми дізнаємося верхнє порівняння між Git ReBase і Merge.

Порівняння «голова до голови» між Git ReBase і Merge (Інфографіка)

Нижче наведено 5 найкращих порівнянь між Git ReBase і Merge:

Основні відмінності між Git ReBase і Merge

Давайте обговоримо ключову різницю між Git ReBase і Merge:

1. Git Rebase

Git Rebase розпочинає свою роботу з спільної комісії між двома гілками. Основний і функціональний, звідси він порівнює обидва і фіксує знімок різниці, який робиться в одній з гілок, а потім додає його іншим. Давайте розглянемо це за допомогою наведених нижче скріншотів.

Уявімо собі, що у нас є головна гілка та остання фіксація цього м2, як показано на наведеному вище скріншоті. З цього коміту ми створюємо гілку функції, і ми зробили деякі модифікації та фіксуємо повідомленням f1. Тепер давайте розглянемо, що хтось об'єднав свою роботу з майстром, і тепер остання комісія майстра - м3, а не м2, як показано нижче.

А також ми продовжуємо працювати над галуззю функцій, щоб додати останню прихильність до f2, як показано нижче.

Як видно з вищезгаданого екрана, ми освоїли останню фіксацію m3, і у нас є функція, яка не в курсі головного майстра, оскільки вона була створена з моментального знімку m2 m2, який має останню фіксацію як f3. Тепер, щоб об'єднати ці зусилля з майстром для створення, показано нижче.

Тепер нам потрібно інтегрувати вищезазначені зміни, які можна здійснити двома способами: один з об'єднанням, а другий з ребазом. Тут ми розглянемо, як інтегруватись із Rebase.

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

З наведеної вище команди rebase ми спробуємо шукати спільну команду як від головного, так і від функції, і в цьому випадку це m2. І тоді, оскільки нам доведеться перезавантажити головний майстер, він буде шукати доповнення, які були зроблені з майстром, і зробить знімок м3 та функцію перезавантаження від м2 до м3. Отже, тепер у нас є функція з м3 (замість м2), 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

Тепер з базою даних ми інтегрували оновлення функції, щоб освоїти. Спробуємо досягти цього шляхом злиття.

2. Git Merge

Ми також використаємо наведений вище скріншот для посилання і тут, і ми зможемо досягти того ж, що ми домоглися також за допомогою відновлення та об'єднання.

Git merge здійснює останнє зобов’язання, яке було у нас у галузі функції, і тут справа з f2-комітом, який збирає всі зміни та об'єднує його з останнім комітетом, який ми маємо у головній галузі, м3 тут. Це виглядає складно, але його можна легко виконати командою злиття. Ми можемо зробити пряме злиття або злиття сквош і різницю в обох.

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

Вищенаведена команда візьме всі зобов’язання функції та додасться також у журнал ведучого. Щоб уникнути того, що ми можемо використовувати сквош, щоб у журналі господаря після м3 було лише одне фіксація, і це є оновленням

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

слід бути обережним під час використання git rebase і намагатися уникати цього. Золоте правило - уникати цього, використовуючи громадські відділення.

Подивіться вищенаведений сценарій. Це може статися, коли ви намагаєтеся перевстановити майстер поверх своєї гілки функцій, а наша головна гілка є загальнодоступною, тепер головна гілка оновлюється, але всі інші працюють над старішою версією майстра. Оскільки звільнення в результаті призведе до нових команд git, можна подумати, що історія головного відділення відрізняється від усіх інших. Єдиний спосіб вирішити це - синхронізувати обидва ведучого, об'єднавши їх назад і отримавши набір комітетів, які будуть заплутаними.

Таблиця порівняння Git ReBase vs Merge

У таблиці нижче наведено порівняння між Git ReBase і Merge:

Основи порівняння між Rebase і Merge	База даних	Злиття
Коміти	Він змінює та переписує історію, створюючи нову комісію для кожного комітету у відділенні джерела.	Він включає всі зміни джерела, але підтримує походження кожної історії комісій, включає всі зміни в джерело, але підтримує походження кожної історії комісій.
Вибір	Тут ми спочатку перевіряємо гілку, яку потрібно перебазувати, а потім вибираємо команду rebase щоб додати оновлення до інших.	Тут спочатку перевірте гілку, яку потрібно спочатку об’єднати. Потім виконайте операцію злиття та останню фіксацію джерела буде злитий з останніми вчинками майстра.
Поводження з конфліктами	Оскільки історія фіксування буде переписана, зрозуміти конфлікт буде важко деякі випадки.	Конфлікт злиття можна легко вирішити, розуміючи помилку, допущену під час злиття.
Золоте правило	Потрібно використовувати на публічних гілках, оскільки історія введення даних може спричинити плутанину.	Немає великої шкоди під час виконання громадських відділень.
Доступність	Коміти, які були колись доступними, більше не будуть доступні після перезавантаження, оскільки історія фіксації зміниться.	Коміти залишаться доступними з джерельних гілок.

Висновок

Merge and Rebase є двома потужними інструментами Git, і обидва використовуються для включення змін до гілок, але ми повинні бути обережними з ребазою, оскільки це перепише історію комітетів, а використання їх на публічних гілках може перешкодити роботі інших викликає в них плутанину. Тоді як ви можете скористатися параметром злиття, оскільки його зобов'язання доступні з вихідної гілки і легко вирішувати конфлікти злиття, якщо ми добре розуміємо.

Git ReBase проти об’єднання - Топ-5 порівняння Git ReBase і Merge

Різниця між Git ReBase і Merge

Порівняння «голова до голови» між Git ReBase і Merge (Інфографіка)