Эксклюзивно на Telega.in

Артём Харченков | IT Инсайты

Здесь я делюсь мыслями и полезным контентом для сотрудников ИТ и их руководителей. За плечами у меня 12-летний опыт в ИТ. Буду рад, если кому-то мой канал поможет!

О канале
Полная статистика

Статистика

Количество постов

292

Среднее количество просмотров на пост

332

Средний охват (48ч)

168

Упоминаний

Получить детальную аналитику

Последние посты канала

imageИзображение недоступно для предпросмотра

...продолжение предыдущего поста

Когда ваш проект становится хотя бы немного похож на серьёзное приложение, советую переходить на Git Flow — это стандарт организации ведения веток при совместной разработке. Тут тоже всё не сложно, но участвуют чуть больше веток. Обычно набор такой:

main/master — стабильный продакшен-код
develop — текущая разрабатываемая версия
feature/* — ветки для разработки фич
release/* — ветки для подготовки релиза
hotfix/* — ветки для срочных исправлений

Например, когда вы как разработчик взялись написать функцию оплаты, то вы создаёте себе новую ветку, копируя код из develop, а по окончании разработки снова заливаете в develop. Весь путь функции в гите будет выглядеть примерно так:

develop → feature/payment (2 недели разработки) → develop

Продолжая аналогию с документами, мы копируем себе актуальный файл, вносим туда правки, а потом делаем запрос на слияние (Merge Request) наших изменений в актуальный файл.

Иногда случается так, что чуть раньше другой разработчик Игнат уже внёс свои изменения в актуальный файл develop и изменил те же кусочки кода (абзацы), что и вы. В этом случае система подсветит это как конфликт, который вам нужно будет устранить: решить, какую версию абзаца взять — вашу или Игната. А уже после разрешения всех конфликтов и Code Review от лида наша функция загружается в develop — ура!

Когда наступает время выпускать релиз, лид копирует код из develop-ветки в «релизную». Например, для релиза v1.2.0 путь будет выглядеть так:

develop → release/v1.2.0 (тестирование, фиксы багов) → main + develop

По такому флоу живут практически все серьёзные проекты, в том числе те, у которых открытый исходный код (Open Source). По факту Git Flow — это стандарт индустрии, с которым вам придётся столкнуться на любом месте работы, который хотя бы немного перестаёт быть стартапом.

——

Сегодня мы стали знать чуть больше о Git Flow, Trunk Based и Feature Flags.

В двух постах мы разобрали основную суть самых популярных подходов к версионированию кода при совместной разработке. Как и во всех темах, тут есть нюансы, но те самые 20%, которые дают 80% результата, я описал выше.

А что используется у вас — Trunk Based, Git Flow или что-то своё?)

Тема достаточно техническая, поэтому интересно знать ваше мнение, насколько интересны подобные разборы. Поэтому, голосуем)

Ставьте 👨🏻‍💻, если подобные технические штуки интересны
Ставьте 🤓, если больше хочется про менеджмент и управленческие темы

175

11:06

21.10.2025

imageИзображение недоступно для предпросмотра

Вижу, что пост про тест стабильности, где я объясняю эту айтишную тему простым языком, нашёл достаточно отклика).

Я искренне считаю, что даже самые сложные вещи в этом мире можно объяснить «на пальцах» — с помощью аналогий и примеров. Если вы хорошо понимаете, как и где применяется технология или термин, вы всегда сможете выделить те самые 20% из принципа Парето и кратко изложить его суть как для своей бабушки.

Давайте сегодня попробуем сделать это для ещё одной полезной темы — подходов к совместному программированию.

Думаю, все знают, что для одновременной разработки программисты используют систему контроля версий Git. Основной сущностью там является ветка. По сути, ветки — это копии кода приложения с некоторыми изменениями под конкретные цели, аналогично, например, версиям текстовых документов. Просто студенты сохраняют файлы в папки, называя «Курсовая_1», «Курсовая_2», «Курсовая_2_финал», «Курсовая_2_точно_финал!!», а у программистов есть для этого специальная система с совместным доступом)).

В небольших проектах, когда несколько разработчиков пишут код одновременно, они могут заливать свои наработки и реализованные функции (делать коммиты) прямо в основную ветку, которая обычно называется main (или master). Это работает, когда сами фичи маленькие, делаются за 1–2 дня и изменения, которые в проекте делает Вася, не пересекаются с изменениями Стёпы.

Например, Вася реализует функцию оплаты, а Стёпа пишет авторизацию. Такой подход к совместной разработке называется Trunk Based. Чаще всего в этом подходе функции, которые разработчики только что реализовали, не тестируются отдельно: проверяется сразу вся система после реализации и влития в main сразу всех функций. Из проверок тут только вычитка кода (Code Review), который написал Вася и Стёпа их лидом перед тем, как загрузить его в main.

Честно говоря, в своё время я был сильно удивлён, когда, проводя собеседования, узнал, что во многих командах такой подход используется даже на достаточно больших проектах.

Представляете себе огромный монолит, который дорабатывают 5–6 человек, и каждый сразу пушит в основную ветку main? Очевидно, что когда перед релизом вы будете тестировать продукт (а вы же будете, верно?)), вы наткнётесь на баги, понять причину которых будет проблематично. Будет сложно выявить, в какой момент они возникли и именно что их вызвало — изменения Васи, Стёпы или вообще их комбинация.

Чтобы хоть немного минимизировать эти проблемы, придумали такую тему, как Feature Flags. Это подход, когда вы пишете какую-то функцию, но блок кода, который отвечает за неё, «включается» только когда вы указываете в конфиге в true какую-то переменную. Что-то типа:

if (new_payment_system == true) then
return processPaymentNewMethod();
else
return processPaymentLegacy();

Штука, конечно, полезная, но имеет много ограничений. Например, если ваша новая функция требует написания большого количества кода в разных местах, вы просто замучаетесь везде проставлять этот флаг, а потом везде его убирать)).

В общем, всё это работает в маленьких проектах.

А что лучше использовать в проектах побольше, напишу в посте ниже… 👇🏻

153