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

markdown source:
---
description: Декоратор wait для behave
tags: cicd python
title:  Про варианты git workflow
---
В сущности вариантов версионирования кода для [[cl]] огромное множество. Вкратце про те, котоыре основыаны на [[git]]

## Gitflow

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

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

[Подробнее об этом тут](https://www.atlassian.com/ru/git/tutorials/comparing-workflows/gitflow-workflow)

[Тут небольшая библиотечка](https://danielkummer.github.io/git-flow-cheatsheet/index.ru_RU.html), позволяющая вести gitflow с одним набором команд

## Forking Workflow

В противоположность gitflow каждый разработчик ведет работу в форках основного репозитория, а не в клонах, корторые также базируются на стороне сервера. Это позволяет не комитить в основной репо, а заниматься полностью своими версиями, отправляя запрос на изменеение в основной репо, если это нужно. Вопрос объединения остается за овнером основного репо. Эта модель популярнак на опенсорсе. [Подробнее тут](https://www.atlassian.com/ru/git/tutorials/comparing-workflows/forking-workflow).

## Github Flow

[Ссылка на гитхаб](https://docs.github.com/en/get-started/quickstart/github-flow)

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

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

Принципиальная разница в том, что процесс разработки в веках упрощавется и идет быстрее. Такая архитектура удобна для микросервисов. [Тут подробная статья](https://habr.com/ru/post/346066/)

[Подробнее на github](https://mcs.mail.ru/help/ru_RU/manage-k8s/k8s-docker-reg)

## Gitlab Flow

Разница с предыдущим вариантом в том, что сначала идет мерж, а потом развертывание и тесты, что потенциально грозит сложным reverse merge в ситуации, когда измененеия необходимо откатить. [ссылка на статью на gitlab](https://docs.gitlab.com/ee/topics/gitlab_flow.html)

### GitHub flow as a simpler alternative

![GitHub flow as a simpler alternative](../attachments/2021-09-20-22-41-46.png)

### Production branch with GitLab flow

![Production branch with GitLab flow](../attachments/2021-09-20-22-42-16.png)

### Environment branches with GitLab flow

![Environment branches with GitLab flow](../attachments/2021-09-20-22-43-35.png)

### Release branches with GitLab flow

![Release branches with GitLab flow](../attachments/2021-09-20-22-44-15.png)


[cl]: cl "ci/cd - непрервыная интеграция"
[git]: ../lists/git "Git"