Безпечні експерименти: робота з гілками

1. Що таке гілки та навіщо вони потрібні?

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

            gitGraph
            commit id: "Initial setup"
            commit id: "Add base features"
            branch feature/new-idea
            checkout feature/new-idea
            commit id: "Implement new logic"
            commit id: "Refactor the logic"
            checkout main
            commit id: "Urgent bugfix on main"
            merge feature/new-idea
            commit id: "Prepare for release"
        

Уявіть, що ви хочете щось серйозно переробити у вашому проєкті або провести ризикований експеримент. Як би ви вчинили без Git? Швидше за все, скопіювали б увесь проєкт у нову теку і працювали б у ній. Якщо результат сподобається — перенесли б його в основну теку. Якщо ні — просто видалили б копію.

Гілки в Git працюють за тим самим принципом, але значно елегантніше. Розгляньмо на прикладі написання книжки:

1. У вас є готовий рукопис (це ваша основна гілка main).
2. Ви хочете написати альтернативну кінцівку (створюєте нову гілку, наприклад feature/new-idea).
3. Ви пишете нову кінцівку, не зачіпаючи основного тексту рукопису (працюєте в новій гілці).
4. Якщо нова кінцівка виявиться кращою, ви замінюєте нею стару (виконуєте злиття гілок — merge).
5. Старий чернетковий варіант із непотрібною кінцівкою можна видалити (видаляєте гілку).

2. Створення нової гілки та робота в ній

Крок 1. Відкрийте меню керування гілками.

На верхній панелі IDE є віджет, що відображає назву поточної гілки (зазвичай — 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)

Команда merge бере всі коміти з гілки feature/add-examples (у цьому випадку — коміт C3) і об’єднує їх із поточною гілкою main, створюючи новий коміт злиття.

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/add-examples
            checkout feature/add-examples
            commit id: "C3: Add new section"
            checkout main
            merge feature/add-examples
        

Отже, ви завершили роботу над своїм завданням у гілці feature/add-usage-examples і хочете додати ці зміни до основного проєкту.

Крок 1. Перемкніться на цільову гілку.

Переконайтеся, що ви перебуваєте в тій гілці, КУДИ хочете додати зміни. У нашому випадку це main.

Крок 2. Виконайте злиття.

Знову натисніть на віджет керування гілками. У списку виберіть гілку, ЗВІДКИ ви хочете взяти зміни (feature/add-usage-examples), і в підменю оберіть Merge feature/add-usage-examples у main.

Крок 3. Перевірте результат.

Тепер у файлі README.md у гілці main зʼявився ваш новий розділ із прикладами. Ви успішно об’єднали свою роботу з основною версією проєкту!

5. Конфлікти під час злиття: не бійтеся, це нормально!

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

            gitGraph
            commit id: "C1: Спільна база"
            branch feature/new-title
            checkout main
            commit id: "C2: Зміна в main"
            checkout feature/new-title
            commit id: "C3: Зміна у feature"
        

Змоделюймо конфлікт:

1. Переконайтеся, що ви перебуваєте в гілці main і у вас немає незбережених змін.
2. Одразу створіть нову гілку feature/new-title, але поки не перемикайтеся на неї. Переконайтеся, що прапорець Checkout branch знято.
3. Тепер, перебуваючи в гілці main, змініть перший рядок у README.md на «My Awesome Project» і зробіть commit.
4. Перемкніться на гілку feature/new-title. Ви побачите, що перший рядок у README.md тут залишився старим: це стан файлу на момент створення гілки. Змініть цей самий рядок на «My Super Project» і зробіть commit.
5. Поверніться до гілки main і виконайте злиття з feature/new-title.

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

Merge Revision

Що ви тут бачите:

• Ліворуч (Your changes): версія файлу з вашої поточної гілки (main).
• Праворуч (Changes from branch...): версія файлу з гілки, яку ви зливаєте.
• У центрі (Result): підсумкова версія файлу, яку ви маєте сформувати.

Ви можете натискати на стрілочки >> або <<, щоб прийняти повністю той чи інший варіант.

Коли результат у центральній панелі вас влаштує, натисніть Apply. IDE автоматично створить коміт злиття, і конфлікт буде розв’язано.

Чому не виник конфлікт?

Може статися, що ви виконали всі кроки, а конфлікт не виник. Найчастіше це повʼязано з тим, що Git зміг виконати fast-forward merge, адже історія однієї гілки просто продовжила історію іншої. Щоб конфлікт був гарантований, історії гілок мають розійтися в різні боки від спільного предка.

Приклад:

1. У вас є певний коміт у main (припустімо, C1).
2. Ви робите новий коміт у main з текстом «My Awesome Project». Гілка main тепер вказує на коміт C2 (main -> C1 -> C2).
3. Ви створюєте гілку feature/new-title з поточного положення гілки main. Це означає, що нова гілка теж починається з коміту C2.
4. Ви робите коміт у feature/new-title з текстом «My Super Project». Ця гілка «йде вперед» і тепер вказує на коміт C3 (feature/new-title -> C1 -> C2 -> C3).
5. Ви повертаєтеся до 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. Ви побачите графічне подання всіх ваших гілок і комітів. Це допоможе наочно відстежити, яка гілка від якої відокремилася й де вони були злиті.

Тут ви можете натиснути на будь-який коміт, щоб побачити, які зміни до нього увійшли, хто й коли його зробив. Це справжня машина часу для коду!