Git Workflow

Вихідні, тож можна і похоліварити, але-ж не треба, насправді, хоч і тема така, що кожному своє. Але буду вдячний за будь-які посилання, а краще підводні камені та граблі з власного досвіду. Тобто, як краще робити, а чого краще не робити. Бо може я чогось пропускаю.

Треба якось формалізувати для всіх 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

Поділиться досвідом.

👍НравитсяПонравилось0
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я раджу починати не з розгляду конкретних підходів, а з визначення важливих для вашої команди цілей.

Якщо це:
— Налагодити чесний CI/CD.
— Мати високу культуру код ревью.
— Мінімізувати merge-конфлікти.
— Мінімізувати release цикл.
Тоді вам варто дивитись в сторону trunk-based development. Головний ризик — це попадання в реліз work-in-progress функціоналу. Для запобігання доведеться ввести систему feature flags, що само по собі відкриває цілу низку викликів.

Якщо це:
— Надати командам/розробникам велику автономію.
— Гарантувати реліз тільки завершеного функціоналу.
— Мати великий контроль над тим, який код попадає в реліз.
Тоді вам варто дивитись на gitflow. Основні ризики витікають з роботи в long-living branches. Це призводить до підвищення ризику виникнення merge-конфліктів і ускладнює code review.

Щось я не зрозумів, а в чому, власне, проблема?

Бажав почути, як організовано у інших. Може я щось упускаю... Може хтось наступив вже на граблі, скаже де вони заховані (якщо є)... Якось так.

Ок.
З ГітХаб форкфлоу ніколи не виникало проблем.

Таги є виключно на мастері... беремо останню стабільну версію з мастера як початок нової гілки

Якщо ви створюєте нову гілку з мастера, то яким чином теги пропадають із нових гілок? Теги ж указують на коміти, вони не прив’язуються до гілок.

Класичний Git Workflow дуже складний для цього

Для чого? Для запуску тестів?

GitHub flow ближче всього... Але чи не наступаємо на якісь граблі? Щось мені не подобається, але я не можу зрозуміти — що.

Ну якщо ви дотримуєтесь рекомендацій такої авторитетної платформи як github, то можете не боятись підводних каменів до того моменту, поки ви їх не почнете зустрічати. Це правило називається «не роби передчасну оптимізацію».

Якщо ви створюєте нову гілку з мастера, то яким чином теги пропадають із нових гілок? Теги ж указують на коміти, вони не прив’язуються до гілок.

Я в курсі ;) Хотів сказати, що теги є тільки на коммітах в мастер. Тобто, тільки на перевірених.

Для чого? Для запуску тестів?

Та ні, тестам все одно, як написано — так і виконаються. Для кожаних мішків команди, в даному випадку. :D Тобто багато зайвої роботи.

Тобто зараз беремо останню стабільну версію з мастера як початок нової гілки, доводимо до робочого варіанту, ревью та зліваємо з мастером. Гілка видаляється.

все норм, як на мене.
martinfowler.com/bliki/FeatureBranch.html

A feature branch is a source code branching pattern where a developer opens a branch when she starts working on a new feature.

Цікаво, у цьому реченні слово «she» хіба не перекладається як «вона»? Незвично таке читати. Це автор так підтримує жінок серед розробників?

Цікаво, у цьому реченні слово «she» хіба не перекладається як «вона»? Незвично таке читати. Це він так підтримує жінок серед розробників?

Это вообще отдельная проблема английского. До какого-то момента в подобной роли (род по умолчанию) было he. Потом навязывали she. Сейчас один из основных трендов — they (примерно так же, как когда-то you вытеснило thou). Столлман агитирует за zhe. Есть ещё десяток вариантов со своими сторонниками, но их ещё меньше.

Какого-то конкретного «він» тут скорее всего нет, но есть типовой для определённого окружения подход.

Подписаться на комментарии