Гит под капотом — это просто хранилище версий, база данных, которая фиксирует дельту изменений. Благодаря этому, мы можем откатиться к любому сохраненному состоянию нашего проекта.
Но ценность гита не только в «машине времени», но и в концепции веток. Ветка — это виртуальная копия состояния системы, которая позволяет работать изолированно.
В командной разработке без веток наступает коллапс. Если три разработчика пилят разные фичи в одном потоке, любой баг блокирует работу остальных разработчиков, кто занимается этим же проектом. Разработка превращается в очередь: все ждут, пока один пофиксит свои ошибки, чтобы просто продолжить работать.
Ветки решают проблему параллелизма. Вы работаете в своей «песочнице», а когда функционал готов — схлопываете изменения в основную ветку (
main или master) одним мерж-коммитом.Git Flow: Когда релиз превращается в бутылочное горлышко
Методологий использования git и веток масса. Самый распространенный подход — Git Flow. У вас есть
main (стабильный код в продакшене) и dev (черновик, где собираются все новые фичи). dev всегда на шаг впереди, там тестируются новые фичи и копится код для будущего релиза.И вот когда релиз готов, мы сливаем ветку
dev в ветку main и пользователи получаю новые фичи, а разработчики начинают работать над новым релизом. Проблема Git Flow в его линейности. Если на релиз запланировано 10 фич, и одна из них готова только на 90% (разработчик заболел или задача оказалась сложнее), весь релиз парализован. Пользователи не получают готовые 90% функционала, потому что они «заперты» в одной ветке
dev вместе с недоделками. Continuous Integration: Отмена релизных циклов
В философии CI (Continuous Integration) мы не ждем «дня релиза». Код улетает в лайв по 10-20 раз в день, как только фича готова и прошла все тесты.
Стандартная схема
main + dev здесь рассыпается: вы не можете подлить в прод одну конкретную фичу из dev, не зацепив при этом весь остальной «мусор», который еще не готов к деплою.Для решения этой задачи архитектура веток усложняется. Под каждую задачу создается не одна, а две ветки: одна для интеграции в
dev (чтобы проверить совместимость), вторая — изолированная — для мерджа напрямую в main, когда тесты пройдены. Именно такой подход позволяет нам доставлять фичи изолированно и независимо от других задач. На крупных проектах стейджей может быть еще больше:
master, pre-master, integration, development. Каждая ветка соответствует конкретному окружению (серверу), где живет код.Гит дает гибкость. Вы можете выстраивать цепочки любой сложности, чтобы разносить состояния системы и не зависеть от чужих багов. Это механизм, который превращает хаотичное написание кода в управляемый инженерный процесс.
🔥 — если за минимализм и две ветки.
🚀 — если плодите ветки под каждый стейдж.
А если остались вопросы или что-то звучит слишком абстрактно — пиши в комменты, обязательно разберем!
10МДК | ВЕБМастер