1. Що таке гілки і навіщо вони потрібні?
Робота з branches (гілками) в Git — один із ключових аспектів керування версіями. Вона дає змогу паралельно вести кілька ліній розробки в одному репозиторії. Розгалуження робить Git потужним інструментом для спільної роботи, експериментів і керування різними версіями проєкту.
gitGraph
commit id: "Початкове налаштування"
commit id: "Додано базові можливості"
branch feature/new-idea
checkout feature/new-idea
commit id: "Реалізовано нову логіку"
commit id: "Доопрацьовано логіку"
checkout main
commit id: "Термінове виправлення помилки в main"
merge feature/new-idea
commit id: "Підготовка до випуску"
main відгалужується нова гілка,
feature/new-idea, для безпечної розробки. Після завершення роботи вона зливається назад у
main.
Уявіть, що ви хочете серйозно переробити свій проєкт або провести ризикований експеримент. Як би ви вчинили без Git? Найімовірніше, скопіювали б увесь проєкт у нову папку й працювали б у ній. Якщо результат сподобається, перенесли б його в основну папку. Якщо ні — просто видалили б копію.
Гілки в Git працюють за тим самим принципом, але набагато елегантніше. Розгляньмо це на прикладі написання книги:
- У вас є готовий рукопис — це ваша основна гілка
main. - Ви хочете написати альтернативну кінцівку, тож створюєте нову гілку, наприклад
feature/new-idea. - Ви пишете нову кінцівку, не чіпаючи основний текст рукопису, тобто працюєте в новій гілці.
- Якщо нова кінцівка виявиться кращою, ви замінюєте нею стару — тобто робите злиття гілок,
merge. - Стару чернетку з непотрібною кінцівкою можна видалити — видаляєте гілку.
2. Створення нової гілки та робота в ній
Крок 1. Відкрийте меню керування гілками.
На головній панелі інструментів, поруч із назвою проєкту, розташований віджет, що відображає імʼя поточної гілки (за замовчуванням — main). Натисніть на нього та виберіть + New Branch.
Крок 2. Вкажіть імʼя нової гілки.
Найкраще називати гілки відповідно до задачі, яку ви розвʼязуєте. Наприклад, feature/add-usage-examples.
Після створення гілки IDE автоматично перемкнеться на неї. Ви побачите нове імʼя в тому самому віджеті.
Крок 3. Внесіть зміни та зробіть commit.
Тепер ви у своїй «пісочниці». Додаймо в наш файл README.md новий розділ із прикладами використання. Внесіть зміни та зробіть commit, як ви робили в минулій лекції.
3. Перемикання між гілками
Ваші зміни з прикладами використання тепер надійно збережені в гілці feature/add-usage-examples. Повернімося до основної гілки main і подивімося, що там.
Крок 1. Знову натисніть на віджет із назвою поточної гілки в лівому верхньому куті.
Крок 2. У списку Local або Recent виберіть гілку main, і в підменю, що зʼявиться, натисніть Checkout.
Крок 3. Перевірте результат.
Щойно ви перемкнетеся, відкрийте файл README.md. Ви побачите, що розділу з прикладами використання там немає! Він залишився в іншій гілці. Таким чином, ви можете працювати над новою функціональністю, не чіпаючи стабільну версію в гілці main.
4. Злиття гілок
Команда merge бере всі коміти з гілки feature/add-usage-examples (у цьому випадку — коміт C3) і обʼєднує їх із поточною гілкою main, створюючи новий коміт злиття.
gitGraph
commit id: "C1"
commit id: "C2"
branch feature/add-usage-examples
checkout feature/add-usage-examples
commit id: "C3: Додати новий розділ"
checkout main
merge feature/add-usage-examples
Отже, ви завершили роботу над своєю задачею в гілці feature/add-usage-examples і хочете додати ці зміни в основний проєкт.
Крок 1. Перемкніться на цільову гілку.
Переконайтеся, що ви перебуваєте в тій гілці, куди хочете додати зміни. У нашому випадку це main.
Крок 2. Виконайте злиття.
Знову натисніть на віджет керування гілками. У списку виберіть гілку, звідки ви хочете взяти зміни (feature/add-usage-examples), і в підменю виберіть Merge 'feature/add-usage-examples' into 'main'.
Крок 3. Перевірте результат.
Тепер у файлі README.md в гілці main зʼявився ваш новий розділ із прикладами. Ви успішно обʼєднали свою роботу з основною версією проєкту!
5. Конфлікти під час злиття
Для новачків слово «конфлікт» часто звучить лякаюче, але в командній розробці це абсолютна норма. Конфлікт виникає, коли в обох гілках, що зливаються, були змінені одні й ті самі рядки в одному й тому самому файлі. Git не може сам вирішити, чия версія правильніша, і просить вашої допомоги.
Саме тут стають у пригоді IntelliJ IDEA та GoLand. Вирішувати конфлікти в терміналі — це ще те випробування, але вбудований в IDE інструмент тристороннього злиття (3-way merge) перетворює цю задачу на наочний і простий процес.
gitGraph
commit id: "C1: Спільна база"
branch feature/new-title
checkout main
commit id: "C2: Зміна в main"
checkout feature/new-title
commit id: "C3: Зміна у feature"
main та
feature/new-title, мають нові коміти (C2 та C3), які базуються на спільному предку (C1). Це гарантовано призведе до конфлікту під час злиття.
Змоделюймо конфлікт:
- Переконайтеся, що ви перебуваєте в гілці
main, і у вас немає незбережених змін у вікні Commit. - Створіть нову гілку
feature/new-title, але поки що не перемикайтеся на неї. Переконайтеся, що галочка Checkout branch знята. - Тепер, перебуваючи в гілці
main, змініть перший рядок уREADME.mdна «My Awesome Project» і зробітьcommit. - Перемкніться на гілку
feature/new-title. Ви побачите, що перший рядок уREADME.mdтут залишився старим: це стан файла на момент створення гілки. Змініть цей же рядок на «My Super Project» і зробітьcommit. - Поверніться до гілки
mainта виконайте злиття зfeature/new-title.
Тепер Git побачить, що обидві історії змінені в одному й тому самому місці. Він покаже вам вікно для вирішення конфлікту (Merge Conflicts).
Натисніть кнопку Merge, щоб відкрити інструмент розв’язання конфліктів. Ви побачите таке:
- Зліва (Your changes): версія файла з вашої поточної гілки (куди ви зливаєте —
main). - Справа (Changes from branch): версія файла з гілки, яку ви зливаєте.
- По центру (Result): підсумкова версія файла, яку ви маєте зібрати власноруч.
Ви можете натискати на стрілочки >> або << (або на хрестики для скасування), щоб повністю прийняти один із варіантів. Також ви можете просто написати правильний текст у центральній панелі.
Коли результат у центральній панелі вас влаштує і всі конфлікти буде вирішено, натисніть Apply (або Save Changes and Finish). IDE сама створить спеціальний коміт злиття, і конфлікт буде розвʼязано.
Чому іноді не виникає конфлікту?
Може виникнути ситуація, коли ви виконали всі кроки, а конфлікту не сталося. Найчастіше це повʼязано з тим, що Git зміг виконати fast-forward merge (злиття перемотуванням). Це відбувається, коли історія однієї гілки просто продовжила історію іншої, і вони не розходилися паралельно.
Приклад:
- Переконайтеся, що ви перебуваєте в
main(припустімо, C1). - Ви робите новий коміт у гілці
mainіз повідомленням «My Awesome Project». Гілкаmainтепер вказує на коміт C2 (main -> C1 -> C2). - Ви створюєте гілку
feature/new-titleз поточного положення гілки main. Це означає, що нова гілка також починається з коміта C2. - Ви робите коміт у
feature/new-titleз повідомленням «My Super Project». Ця гілка «йде вперед» і тепер вказує на коміт C3 (feature/new-title -> C1 -> C2 -> C3). - Ви повертаєтеся в
main(яка все ще на коміті C2) і даєте команду злити feature/new-title.
Git аналізує ситуацію і бачить, що гілка main є прямим предком гілки feature/new-title. В історії main не було жодних нових комітів, поки ви працювали в іншій гілці. Git думає: «А, тут просто потрібно перемотати main уперед до коміта C3. Жодних суперечностей немає». І він просто переміщує вказівник main на коміт C3 без конфліктів.
gitGraph
commit id: "C1"
commit id: "C2"
branch feature/new-title
checkout feature/new-title
commit id: "C3"
checkout main
merge feature/new-title
6. Перегляд історії змін
Щоб краще розуміти, що відбувається у вашому проєкті, корисно дивитися на його історію.
Відкрийте вікно інструмента Git (зазвичай це іконка на лівій бічній панелі або внизу вікна IDE) і виберіть вкладку Log або Show Git Log на панелі інструментів Git. Ви побачите графічне представлення всіх ваших гілок і комітів. Це допоможе наочно відстежити, яка гілка від якої відокремилася та де їх злили.
Тут ви можете клацнути будь-який коміт, щоб побачити, які зміни до нього увійшли, хто і коли його зробив. Це справжня машина часу для вашого коду!
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ