Про варианты git workflow

Теги: cicd  python 

В сущности вариантов версионирования кода для [cl] огромное множество. Вкратце про те, котоыре основыаны на [git]

Gitflow

Самый распространенный вариант, довольно часто применяемый в монолитных проектах. Включает в себя:

• main ветвыь репозитория, которая используется для деплоя приложения на сервер
• development ветвь, используемая для разработки фичей и релизов. С main никогда непосредственно не сливается
• ветви фичей, образуемые от dev. Могут как завершаться. так и нет слиянием с dev. Никогда не сливаются с main
• ветвь релиза. Созается из dev, после чего производятся тесты и необходимые доработки. Фичи в эту ветвь, пока она открыта, не добавляются. После подготовки релиза, релиз сливается с dev и main, после чего удаляется.
• hotfix ответвляется от main чтобы исправить какие-то критичные ошибки, не останавливая процесс разработки

Подробнее об этом тут

Тут небольшая библиотечка, позволяющая вести gitflow с одним набором команд

Forking Workflow

В противоположность gitflow каждый разработчик ведет работу в форках основного репозитория, а не в клонах, корторые также базируются на стороне сервера. Это позволяет не комитить в основной репо, а заниматься полностью своими версиями, отправляя запрос на изменеение в основной репо, если это нужно. Вопрос объединения остается за овнером основного репо. Эта модель популярнак на опенсорсе. Подробнее тут.

Github Flow

Ссылка на гитхаб

Остновное отличие от gitflow в том, что нет рабочей ветки и релизов:

• каждая фича ведется в своей вектке
• когда фича готова, запрашивается pull request в main
• производится раззвертывание для тестов и обсуждение
• после чего плу реквест принимается и ветка фичи мержится или плу реквест отклоняется

Принципиальная разница в том, что процесс разработки в веках упрощавется и идет быстрее. Такая архитектура удобна для микросервисов. Тут подробная статья

Подробнее на github

Gitlab Flow

Разница с предыдущим вариантом в том, что сначала идет мерж, а потом развертывание и тесты, что потенциально грозит сложным reverse merge в ситуации, когда измененеия необходимо откатить. ссылка на статью на gitlab

GitHub flow as a simpler alternative

Production branch with GitLab flow

Environment branches with GitLab flow

Release branches with GitLab flow