-
1. Вступ
- 1.1 Про систему контролю версій
- 1.2 Коротка історія Git
- 1.3 Основи Git
- 1.4 Git, зазвичай, тільки додає дані
- 1.5 Три стани
- 1.6 Командний рядок
- 1.7 Інсталяція Git
- 1.8 Початкове налаштування Git
- 1.9 Отримання допомоги
- 1.10 Підсумок
-
2. Основи Git
- 2.1 Створення Git-сховища
- 2.2 Запис змін до репозиторія
- 2.3 Перегляд історії комітів
- 2.4 Скасування речей
- 2.5 Взаємодія з віддаленими сховищами
- 2.6 Теґування
- 2.7 Псевдоніми Git
- 2.8 Підсумок
-
3. Галуження в git
- 3.1 Гілки у кількох словах
- 3.2 Основи галуження та зливання
- 3.3 Управління гілками
- 3.4 Процеси роботи з гілками
- 3.5 Віддалені гілки
- 3.6 Перебазовування
- 3.7 Підсумок
-
4. Git на сервері
- 4.1 Протоколи
- 4.2 Отримання Git на сервері
- 4.3 Генерація вашого публічного ключа SSH
- 4.4 Налаштування Серверу
- 4.5 Демон Git
- 4.6 Розумний HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Варіанти стороннього хостингу
- 4.10 Підсумок
-
5. Розподілений Git
-
6. GitHub
-
7. Інструменти Git
- 7.1 Вибір ревізій
- 7.2 Інтерактивне індексування
- 7.3 Ховання та чищення
- 7.4 Підписання праці
- 7.5 Пошук
- 7.6 Переписування історії
- 7.7 Усвідомлення скидання (reset)
- 7.8 Складне злиття
- 7.9 Rerere
- 7.10 Зневадження з Git
- 7.11 Підмодулі
- 7.12 Пакування
- 7.13 Заміна
- 7.14 Збереження посвідчення (credential)
- 7.15 Підсумок
-
8. Налаштування Git
-
9. Git and Other Systems
- 9.1 Git як клієнт
- 9.2 Міграція на Git
- 9.3 Підсумок
-
10. Git зсередини
- 10.1 Кухонні та парадні команди
- 10.2 Об’єкти Git
- 10.3 Посилання Git
- 10.4 Файли пакунки
- 10.5 Специфікація посилань (refspec)
- 10.6 Протоколи передачі
- 10.7 Супроводження та відновлення даних
- 10.8 Змінні середовища
- 10.9 Підсумок
-
A1. Додаток A: Git в інших середовищах
- A1.1 Графічні інтерфейси
- A1.2 Git у Visual Studio
- A1.3 Git в Eclipse
- A1.4 Git у Bash
- A1.5 Git у Zsh
- A1.6 Git у Powershell
- A1.7 Підсумок
-
A2. Додаток B: Вбудовування Git у ваші застосунки
- A2.1 Git з командного рядка
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Додаток C: Команди Git
- A3.1 Налаштування та конфігурація
- A3.2 Отримання та створення проектів
- A3.3 Базове збереження відбитків
- A3.4 Галуження та зливання
- A3.5 Поширення й оновлення проектів
- A3.6 Огляд та порівняння
- A3.7 Зневаджування
- A3.8 Латання (patching)
- A3.9 Електронна пошта
- A3.10 Зовнішні системи
- A3.11 Адміністрування
- A3.12 Кухонні команди
3.4 Галуження в git - Процеси роботи з гілками
Процеси роботи з гілками
Тепер, коли ви навчилися основам роботи з гілками, що ж з ними можна чи потрібно робити далі? В цьому розділі ми розкажемо про найбільш вживані підходи до роботи з гілками, які дозволяє така легка система галуження Git, а ви можете вирішити чи втілювати вам їх у свій робочий цикл.
Довго-триваючі гілки
Оскільки Git використовує просте триточкове злиття, то зливання одної гілки в іншу протягом тривалого часу зазвичай не є складною задачею. Це означає, що ви можете мати кілька активних гілок та використовувати їх для різних стадій вашого робочого циклу; можете періодично зливати з одної гілки в іншу.
Багато розробників підтримують з Git такий процес, коли тільки в master
є стабільна версія коду — найімовірніше того, що був чи буде запроваджений у виробництво.
Також вони мають паралельні гілки develop
чи next
, які використовуються для тестування стабільності — це не обов’язково постійно стабільні гілки, але, як тільки вони стабілізовуються, їх можна зливати з master
.
Також практикується мати тематичні гілки (коротко-термінові, як iss53
, що ви створили раніше) та зливати їх, коли вони готові, проходять всі тести, та не привнесуть нових помилок.
Насправді, ми маємо справу з вказівниками, що рухаються вздовж лінії комітів, які ви додаєте. Стабільні гілки нижче по лінії ваших комітів, а “дослідницькі” гілки — ті, що містять нові зміни, випереджають їх.
![Лінійне представлення прогресування стабільності в гілках.](/book/uk/v2/images/lr-branches-1.png)
Взагалі простіше собі уявити цей процес як елеватор, коли набори комітів прямують до більш стабільних гілок, де вони повністю тестуються.
![``Елеваторне'' представлення прогресування стабільності в гілках.](/book/uk/v2/images/lr-branches-2.png)
Ви можете мати декілька рівнів стабільності.
На більших проектах також практикують мати proposed
чи pu
(proposed updates) гілки, де зберігаються гілки, що вже інтегровані, але не готові бути перенесені в основні гілки next
чи master
.
Ідея таких гілок в тому, що ваші гілки мають кілька рівнів стабільності і коли вони досягають більш стабільного рівня, їх зливають до гілок, котрі вище над ними.
Зверніть увагу, що мати кілька довготривалих гілок не обов’язково, проте буває корисним, особливо коли маєте справу з великими чи складними проектами.
Тематичні гілки
Тематичні гілки мають своє застосування в проектах будь-якого розміру. Тематична гілка — це короткострокова гілка, що створюється для окремо взятого завдання чи функціональності. Напевно, ви таке раніше не робили часто з іншими СКВ, оскільки загалом це досить “дорого” створювати та зливати гілки. Проте в Git це досить звична практика створювати, додавати коміти, зливати та видаляти гілки по кілька разів на день.
Приклад цього ви бачили раніше в попередньому розділі з гілками iss53
та hotfix
Ви додавали кілька комітів в ці гілки та видаляли їх одразу після зливання в основну гілку.
Така техніка дозволяє швидко та повністю змінювати контекст роботи, оскільки ваша робота в окремому елеваторі, де всі зміни пов’язані тільки з однією темою чи завданням, це полегшує та ізолює перегляд коду тощо.
Ви можете тримати свої зміни там кілька хвилин, днів, чи місяців, і зливати аж тоді, коли вони будуть готові.
Розглянемо приклад, коли нам потрібно зробити завдання №91 (в master
), ми робимо гілку (iss91
), трохи там працюємо, потім робимо з неї ще одну гілку (iss91v2
) щоб попробувати інший підхід, повертаємося в master
на деякий час, і тоді робимо ще одну гілку щоб перевірити одну непевну ідею (гілка dumbidea
).
Історія комітів виглядатиме десь так:
![Багато тематичних гілок.](/book/uk/v2/images/topic-branches-1.png)
Тепер, скажімо, вам сподобався підхід номер два (iss91v2
) і ви показали свою ідею (гілку dumbidea
) колегам, і вона їм здається геніальною.
Ви можете викидати оригінальну iss91
(втрачаючи коміти C5
та C6
) та зливати дві інші гілки.
Тепер ваша історія така:
![Історія після зливання `dumbidea` та `iss91v2`.](/book/uk/v2/images/topic-branches-2.png)
dumbidea
та iss91v2
Ми приділимо більше уваги різним можливим робочим процесам ваших Git проектів в Розподілений Git, тому, перед остаточним рішенням яку ж схему обрати, прочитайте цей розділ.
Пам’ятайте: усі зміни, що ви робили тут з гілками — повністю локальні. Коли ви створюєте гілки та зливаєте їх — все це відбувається тільки у вашому сховищі — жодних змін на сервер чи з нього не надсилається.