RDCLR.DEV

Сколько веток должно быть в репозитории

🕑 Сразу определимся, что мы говорим только о долгоживущих ветках, то есть ветках, не зависящих от текущих задач, релизов и т.д.

Давайте разберем ответы из нашего опроса с конца:

👩‍🔧 По количеству разработчиков + 1.
Наверное, тут есть логика, что каждый девелопер работает в своей ветке и время от времени все сливают свои изменения в одну общую. Но почему бы не создавать новую ветку под задачу и потом закрывать ее после мерджа, переходя к следующей? Непонятно. Вариант синтетический, и, на мой вкус, не очень осмысленный.

🖥 По числу стендов и окружений.
Этот подход действительно много где применяется. Его концепция в том, что у нас есть одна основная ветка с кодом и по ветке на стенды: тест, стейдж, прод и т.д. Ветки, ассоциированные со стендами, содержат специфические настройки окружений. Например, разработческая и тестовая ветки могут ходить на единичный инстанс БД, а стейдж и продакшн поддерживать архитектуру мастер-реплика. Минус здесь в том, что, по сути, на каждый стенд вы деплоите разный код, собранный специально для этого стенда. И гарантировать одинаковое поведение системы невозможно.

🔗 Две ветки — develop и master.
Это отсылка к широко известному GitFlow со всеми его плюсами и минусами.
Вообще говоря, с момента появления GitFlow прошло больше десяти лет, а с тех пор многое изменилось. Появилась концепция микросервисов, Docker, клауды и инструменты Infrastructure as Code. Ну и родился он в недрах Linux сообщества для координации работы большого количества программистов, пишущих монолитный продукт со множеством инсталляций в условиях, когда нужно поддерживать и развивать несколько версий. Если ваш продукт подходит под это описание, то... ну почему бы и нет. Но если у вас микросервисы и по одному репозиторию на компонент, как описано в предыдущем посте, то развлечения с ветками, разъехавшимися версиями на окружениях, поиском коммитов в ветках, мерджами и конфликт резолвингом вам гарантированы.

❓ Почему так? Потому что, если у вас несколько долгоживущих веток, рано или поздно они они начинают различаться все сильнее и сильнее. Радикальный способ избавиться от этой проблемы —>

🦄 Одна долгоживущая ветка.
С непривычки звучит странно, но все чаще современные методологии разработки строятся на этом принципе. В следующем посте мы поговорим об одной из самых популярных — философии Trunk Based Development.

Keep tuned.

#rdclr_backend #rdclr_frontend #product

www.tgoop.com/rdclr_dev/67

326 viewsDec 28, 2021 at 16:57

Сколько веток должно быть в репозитории

🕑 Сразу определимся, что мы говорим только о долгоживущих ветках, то есть ветках, не зависящих от текущих задач, релизов и т.д.

Давайте разберем ответы из нашего опроса с конца:

👩‍🔧 По количеству разработчиков + 1.
Наверное, тут есть логика, что каждый девелопер работает в своей ветке и время от времени все сливают свои изменения в одну общую. Но почему бы не создавать новую ветку под задачу и потом закрывать ее после мерджа, переходя к следующей? Непонятно. Вариант синтетический, и, на мой вкус, не очень осмысленный.

🖥 По числу стендов и окружений.
Этот подход действительно много где применяется. Его концепция в том, что у нас есть одна основная ветка с кодом и по ветке на стенды: тест, стейдж, прод и т.д. Ветки, ассоциированные со стендами, содержат специфические настройки окружений. Например, разработческая и тестовая ветки могут ходить на единичный инстанс БД, а стейдж и продакшн поддерживать архитектуру мастер-реплика. Минус здесь в том, что, по сути, на каждый стенд вы деплоите разный код, собранный специально для этого стенда. И гарантировать одинаковое поведение системы невозможно.

🔗 Две ветки — develop и master.
Это отсылка к широко известному GitFlow со всеми его плюсами и минусами.
Вообще говоря, с момента появления GitFlow прошло больше десяти лет, а с тех пор многое изменилось. Появилась концепция микросервисов, Docker, клауды и инструменты Infrastructure as Code. Ну и родился он в недрах Linux сообщества для координации работы большого количества программистов, пишущих монолитный продукт со множеством инсталляций в условиях, когда нужно поддерживать и развивать несколько версий. Если ваш продукт подходит под это описание, то... ну почему бы и нет. Но если у вас микросервисы и по одному репозиторию на компонент, как описано в предыдущем посте, то развлечения с ветками, разъехавшимися версиями на окружениях, поиском коммитов в ветках, мерджами и конфликт резолвингом вам гарантированы.

❓ Почему так? Потому что, если у вас несколько долгоживущих веток, рано или поздно они они начинают различаться все сильнее и сильнее. Радикальный способ избавиться от этой проблемы —>

🦄 Одна долгоживущая ветка.
С непривычки звучит странно, но все чаще современные методологии разработки строятся на этом принципе. В следующем посте мы поговорим об одной из самых популярных — философии Trunk Based Development.

Keep tuned.

#rdclr_backend #rdclr_frontend #product

BY RDCLR.DEV