Принципы поддержания стабильности кодовой базы и обеспечения эффективной командной работы
Незавершенный код (часто называемый WIP - Work In Progress) — это любой код, который не соответствует критериям готовности для интеграции в общую кодовую базу.
Главный признак: Если такой код попадет в общую ветку, он с высокой вероятностью сломает сборку или нарушит работу других разработчиков.
Это фундаментальное правило GitFlow, и оно существует по нескольким ключевым причинам:
Ветка develop в GitFlow представляет собой готовый к следующему релизу код. Это "основная линия" разработки. Если она нестабильна, то:
Представьте, что вы начинаете новую задачу. Вы делаете git checkout develop; git pull и обнаруживаете, что проект не собирается. Вам приходится тратить время на поиск виновника и решение проблемы, которая не имеет отношения к вашей задаче. Это убивает продуктивность.
Одна из целей GitFlow — быть готовым к выпуску новой версии в любой момент. Если develop всегда находится в рабочем состоянии, то создание ветки release — это быстрая и безопасная операция.
Это правило прививает культуру ответственности. Разработчик не может "забросить" свой незавершенный код в общее пространство. Он обязан довести его до ума, протестировать и только затем интегрировать. Это напрямую повышает качество продукта.
Важно: Нарушение этого правила приводит к "синдрому сломанной сборки", когда команда тратит больше времени на исправление проблем интеграции, чем на разработку новой функциональности.
Прямого указания в стиле "не сливайте неработающий код" в виде единого стандарта нет, но этот принцип является краеугольным камнем всей методологии. Он логически вытекает из описания веток и их назначения.
Первоисточником считается знаменитая статья Винсента Дриссена (Vincent Driessen), которая и ввела термин "GitFlow".
Ссылка на статью: A Successful Git Branching Model
Если внимательно прочитать статью, то можно увидеть, что автор описывает ветку develop как основную, где происходит интеграция законченных функций.
"When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number."
Ключевые слова — "stable point" (стабильное состояние) и "ready to be released" (готово к релизу). Это состояние невозможно достичь, если в develop постоянно мержится незавершенный код.
Более поздние инструменты и статьи, объясняющие GitFlow, делают это правило еще более явным. Например, в популярной библиотеке git-flow (расширение для Git) процесс завершения фичи (git flow feature finish) автоматически мержит вашу ветку в develop, что подразумевает, что к этому моменту она уже готова.
Вместо мержа в develop используйте правильные практики:
Это ваша песочница. Коммитьте туда так часто, как хотите, даже если код нерабочий.
git rebase (с осторожностью)Чтобы поддерживать свою ветку в актуальном состоянии с develop, перебазируйте ее, а не мерьте develop в свою фичу. Это сохранит историю чистой.
Разбейте большую задачу на подзадачи и почаще интегрируйте маленькие, но законченные куски кода в develop. Это снижает риск конфликтов и упрощает код-ревью.
Настройте автоматические проверки, которые не позволят замержить код, не прошедший тесты и линтеры.
Запрет на мерж незавершенного кода в develop — это не просто "принято", это основополагающий принцип GitFlow, необходимый для поддержания стабильности, обеспечения командной работы и достижения высокого качества кода.
Он прописан между строк в оригинальной статье, описывающей модель, и является следствием логичного разделения веток по их назначению.