В предыдущих статьях мы уже затрагивали тему подходов при работе с git и подробно рассматривали метод Gitflow и Feature Branch Workflow как основу коллективной работы над кодом. Напомним, что основной идеей в Gitflow является создание feature-веток – для разработки одного нового функционала создается отдельная ветка, которая вливается в ветку develop, когда работа над функциалом окончена. При этом нередко возникают сложности с разрешением конфликтов, сломаными сборками.
В данной статье мы рассмотрим альтернативный подход для контроля версий исходного кода – разработка на основе главной ветки, или Trunk-Based Development. В ее основе лежит такая модель ветвления, в которой разработчики совместно работают над кодом в одной ветке, называемой «главной» (или master в терминологии Git). При этом второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни. Этот подход прочно занимает свои позиции наряду с другими документированными методами разработки в долгосрочных ветках и позволяет разработчикам избежать сложностей связанных со слиянием веток. Словосочетание «главная ветка» (от англ. “trunk” - ствол) несет в себе идею растущего дерева, у которого самой толстой и самой длинной частью является именно ствол, а не ветви, которые расходятся от него и имеют более ограниченную длину.
После того, как разработчики долго используют Gitflow, данный подход может выглядеть наивным и примитивным, однако, для проектных команд, которые сфокусированы и стремятся продвигаться максимально быстро, именно такой подход может дать лучшие результаты.
При использовании разработки на основе главной ветки процессы непрерывной интеграции и непрерывной поставки являются критически необходимыми, так как позволяют участникам команды прогнозируемо интегрировать свои наработки в основной код с обеспечением гарантии качества результата.
Один из приверженцев подхода TBD, выступая на конференции JAX, говорил, что у них в команде есть большая красная сирена, которая воет каждый раз, когда интеграция неуспешно. Это мотивирует участников команды делать изменения такими компактными, чтобы шанс их интеграции без ошибок был максимально выскоким.
Данная статья является переводом оригинальной статьи с официального сайта подхода TBD – trunkbaseddevelopment.com.