GIT використовує гілки для ізоляції потоків розвитку, щоб запобігти забрудненню стабільної гілки вивільнення. Приведення роботи у гілці в основний потік означає злиття гілок. Ось як ви це робите.
Що таке злиття в Git?
Підготовка до об'єднання гілки в Git
Виконання злиття
Виконання швидкості вперед у Git
Як вирішити злиття конфліктів у Git
Зрештою все зливається
Що таке злиття в Git?
Git був розроблений для того, щоб зробити розгалуження простим і швидким. На відміну від інших систем управління версіями, розгалуження на GIT - це тривіальна речовина. Особливо з проектів з мультирозвиток, розгалуження є одним із основних організаційних інструментів GIT.
Біллі пісочниці Нові зусилля з розробки, щоб код міг бути змінений або доданий, не впливаючи на код в інших галузях, особливо основній або головній гілці. Зазвичай це містить стабільну версію вашої бази коду.
Ізоляція цих змін зі стабільної версії коду має ідеальний сенс. Але рано чи пізно новий код буде протестований, переглянутий та штампований гумовим штампуванням у головну гілку. У цей момент вам потрібно об'єднати свою гілку в головну гілку.
Насправді гілки можуть мати підгрупи, щоб ви могли об'єднати свою гілку в якусь іншу гілку замість головної гілки. Тільки пам’ятайте, що злиття завжди беруть одну гілку і зливають її в цільовий гілка, якою б не була ця гілка. Якщо ви хочете об'єднати свою головну гілку в іншу гілку, ви навіть можете це зробити.
Як і більшість дій у GIT, ви виконуєте об'єднання у своєму місцевому сховищі та підштовхуєте їх до вашого віддаленого сховища.
Підготовка до об'єднання гілки в Git
У нас є невеликий проект розвитку з місцевим сховищем GIT та віддаленим сховищем GIT. Ми створили гілку під назвою "Bugfix14" з гілки "Master" і працювали над рішенням помилки.
Ця робота завершена, і ми перевірили наш код. Все працює як очікувалося. Ми хочемо перекинути ці зміни в головну гілку, щоб наше виправлення було частиною наступного випуску програмного забезпечення.
Перед тим, як виконати злиття, потрібно зробити невелику підготовку. Нам потрібно переконатися, що цільова гілка - у цьому випадку "господаря" гілки - і гілка, яку ми збираємося з’єднатись, обидва оновлені.
- На гілці Bugfix14 : Це наша поточна гілка.
- Ваша гілка в курсі "Origin/Bugfix" : Відділення в нашому місцевому сховищі має ту саму історію комітету, що і філія у віддаленому сховищі. Це означає, що вони однакові.
- Нічого скоїти У зоні постановки немає змін, які не були вчинені.
- Робоче дерево чисте : У робочому каталозі немає нестабільних змін.
Усі ці вказують на те, що гілка оновлена, і ми зрозуміли, що продовжуємо діяти. Якщо будь -яка з них вказувала на те, що зміни існують, нам потрібно було б їх постановити, здійснити їх та підштовхнути до віддаленого. Якщо хтось інший працював над цими файлами, можливо, нам доведеться зробити їх зміни з віддаленого сховища.
Перевірка гілки, яку ми збираємося об'єднатись, спрощує процес злиття. Це також дозволяє нам перевірити, що це оновлено. Давайте подивимось на головну гілку.
Ми отримуємо ті самі підтвердження, що "Майстер" оновлюється.
Пов'язаний: Як вибрати робочий процес Git & amp; Модель розгалуження, яка підходить для вашої команди
Виконання злиття
Гілка "Bugfix14" була відгалужена з гілки "Майстер". Після створення гілки "BugFix14" відбулося зобов'язання з гілкою "Майстер". У відділенні "Bugfix14" було кілька комісій.
Ми переконалися, що наші дві гілки актуальні, і ми перевірили відділення "Майстер". Ми можемо випустити команду об'єднати гілку "BugFix14" у гілку "Майстер".
Злиття відбувається. Гілка "Bugfix14" все ще існує, але тепер зміни, внесені в цій галузі, були об'єднані у відділення "Майстер".
У цьому випадку команда злиття виконує тристороннє злиття . Є лише дві гілки, але є три зобов’язання. Вони є головою будь -якої гілки, і третє зобов'язання, яке представляє саму дію злиття.
Щоб оновити наш віддалений сховище, ми можемо використовувати git push команда.
Деякі люди вважають за краще видаляти бічні гілки, як тільки вони об'єднали їх. Інші дбають про збереження їх як запис справжньої історії розвитку проекту.
Якщо ви хочете видалити гілку, ви можете зробити це за допомогою
гілка
команда з
-Д
(Видалити) варіант.
До видалити гілку У віддаленому сховищі використовуйте цю команду:
У вас буде лінійна історія комітету, але це не буде справжньою історією.
Пов'язаний: Як видалити гілки GIT на місцевих та віддалених сховищах
Виконання швидкості вперед у Git
Якщо ви не зробили жодних дописів у відділення "Майстер", ваша історія буде виглядати так. Це також буде виглядати, якщо ви відроджений Ваша гілка розвитку, щоб вона була прикріплена до кінця гілки "господаря".
Оскільки у відділенні "Майстер" немає комісій, щоб об'єднати гілку "Bugfix15", все, що має зробити, - це вказати на вказівник "Майстер" на останній фіксацію гілки "Bugfix15".
Git здійснить швидке злиття Щоразу, коли це може . Якщо зобов’язатись у «Майстрі» гілки означають, що швидке злиття вперед неможливе, Git використовуватиме a тристороннє злиття .
Ви не можете
примушувати
Зрештою, швидке злиття-це може неможливо, але ви можете заявити, що це буде швидке злиття або нічого. Існує варіант, який доручає GIT використовувати швидке злиття, якщо воно може, але не робити тристороннє злиття, якщо воно не може. Варіант є
-Тільки
(Тільки швидке злиття).
Це об'єднує гілку "BugFix15" у гілку "Майстер", але лише якщо можливе швидке злиття.
У цьому випадку відбувалися до «господаря» гілки, тому швидке злиття вперед неможливо.
Як вирішити злиття конфліктів у Git
Якщо однакові частини одного файлу були змінені в обох гілках, гілки не можуть бути об'єднані. Для вирішення суперечливих редагувань потрібна взаємодія людини.
Тут ми внесли зміни до файлу під назвою "rot.c" у гілці під назвою "Bugfix17", який ми хочемо об'єднати до гілки "Master". Але "ROT.C" також змінено у гілці "Master".
Коли ми намагаємось об'єднати його, ми отримуємо попередження про те, що є конфлікти. GIT перераховує суперечливі файли та повідомляє нам про те, що злиття не вдалося. Ми могли б повністю відмовитися від використання
-Борт
Варіант:
Але вирішення злиття не так страшно, як це звучить. Git зробив певну роботу, щоб допомогти нам. Якщо ми редагуємо один із суперечливих файлів - у нашому випадку, у нас є лише один - ми знайдемо для нас розділи конфліктуючих кодів.
Кожен конфлікт обмежений семи менш ніж персонажами "
& lt; & lt; & lt; & lt; & lt; & lt; & lt;
"І сім більше, ніж персонажі"
& gt; & gt; & gt; & gt; & gt; & gt; & gt;
“, З семи рівними знаками”
=======
" між ними.
- Код вище знаків рівних - з гілки, яку ви злиєте у .
- Код нижче знака Equals - код з гілки, яку ви намагаєтесь об'єднання .
Ви можете легко шукати один із наборів із семи символів і перейти від конфлікту до конфлікту через ваш файл. Для кожного конфлікту вам потрібно вибрати, який набір редагувань ви збираєтеся дотримуватися. Ви повинні редагувати код, який ви відхиляєте, та семи символьні лінії, які додали Git.
Ми будемо тримати код у відділенні "Bugfix17". Після редагування наш файл виглядає так.
Зараз ми можемо продовжувати злиття. Але зауважте, ми використовуємо
вчинити
команда зробити це, а не
об'єднання
команда.
Ми здійснюємо зміни, влаштовуючи файл і здійснюючи його, як завжди. Ми перевіримо статус, перш ніж зробити остаточне зобов'язання.
Злиття завершено. Тепер ми можемо підштовхнути це до нашого віддаленого сховища.
Пов'язаний: Як виправити, редагувати чи скасувати виконання (зміна історії git)
Зрештою все зливається
Зрештою, всі гілки повинні бути об'єднані, щоб зміни в них не стали сиротою і забутими.
Об'єднання гілок легко, але боротьба з конфліктами може бути складною у зайнятих, більших командах. Вирішення конфліктів може зажадати вкладу кожного розробника лише для пояснення того, що робить їхній код і чому вони внесли свої зміни. Ви повинні це зрозуміти, перш ніж ви зможете прийняти обґрунтоване рішення про те, які зміни слід дотримуватися.
- › Як перейменувати гілку в Git
- › Як оформити карту віддалену гілку
- › Як зберігати зміни в Git
- › Як перемикати гілки в github
- › Git rebase: все, що потрібно знати
- › OnePlus 11 тут, але з грубим стартом
- › Microsoft Edge отримує чат AI та новий вигляд на Windows
- › Найкращі навушники для шанувальників iPhone просто потрапили на найнижчу ціну
