Comments 14
Сколько лет этому флоу? А сколько лет уже говорят что не надо его использовать? Есть же https://githubflow.github.io/ или еще больше примеров в Trunk Based Development https://trunkbaseddevelopment.com/ . Но только не гит флоу.
И разберитесь как правильно использовать Git merge vs rebase. Если коротко, то Rebase можно использовать ТОЛЬКО если вы еще не делились своей историей, не делали push. Все остальное время вы делаете merge.
Чистота коммитов - это не то о чем надо заботится в репе. Репа это про изменения в коде, и нет смысла их прятать. Разве что вашим разработчикам стыдно показывать свою работу другим. Но это к психологу. В остальных же случаях, когда говорят про чистоту коммитов, имеют ввиду порядок коммитов для системы релизов. Чтобы коммиты-релизы шли один за другим по порядку. В этому случае - у вас не доделанный пайплайн. Релизы это не про коммиты. Добавьте гит тэги, если их нет. Или уберите, если вы тэгаете все подряд.
Извините что так резко, у меня ПТСР после всего этого. но переписывать уже лень.
Кто вам сказал, что githubflow это альтернатива для gitflow? Да и TBD, хоть и классный, но точно не альтернатива gitflow.
Flow выбирается не от хотелки разработчика, а от процессов в компании. У всего есть плюсы и минусы.
А в остальном согласен :D
Уточните пожалуйста, кто вам сказал что это не альтернатива?
Не всегда флоу выбирается под процессы. Всегда имеет место человеческий фактор - кто-то нагуглил и не изучил альтернативы.
Утверждение что он "самый популярный" - никакими цифрами не подтверждается.
SWOT анализ нам тут не показали. Только хотелки в ведении. И все эти хотелки гараздо лучше решаются TBD или Github Flow.
Если для вас процессы это важно и вам нужен CI/CD то может автор Continuous Delivery вам расскажет понятнее https://www.youtube.com/watch?v=_w6TwnLCFwA
Вот цитата с сайта атласина про гит флоу:
Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. Gitflow also can be challenging to use with CI/CD. This post details Gitflow for historical purposes.
А вот ссылка на страницу автора Гит Флоу - https://nvie.com/posts/a-successful-git-branching-model/
Просто перестаньте это использовать. Пристрелите уже лошадь.
Gitflow also can be challenging to use with CI/CD.
Да нормально он может работать. Просто надо добавить существенную деталь. Репозитариев должно быть несколько. Один - публичный, с которого все продуктовые версии всеми, кому над, собираются и откуда все 'стабильные' изменения тянут. И еще один - тестовый, куда все изменения пушат и где происходит описанные в GitFlow слияния. После чего CI/DI их вытягивает, тестирует итд итп. И только после этого все уходит в публичный.
В то время, когда GitFlow описывалось - это само получалось, т.к. такой централизации на одни сервис не было. Люди, занимающиеся тестированием и окончательной сборкой все к себе на машины вытягивали и то, что я выше назвал 'тестовым' только у них на машинах и было. А потом это незаметная но нужная особенность поломалась.
Ну и из-за той же централизации - боязнь замусоривания репозитария ветками. Конечно, будет замусоривание, если всем одним и тем же 'центральным' репозитарием для всех целей пользуются.
У меня нет ни малейшего сомнения, что вы заставите это работать технически. Многие уже делали.
Суть в том, что практически в 2025 году мы видим на популярном ресурсе статью, в которой рассказываю про Гит Флоу как актуальный метод работы, хотя он уже как 5 лет признан автором и комьюнити устаревшим и имеет пару преемников.
И они появились не просто так, а по тому что они проще и удобнее. Разработчикам не надо думать "в какую ветку сейчас пушить?" и не надо использовать дополнительный инструмент. Что упрощает ежедневную работу и ускоряет поставку.
А в чем проблема с "замусориванием" - ветки не удаляются? Теперь вы предлагаете вообще мульти-репу... Это еще больше усложняет подход. Тем самым вы практически сделаете невозможным CI.
Да и зачем что-то тянуть к себе локально из разных реп, когда это все должно храниться в 1 репе и тестироваться в пайплайнах? У меня все больше вопросов к вашему процессу сборки, тестированию и деплоя. Но углубляться в это в комментариях не лучшая идея. Если кому интересно можете постучать в личку.
Но в целом этот процесс далек от CI\CD и от Continuous Delivery.
хотя он уже как 5 лет признан автором и комьюнити устаревшим и имеет пару преемников.
С ссылки от автора:
If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.
Софт вебсайтами с одним экземпляром запущенной системы не ограничивается.
И если нужно поддерживать и выпускать обновления к SoftName v2.* одновременно с SoftName v3.* - то все способы будут выглядеть как GitFlow плюс-минус незначительные изменения.
Если у вас сразу несколько версий в проде - значит надо относиться к ним как к актуальным. Т.е. хранить их код в 1 репе в 1 бранче в разных модулях. Тут работает та же стратегия что и с версионированием API.
Да файлов одновременно у разработчика станет больше локально. но процесс - сильно проще. К тому же это позволит вам переиспользовать код гораздо эффективнее.
Если версии сильно завязаны на версии модулей и не билдятся с одними зависимостями - вот тут бы делать другую репу... т.к. это другое приложение.
Возможно в этом случае стоит отделить только какое-то ядро приложения и обьявить контракт, для интеграции с другими компонентами.
Но все это билдится без через гитхаб флоу и тп. все это проще чем Гит Флоу.
Т.е. хранить их код в 1 репе в 1 бранче в разных модулях.
Умрешь одно и то же изменение на обе версии накладывать.
Так ведь наоборот же, выделил общее изменение в одтельный класс и потом переиспользуешь в нужных местах. Куде еще проще?
Изменения бывают не только в классах, которые допускают переиспользование. И вообще в классах. Если все-все-все, включая всевозможные ресурсы, модульное и можно компоновать как угодно - тогда, возможно, и получиться. Но это надо где-то в самом начале такую систему модулей придумать и ее поддерживать. Что не бесплатно по сложности получившегося изделия.
Пример - здоровенный такой файл с локализацией. Можно влить в две ветки v2.* v3.* ветку FIX-1234 с его исправлением (ну опечатка в каком-то переводе была) а можно - придумывать, как его из кусочков собирать под нужную версию ("Эти переводы - для v2, эти - для v3"). Что-то мне кажется, что первое проще.
Так и есть. Так же приходится версионировать переменные окружения, инфраструктуру и т.п. Но не все данные должны находиться в репе. Все это про принципы Чистой Архитектуры и 12 факторных приложений.
Допустим, мы справились с модулями и положили все в репу. В этом случае изменения локализации - это 1 коммит. + у вас есть возможность инструментами вашей среды проверить все места использования ключа перевода. Множества версий можно про разному обслуживать, зависит от вашей фантазии - несколько файлов или пулл переводов из системы локализации во время билда. Все равно 1 коммит и просто проверяется. Переводы тут же оказываются у всех разработчиков, что снижает шанс конфликтов в коде.
В общем, я уверен идею вы поняли, не буду давить. Конечно у вас уже есть какой-то код и процесс и менять его - это не бесплатно. Изменения это всегда больно - отказываться от привычного поведения это больно. Но хотя бы проведите мысленный эксперимент.
Немного расширю аргументацию
Т.е. хранить их код в 1 репе в 1 бранче в разных модулях.
Берем, скажем, документацию. Делать подобное - это означает, что мы где-то вручную (в конфигах, именами, положением в файловой системе) описываем "этот кусок - есть для v2, этот - есть для v3, этот - есть и там и там"
И смысл? Если Version Control для того и придуман, чтобы отслеживать, в какой версии артефакта что есть.
Ошибиться в таком раскладывании по версиям (положить не в тот каталог, вписать не в тот конфиг-файл, поставить в имени не ту версию) - ничуть не сложнее, чем не в той ветке VC разместить.
Это все очень контекстуально и зависит от того как вы собираете документацию, как структурируете код. Уверен можно выделить что-то общее и в модулях оставить только то что относится к ним и собрать нужную версию для релиза.
Обычно разработчик в курсе, какую версию он меняет и может отличить ее от другой в коде. Варианты когда разраб был пьян или потерял очки и не рассмотрел цифру я сразу отметаю как не конструктивные.
Version Controll не про артефакты - он про изменения в коде и обмен им с другими разработчиками.
Артефакты - это результат работы вашего пайплайна. Какой бинарь соберется в итоге из кода, какие зависимости подтянутся, какой пдф отретндерится, Docker image и тп - вот это все вместе - артефакт. И хранятся они в другом месте, не в VCS. Github Releases например - продукт гитхаба, а не гита.
Сам код в большинстве случаев еще не артефакт. Разве что он не имеет зависимостей и тестов. И то с натяжкой, т.к. не каждый файл пользователь использовать может. Если для этого нужен компилятор - это не артефакт.
Допустим, что сложность управления бранчами и навигации по файлам одинаковая. Но как это меняет процесс работы? Имея инструменты навигации по файлам, помощь IDE, возможность использовать CI\CD на полную, автоматизация проверок, т.к. все в 1 месте - перевешивает все остальное.
Я не могу вас убедить словами, вам надо прожить этот опыт самому. Заставить я вас тоже не имею права.
Артефакты - это результат работы вашего пайплайна.
Готовые артефакты - да. А отслеживание что в какой версии есть и из чего конкретная версия состоит - это VC. И там должен быть, разумеется, не только код, а полное описание того, что нужно для воспроизведения артефакта версии abcd.
вам надо прожить этот опыт самому.
У меня, увы, как раз был опыт очень похожего подхода. Еще при использовании SVN. Когда разные варианты поведения одного и того же - лежали в разных ветках файловой системы, хоть и виртуальной. И легко и просто использовалось "вытаскиваем и собираем поведение v2 и v3 прямо тут, рядышком и одновременно". Мне очень не понравилось.
Так что, вероятно, это мое возражение против такого - следствие той травмы.
Стандарты групповой разработки в GitFlow-команде. О чем стоит договориться?