Уроки в Git: злиття / відновлення

Розподілена система управління версіями під назвою Git змінила спосіб розробників думати про об’єднання та розгалуження коду, порівняно з попередніми системами управління версіями, такими як CVS та SVN.


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

Якщо ви не новачок у Git, наступні посилання повинні допомогти швидко розпочати роботу:

  • Git – Простий посібник
  • Основи Git
  • Основи розгалуження гіта
  • Успішна модель розгалуження Git

У Git є два основні способи інтеграції змін з однієї гілки в іншу:

  1. злиття
  2. ребаза

Ми розглянемо об’єднання з опцією -ff та опцією –no-ff. Примітка: немає команди git –no-ff rebase.

Швидка демонстраційна настройка

Перш ніж ми розглянемо два способи злиття Git, спочатку створимо робочий сховище Git із такими командами:

1
2
3
4
5
6

mkdir мій код

відлуння “foo bar baz” > мій код / ​​foo.txt

git init мій код

cd мій код

git додати foo.txt

git commit -m “Повідомлення про зобов’язання”

Давайте тепер створимо нову гілку під назвою “myfeature” та перейдемо до неї:

1 git checkout -b міофактура

Тепер ми можемо внести зміни до файла “foo.txt” у гілці “myfeature” нашого місцевого репо:

1
2

echo -e “foo bar baznquux” > foo.txt

git commit -a -m “додав мій режим”

Припустимо, що наша зміна “міжособистості” завершена, і тепер ми хотіли б інтегрувати цю функцію в нашу “головну” гілку.

Наш графік git виглядав би так:

1
2
3

   Б міжособистість

  /

Майстер

Як було сказано раніше про Git, у нас є два шляхи для цього: або зробити злиття, або перезавантаження.

Як користуватися: git merge

Команда git merge об’єднує дві або більше гілок разом.

По-перше, повернемося до “головного”, щоб ми могли застосувати злиття на нашій головній гілці.

1 git checkout master

Тепер ми можемо зробити об’єднання, але давайте спочатку обговоримо два різних способи створення злиття.

Часто нинішній керівник відділення є родоначальником названого комітету («міфатура»). Це найпоширеніший випадок. У цьому сценарії нове зобов’язання не потрібно для зберігання об’єднаної історії. Натомість git HEAD (разом з індексом) оновлюється так, щоб вказувати на названий комітет, не створюючи зайвих комірок злиття.

Типова поведінка git merge – це зробити швидке злиття вперед, коли це можливо. Ця поведінка за замовчуванням може бути виразною за допомогою параметра -ff, або така поведінка може бути придушена за допомогою параметра злиття без перемотки вперед (–no-ff). Під час об’єднання поміченого тегу Git завжди створює комісію злиття, навіть якщо можливо швидке злиття вперед.

Під час використання –no-ff, хто переглядає історію git, може чітко побачити гілку, над якою ви перевірили роботу. Також зауважте, як злиття –no-ff має в кінці додаткову комісію злиття.

Нижче зображено зображення, яке показує різницю між злиттям –no-ff та –ff.

git - no-ff rebase

Тепер у вас є можливість використовувати будь-яке:

1 git merge myfeature

Після цієї команди наш графік git виглядатиме так:

1 A – B майстер

Або ми могли зберегти історію філії, зробивши:

1 git merge –не-ff міфеатура

В останньому випадку наш git-графік виглядатиме так:

1
2
3

  Б мій характер

/

A – C майстер

І якщо ми виконаємо таку команду git log:

1 git log –graph – повна історія –all –pretty = формат: „% h% x09% d% x20% s“

Це покаже аналогічний графік git:

1
2
3
4
5

* 5368727 (HEAD, master) Об’єднати гілку “myfeature”

|

| * 6267227 (myfeature) додав міфеатуру

| /

* ac54e38 Повідомлення фіксації

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

Як користуватися: git rebase

Другий спосіб інтеграції змін з однієї гілки в іншу – це зробити git rebase.

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

Місцевий git rebase переадресовує локальні посилання на оновлену головну версію потоку. Звільнення – це процес переміщення філії до нового базового комітету.

Ось так виглядає на графіку git. Припустимо, існує така історія, і нинішня галузь є “мією”:

1
2
3

      Міофактура A – B – C

     /

D – E – F – G майстер

І якщо ми зараз:

1 git rebase master

Результатом буде:

1
2
3

        Міфатура A – – B – C

       /

D — E — F — G майстер

Тепер гілка “master” містить зміни гілки “myfeature” на комітеті “G” без створення об’єднання об’єднань. Таким чином, замість того, щоб з’єднуватися з гілками з об’єднанням, скасування інтегрує гілку “myfeature”, будуючи поверх майстра. Результат – це лінійна історія, яку розробникам може бути легше зрозуміти. Журнал git тепер відображав би лінійну історію „D — E — F — G master“.

У разі конфлікту, git rebase зупиниться на першій проблематичній фіксації та залишить маркери конфлікту на дереві.

Об’єднати або відновити?

Обидва способи інтеграції коду слід використовувати, коли вони найкраще підходять. Існують різні думки щодо того, коли слід використовувати певний метод.

Ось декілька посилань, які описують ситуації, коли одному методу можна віддати перевагу над іншим:

  • злиття або відновлення?
  • Коли об’єднати порівняно з часом
  • Робочі процеси Git Team: злиття або відновлення?
Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Adblock
    detector