Давайте вспомним две самые популярные на сегодняшний день branching model. • Gitflow • Trunk Based Development (TBD) Когда-то очень давно я старался придерживаться модели Gitflow и строить процесс разработки и управления кодом вокруг этой модели. Со всё большим погружением в философию DevOps и в практики Continuous Integration, Continuous Delivery и её подвида Continuous Deployment всё чаще складывалось ощущение, что что-то не так. Почему так неудобно? Зачем эти страдания при решении мерж-конфликтов? Почему ветки такие гигантские и их так сложно ревьюить? В какой-то момент я познакомился с моделью TBD и для меня это был некий сдвиг парадигмы и скачок в развитии. TBD - это не просто branching model, это ещё и ряд практик, техник и подходов к разработке. Не хочу перечислять все достоинства и пересказывать всю крутость TBD. Вы можете прочитать про это в документации по ссылке выше. Но я хочу упомянуть одну из практик в TBD, которая часто является самой сложной в осознании и применении. Эта практика называется "Branch by abstraction" и картинка этого поста посвящена ей. Идея в том, чтобы не делать одну гигантскую ветку на всю фичу и вместо этого делать много маленьких веток, каждая из которых содержит очередной маленький шажок в реализации фичи. Такой подход, очевидно, не решает вообще всех проблем. У нас точно всё ещё останутся какие-нибудь миграции на новые версии библиотек, у которых изменились SDK/API/сигнатуры методов. У инженеров, которые впервые слышат про этот подход, часто появляется куча противоречий в голове. Как я могу себе позволить мержить в мастер кусок недоделанной фичи? А что если я кого-то сломаю? И так далее. Очевидно, что автоматизированное тестирование и feature flags решают эту проблему. Если вы не слышали или ещё не используете TBD, то крайне рекомендую начать погружение как можно раньше. #picture #link #thought