Вступ до Git merge and rebase: що це таке, і як ними користуватися

Як розробник, багатьом з нас доводиться вибирати між об’єднанням та перебазуванням. З урахуванням усіх посилань, які ми отримуємо в Інтернеті, всі вважають, що «не використовуйте Rebase, це може спричинити серйозні проблеми». Тут я поясню, що таке злиття та перебазування, чому ви повинні (і не повинні) їх використовувати, і як це зробити.

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

Це питання розкололо спільноту Git. Одні вважають, що вам слід завжди переоцінювати, а інші - що ви завжди повинні зливатися. Кожна сторона має певні переконливі переваги.

Git Merge

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

Плюси

  • Просто і звично
  • Зберігає повну історію та хронологічний порядок
  • Зберігає контекст гілки

Мінуси

  • Історія комітів може бути забруднена безліччю комітів злиття
  • Налагодження за допомогою git bisectможе стати складнішим

Як це зробити

Об’єднайте головну гілку у гілку об’єкта за допомогою команд checkoutі merge.

$ git checkout feature $ git merge master (or) $ git merge master feature

Це створить новий “ Злиття коміту ” у гілці об’єктів, що зберігає історію обох гілок.

Git Rebase

Rebase - це ще один спосіб інтегрування змін з однієї гілки в іншу. Rebase стискає всі зміни в один “патч”. Потім він інтегрує патч у цільову гілку.

На відміну від злиття, перебазування згладжує історію, оскільки передає виконану роботу з однієї гілки на іншу. У процесі усувається небажана історія.

Бази - це те, як зміни повинні проходити зверху ієрархії вниз, а злиття - те, як вони повертаються вгору

Плюси

  • Впорядковує потенційно складну історію
  • Маніпулювати одним комітом легко (наприклад, скасувати їх)
  • Уникає злиття "шуму" при зайнятих репозиторіях із зайнятими гілками
  • Очищає проміжні коміти, роблячи їх одним комітом, що може бути корисним для команд DevOps

Мінуси

  • Здавлення функції до декількох коммітів може приховати контекст
  • Перебазування загальнодоступних сховищ може бути небезпечним під час роботи в команді
  • Це більше роботи: використання rebase для постійного оновлення вашої гілки функцій
  • Перебазування з віддаленими гілками вимагає примусового натискання. Найбільша проблема, з якою стикаються люди, полягає в тому, що вони змушують натискати, але не встановили git push за замовчуванням. Це призводить до оновлень усіх гілок, що мають однакові назви, як локально, так і віддалено, і з цим жахливо мати справу.
Якщо ви перебазуєте дані неправильно та ненавмисно переписуєте історію, це може призвести до серйозних проблем, тому переконайтеся, що ви знаєте, що робите!

Як це зробити

Перебазуйте гілку об’єкта на головну гілку, використовуючи такі команди.

$ git checkout feature $ git rebase master

Це переміщує всю гілку об’єкта поверх головної гілки. Він робить це, переписуючи історію проекту, створюючи абсолютно нові коміти для кожного коміту у вихідній (функціональній) гілці.

Інтерактивне перебазування

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

$ git checkout feature $ git rebase -i master

Це відкриє редактор із переліком усіх комітів, які збираються перемістити.

pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

Це визначає, як саме виглядатиме гілка після виконання перебазування. Змінивши порядок об’єктів, ви можете зробити історію схожою на все, що забажаєте. Наприклад, ви можете використовувати такі команди , як fixup, squash, і editт.д., на місці pick.

Який із них використовувати

То що найкраще? Що рекомендують експерти?

Важко узагальнити та визначитися з тим чи іншим, оскільки кожна команда відрізняється. Але ми повинні десь починати.

Командам потрібно розглянути декілька питань під час встановлення політики Git rebase проти злиття. Оскільки, як виявляється, одна стратегія робочого процесу не краща за іншу. Це залежить від вашої команди.

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

Нарешті, рішення про злиття та перебазування слід розглядати в контексті чіткої стратегії розгалуження ( див. Цю статтю, щоб зрозуміти більше про стратегію розгалуження). Успішна стратегія розгалуження розроблена навколо організації ваших команд.

Що я рекомендую?

У міру зростання команди буде важко керувати або відстежувати зміни в розвитку за допомогою політики постійного злиття. Щоб мати чітку та зрозумілу історію комітів , використання Rebase є розумним та ефективним.

Розглядаючи наступні обставини та рекомендації, ви можете отримати найкращі результати від Rebase:

  • Ви розвиваєтесь локально: якщо ви ні з ким не ділилися своєю роботою. На цьому етапі вам слід віддати перевагу перебазуванню перед об’єднанням, щоб ваша історія була охайною. Якщо у вас є ваш персональний форк сховища, який не надається іншим розробникам, ви можете перебазувати дані навіть після того, як перейдете у свою гілку.
  • Ваш код готовий до розгляду: Ви створили запит на витяг. Інші переглядають вашу роботу і потенційно переносять її у свою вилку для місцевого огляду. На цьому етапі вам не слід переоцінювати свою роботу. Вам слід створити коміти "переробки" та оновити гілку функцій. Це допомагає простежити запит на витягування та запобігає випадковій поломці історії.
  • Огляд зроблено і готовий до інтеграції в цільову гілку. Вітаємо! Ви збираєтеся видалити свою гілку функцій. З огляду на те, що з цього моменту інші розробники не збиратимуться об’єднувати ці зміни, це ваш шанс очистити свою історію. На цьому етапі ви можете переписати історію та скласти оригінальні коміти, а ті докучливі коміти 'pr rework' та 'merge' у невеликий набір цілеспрямованих комітів. Створення явного злиття для цих комітів є необов’язковим, але має значення. Він фіксує, коли функцію закінчили освоювати.

Висновок

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

Я з нетерпінням чекаю написання робочих процесів Git та концепцій Git . Коментуйте теми, про які ви хочете, щоб я писав далі. Ура!

code = coffee + developer

школа кодування для розробників програмного забезпечення