Git Workflow
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Вихідні, тож можна і похоліварити, але-ж не треба, насправді, хоч і тема така, що кожному своє. Але буду вдячний за будь-які посилання, а краще підводні камені та граблі з власного досвіду. Тобто, як краще робити, а чого краще не робити. Бо може я чогось пропускаю.
Треба якось формалізувати для всіх Workflow. Точніше, я зараз переписую те, що є.
Початкові дані — є невеличкі (відносно) модулі, які змінюються раз у спринт (не всі, але зміна кожного не може бути довшою, ніж один спринт — бо вони маленькі і там нічого робити на кілька спринтів). Таги є виключно на мастері. Код в мастері виключно стабільний — тобто він успішно проходить всі тести що є (без цього він не може бути смерджений у мастер взагалі). Кожен пуш в будь-яку гілку запускає всі тести (код не великий, тож це не дуже довго, але треба перевірити багато чого, руками це робити важко. Частину тестів локально неможливо виконати.
Класичний Git Workflow дуже складний для цього. До того-ж, старі версії (що відмічені тагами) ніколи не змінюються. Тобто, можна вважати, що у модуля є (використовується) тільки остання стабільна версія. GitLab flow теж виглядає занадто складним із трьома гілками.
GitHub flow ближче всього. Тобто зараз беремо останню стабільну версію з мастера як початок нової гілки, доводимо до робочого варіанту, ревью та зліваємо з мастером. Гілка видаляється. Після , можливо, тесту на не критичних проектах, створюється новий таг. Все майже просто. Гілки створюються або (рідко) для якогось виправлення (fix_) або для для нового функціоналу (feature_). Але чи не наступаємо на якісь граблі? Щось мені не подобається, але я не можу зрозуміти — що.
Читати:
docs.microsoft.com/...uidance?view=azure-devops
trunkbaseddevelopment.com
guides.github.com/introduction/flow
docs.gitlab.com/...e/topics/gitlab_flow.html
Поділиться досвідом.
10 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів