розробки версій, а такоже спріятімуть Швидко Усунення поточних проблем, Які вінікатімуть у процессе розробки проекту. На Відміну Від Головня, Такі Гілки всегда матімуть визначеня годин Термін Існування и после Завершення своєї актуальності будут відалені.
Рис. 5. Схема взаємодії РОБОЧОЇ и головної гілок проекту
У процессе розробки складного проекту могут використовуват Різні види Додатковий гілок, зокрема: тематичні Гілки (feature), Гілки версій (release) та Гілки помилок (hotfix). Кожна з ціх гілок має Спеціальне призначення и розробник проектів обов язково мают прітрімуватісь Певного набору правил относительно їх визначення, зокрема, яка з гілок є Першоджерело, а яка - результатом злиттів других, ТОЩО. З технічної точки зору це звічайні Git Гілки, а їх класіфікації буде візначатіся метою їх использование.
Рис. 6. Схема Утворення тематічної Гілки
тематичні Гілки є відгалуженням від РОБОЧОЇ Гілки (develop) i после Завершення розробки визначеного функціоналу на них повінні буті зліті самє з РОбочий гілкою. Такі Гілки можна назіваті будь-Якими іменамі, окрім master, develop, release- *, or hotfix- *.
тематичні Гілки Використовують для розробки НОВИХ, спеціфічніх функцій майбутньої Версії проекту. Основною особлівістю даних гілок є ті, что смороду існують доки триває розробка певної Функції проекту, а потім відбудеться їх злиттів з гілкою develop (у випадка Додавання новой Функції до новой Версії проекту) або и Взагалі будут зніщені (у випадка Невдалий експеримент їх! Застосування). Тематичні Гілки існують лишь в репозіторію Гілки develop.
Колі почінається робота над новою функцією проекту, то відбувається відвітлення від Гілки develop. Процес создания тематічної Гілки відбувається так:
$ git checkout -b myfeature develop
Отже, відбулося Створення і Переход на нову гілку myfeature raquo ;. После Завершення роботи на Цій гілці вона зіллється з гілкою develop:
$ git checkout develop//з єднання з гілкою develop
$ git merge --no-ff myfeature//злиттів змін Гілки myfeature з поточних develop $ git branch -d myfeature//відалення Гілки myfeature
$ git push origin develop//сінхронізація даних з віддаленім репозіторієм.
Використання параметра --no-ff забороняє виконан операции Fast Forward, тобто простого переміщення вказівніка Гілки по дереву, даже если це можливо [8]. Це дозволяє избежать Втратили информации про Існування тематичних гілок и згрупуваті разом усі компоненти, з якіх складатіметься новоутвори функція проекту. Порівняємо два способи процесса злиттів гілок.
Рис. 7. Схема злиттів гілок
У Першому випадка (ліва частина рис. 7) з історії проекту Неможливо виокремити ті про єкти, Які утворювалі нову функцію, а, отже, у разі спожи ее вдосконалення, слід буде ретельно переглядаті весь журнал повідомлень. Утім, процес повернення до всієї тематічної Гілки (тобто до групи фіксацій) буде очень складним. Избежать зазначену проблему можна за умови использование параметра -no-ff (права частина рис. 7). Звісно, ??такий ПІДХІД прізведе до создания декількох Додатковий коммітів (містять інформацію про злиттів, а в разі Виникнення конфліктів злиттів містітімуть такоже Зміни файлів, Які прізвелі до них), но Це не Завада проекту.
Гілки версій прізначені для підготовкі новой Версії проекту. Смороду дозволяють за мить до завершення роботи над поточних версією візначаті місця Підключення до головної Гілки, а такоже Надаються можлівість Виконувати незначні правки ї готувати дані про версию (номер, дата создания ТОЩО). Виконання такого виду операцій на гілці Версії дозволяє значний спростіті розгалуження головної Гілки develop. Відгалуження Гілки Версії від РОБОЧОЇ Гілки develop відбуватіметься за умови Отримання Бажанов стану новой Версії проекту на робочій гілці.
Гілки помилок функціонально очень схожі на Гілки версій, оскількі такоже Використовують для підготовкі новой Версії проектом, но створюються смороду спонтанно. Утворюються Гілки помилок у разі спожи виконан міттєвіх Дій Задля Усунення небажаним станів РОБОЧОЇ Версії проекту. Тобто, если нужно виправити критичність ошибку у робочій Версії проекту, то створюється відгалуження Гілки помилок від головної Гілки master, на того ее етапі, что відповідає робочій Версії проекту в цею момент годині. Сутта использование таких гілок є ті, что у разі Виникнення непередбачуваніх помилок робота членів команди на головній гілці develop НЕ буде Зупини, а помилки будут Швидко знайдені и Виправлені.
Технологія командної роботи над проектом
Вище розгл...
