Вариант работы с контролем версий (аналог git-flow)

Такое где-то было, кажется в мейле и на какой-то странной vcs. Говорили что ад и погибель, тонны автоматики которая все время сбоит

Но это так, через третьи руки, хз, feature-флаги проще кмк

мне кажется идея обобщить подход работы с гитовыми ветками - утопичная идея. у каждого проекта найдутся свои корнеркейсы, которые просто не вписываются в красивую картинку.

один из наглядных примеров - кажущаяся идилия с фича-бранчами, которые можно в один букет смержить и потестить просто разбивается о суровую реальность ибо очень часто эти фичабранчи имеют зависимости между собой.

еще одно из мнений, которое я никогда не понимал - показушное храниние всех коммитов процесса разработки какого-то фича-бранча. еще ни разу в жизни не сталкивался с потребностью (ни у себя, ни где-то у других) заглянуть в какой-нибудь 105ый коммит какого-нибудь фичабранча.

резюмирую… с годами выработал простой подход

• мастер бранч с тегами релизов, откуда могут бранчеваться релизные бранчи если (это для саппорта внешних потребителей, кому отгрузили определенную версию и нужно саппортить его какое-то время)

• предрелизный (читай как тестовый). формируется после каждого релиза как точка отсчета для следующей разработки. по завершению она вмерживается в мастер схлапывая все коммиты в один. на нем же всякие тесты гоняются.

• остальная разработка ведется путем бранчевания от предрелизного

• если какая-то фича А зависит от фичи Б, то бранч А должен создаваться от бранча Б. если обе фичи зависят др от друга - увольняйте вашего ПМ или лида ибо кто-то из них не умеет в планирование.

• каждый разраб работает в клоне и бранчуется локально от фича-бранча. коммиты ведет ровно так, как ему хочется (хоть каждую букву коммитит). но пул-реквест должен быть одним коммитом с нормальным описанием.

работал в одном проекте, где лид любил ребейзить пачку коммитов. это полный *****ц был потом каждый раз выравниваться на его ребейзы.

Я тебе скажу, что фичефлаги не панацея и с ними много проблем, например десятки if-else, плюс часто асинхронщина. Короч такое.

Но вообще, одно другому не мешает.

и на какой-то странной vcs

Может в этом была проблема? Потому что если мержится плохо, то там, очевидно, повесишься. Особенно если сборки раз-два в день, если она длится часы, если сама инфраструктура сборки отваливается все время. Ну в этом плане да, чаще закидывать говнягу в репу проще.

Не взлетит, т.к. невозможна ситуация, когда фичи не зависят друг от друга.

В реальном проекте ещё и порядок мержа фич-веток будет иметь огромное значение.

Поддерживать весь этот зоопарк будет в разы сложнее, нежели смириться с несовершенством git-flow.

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

Есть альтернатива git-flow: https://github.com/rocketraman/gitworkflow

Честно говоря, не вчитывался в отличия и не пытался понять преимущества.

Ещё надо иметь в виду, что разработчики - такие же ленивые и неумные существа, как и все остальные (хотя считают себя самыми умными). И на самом деле, 80-90% не могут осилить до конца даже простой воркфлоу add/commit/push без ошибок. Про merge и rebase уж даже не говорю. И какие-то продвинутые workflow может оказаться вообще невозможно внедрить в том числе и по этой причине.

В реальном проекте ещё и порядок мержа фич-веток будет иметь огромное значение.

Та не. Там единственный вопрос на кого конфликт свалится.

не сталкивался с потребностью (ни у себя, ни где-то у других) заглянуть в какой-нибудь 105ый коммит какого-нибудь фичабранча.

Иногда в каком-нибудь долгом проекте видишь код, по которому невозможно понять, зачем он был добавлен. Было ли это исправление ошибки или костыль.

Он может мешать добавить новый код или мешать рефакторингу. Но т.к. нет соотв. комментария, как правило, не получается понять, можно ли его безболезненно удалить. Или в проде вдруг всё рассыпется в неожиданный момент, потому что этот костыль подпирал что-то важное и неочевидное.

Иногда история того, как оно появилось в коде, помогает разобраться. Но не всегда.

Тем не менее, встречаюсь с такими ситуациями минимум 1-2 раза в год.

Автор того гитфлоу, которое ты (и все) имеют в виду (с первых страниц гугла) придумал оное в 2010м году для мелких команд. С тех пор его так достало, что все ссылаются на его процесс как на какую-то догму, что он отдельно написал «придумайте уже что-то свое». В книжках по гиту описывают до 10+ разных вариантов работы с гитом, в т.ч. «схему с диктатором патчами по почте» (привет аквалангисту). Так что... любая схема работы с гитом может называться «гитфлоу», и она либо подходит тебе, либо нет :) «узбагойзя и придумай свою» (тм)

Не взлетит, т.к. невозможна ситуация, когда фичи не зависят друг от друга.

Эту проблему теоретически можно решить, например всегда есть ветка текущей тестовой сборки в которой есть все.

Либо написать какую-нибудь несложную тулзу, которая будет притаскивать нужные фичи.

например десятки if-else

Чёт слишком дохрена. 10 фичей разом катить это перебор, а старые - чистить надо. Но так да, флаги не панацея, особенно если логика сложнее чем жсон переложить.

Но кмк автомерж это тоже ни разу не выход, нужно до фига проверок что все смержилось корректно, а проверок дофига по определению не бывает. Плюс некоторые вещи нереально смержить автоматом, и даже руками сложно бывает.

Ну и ещё миграции. Иногда чтоб откатить сложную миграцию надо присесть сильно больше чем «убрать коммит из релиза»

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

есть такой подход: trunk based development, мы как раз его в флюссонике придерживаемся.

Хочешь что-то написать — делаешь бранч, пишешь в него, потом мержишь.

Чем мельче бранчи, тем меньше сюрпризов при мерже.

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

Плюс некоторые вещи нереально смержить автоматом

Скорее нет, чем да. Когда постоянно несколько человек переписывают один файл - это что-то странное.

Ну и ещё миграции.

Не все можно откатить)

Да не работает это когда разработчиков хотя бы десятки, это уж не говоря про сотни. Когда народу много все можно делать только через автоматизацию.

Когда постоянно несколько человек переписывают один файл - это что-то странное

Да легко. Если апишка или .proto файлы - почти всегда. Если монга с её денормализацией - тоже. Тебе ж надо смержить все файлы, а не только бизнес-логику

Когда менеджмент обосрался, разработчикам только и остаётся затыкать дыры техническими способами, они же последнее звено в иерархии. У linux тысячи контрибьютеров и всё прекрасно работает. Да вообще много проектов, где это работает.

Вот тут хорошо описано: https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

Всю главу надо просмотреть и по ссылкам сходить.

У linux тысячи контрибьютеров и всё прекрасно работает.

Ядро линукса не идет в релиз сразу как выпустилось - вообще не корректный пример. Там по факту весь процесс тестирования потом берут на себя те, кто это ядро будет использовать.

Этот способ работает когда нет фактора времени и фактора ответственности. Что не совсем подходит, когда ты дописываешь софт, который работает здесь и сейчас. Разные задачи.

Похоже ты хочешь фича-бранчи. Они работают только при экстенсивной разработеке. Например 100500 микро-сервисов на 100500 разрабов в монорепе. Или 100500 страничек сайта. Т.е. код, который не трогают после написания.

При наличии общих кусков кода любой рефакторинг приводит к тому, что мерж фичабранчей требует вдвое больше времени, чем написание кода для них.

При наличии общих кусков кода любой рефакторинг приводит к тому, что мерж фичабранчей требует вдвое больше времени, чем написание кода для них.

С этим вряд ли поспоришь.