Что такое Git flow и когда использовать? 

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

Хорошо рассказал Не доходил до этого видео до термина "гитфлоу", но, как выяснилось, уже используем его в работе :) Успехов!

Просто отличная подача материала! Спасибо!

Интересная подача и очень приятно слушать) Обязательно что-то еще посмотрю из твоего канала. Спасибо за видео!)

Антон, спасибо! Как всегда чётко и по существу и очень понятно.

Спасибо за проделанную работу.

Большое Вам спасибо за то что делитесь знаниями.

Дико полезное и классное видео. Презентация на высоте. Спасибо!

Да очень доходчиво все объяснил, спасибо за ценный материал!

Понятное и полезное объяснение, спасибо

Отлично разжевал. Молодец, респект, отличная работа

Отличный материал, спасибо!

Спасибо за хорошо структурированное и доступное объясние. Лайк, подписка👍

Классная подача материала, я правда ускорил видео на 1.5, но видео стало просто идеальным)

Спасибо. Клёвый видос 👍. Вот бы еще что-нибудь такое про Doker.

У нас несколько человек делают каждый свою версию, и не всегда порядок релизов может совпадать с порядком вливаний, поэтому нам важно, чтобы ничего лишнего не попало в релиз. Так что, для свой небольшой команды, мы немного поменяли Git Flow и, вместо того, чтобы мерджить фичи в develop, делаем релизную ветку из девелопа, и уже в неё вливаем фичи. Если что-то обновилось в девелопе, то разработчик мерджит в свою релизную ветку. Когда релиз протестирован и выпускается, релиз вливается в девелоп и мастер).

Просто и понятно! Спасибо за видео.

Спасибо тебе большое, Антон Ларичев!!!

Спасибо за разъяснение! Gitflow используется на новой работе

Очень качественно, аккуратно и понятно выполнено пояснение. Даже нет желания искать где-то ещё информацию. Почти все моменты затронуты. Спасибо большое. Я работаю (числюсь как контибьютор) в одной очень маленькой компании, в развитии которой я сам участвовал. Когда посмотрел этот видео ролик, я удивился обнаружив, что мы на самом деле работаем по Git Flow и практически точно так же как на схеме. Но мы к этому пришли не сразу. По Software Configuration Management (касательно именно этой части) у нас вообще изначально не было никакой стратегии. Но постепенно, набив пару шишек, мы сами пришли к такой схеме, которая оказалась наиболее безопасной и управляемой. Но я однажды смотрел одну конференцию, где работник из Microsoft рассказывал как они работают очень короткими итерациями. И рекомендовал делать очень частые слияния с Продом. Для избежания многих конфликтов. Правда я уже не помню его схему.

Молодец! Так держать!

Блин, это же просто, продуманно и гениально. Убирает столько путаницы. Буду пробовать)

Отлично! Я пооонял! =) Было бы здорово ещё рассказать про версионирование веток.

Уф, как я хорошо попал, все курсы на юдеми закончил , и тут такой подгончик на канале =)

Дякую за матеріал, доступно та зрозуміло

очень понятно

Все, прям как у нас на текущем проекте! Спасибо за материал.

TNX bro) Plugin works on after effects.

В видео довольно хорошо раскрыты достоинства Git Flow (Кстати подход с одной релизной веткой для команды называется github flow и в целом github flow мне намного больше импонирует). Жаль только поверхностно раскрыли жирные минусы Git Flow и почему от него отказываются в больших или кроссфункциональных командах. На мой взгляд, если работать по гибким методологиям, git flow подходит только для небольших команд и при росте команды рекомендовал бы смотреть в сторону TBD, Feature Flag и т.д. и т.п.

Я единственный кодер в нашей маленькой компании и все равно делаю что-то похожее но попроще. Есть мастер, есть feature/фича-нейм. Всегда в истории можно найти и локализовать проблему если сломалось

просьба сделать ролик практической демонстрации!!! спасибо

Спасибо) не совсем понял, чем main ветка отличается от release ветки?

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

Спасибо

Антон, привет. Подскажите кто сейчас лидер среди минималистичных фреймворков? (экспресс и коа вроде как устаревшие)

Не упомянуто одно важное условие: в develop должен попадать только протестированный код. Иначе баги и недоделки будут неизбежно выезжать на прод. Автотестов и кодревью часто бывает недостаточно, например в случае веб-приложений - нужно чтобы прошло ручное QA-тестирование. Возникает вопрос - как организовать такое тестирование? Частая ошибка использования git-flow состоит в том, что тестирование делается на сервере в develop-ветке. А тестировать надо код ДО вмерживания в develop.

А можно делать feature ветку от другой feature?

подскажите, что за известные события, в связи с которыми master стал main?👀

Всегда было интересно узнать, какова целевая аудитория данных роликов?

Вопрос что делать если на develop ветки тестируются множество фитч, но например какие-то уже хотят зарелизить. Т.е. ситуация когда мы не все что есть на деве хотим отправить в мастер.

On 7:37 hot-fix merge into develop will produce one more merge commit and will not point to merge commit feature -> dev.

1:45 не понял что могло повлиять на названия main-master?

Увидел, Вас здесь впервые Потом на Udemy Ваш курс нашел случайно - уже купить легче. Так как подача понравилась, и Вас уже "знаю" =)

Предположим идёт разработка сайта, и там делаем несколько сразу фич, например 1,2 и 3. В релизе нам все фичи не нужны, только 1 и 3. Как нам быть, как в релиз вынести только определённые 1 и 3?

Только я не понял, ветки release должны иметь номер релиза или всё-таки main? По схеме не совсем понятно

А как делается коммит в девелопе, который объединяет сразу две ветки? хотфикс и фича???

Круто! А какая есть альтернатива?

А как быть если в мастере уже есть версия 1.2.0, а нам нужно внести фикс и сделать версию, например, 1.1.1.

Так или иначе, все используют Git Flow, просто не все об этом не догадываются. А как вы вносите изменения в release-ветку? Как-то проскочил этот момент, а ведь он тоже важен.

Вопрос Добрый день Вы отвечаете?

ждем Git flow vs GitLab flow

А какие альтернативы есть если GF не подходит ?

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

GitFlow и GitBucket это разные вещи?

А что за события, что лучше главную ветку назвать main, а не master

Западным коллегам даем всю документацию с гитом со словом Master, в чатах так же) не стоит идти за повесткой и переходить на Main, будьте выше этого, на скользкую дорожку переходите) П.С. А ролик хорош и понятен, спасибо за труд.

Почему нельзя использовать название мастер?

Стандартный гитфлоу и затронута лишь идеальная его сторона, а вот сама тема не раскрыта: - как хотфиксы добавлять в мастер и дев? патчем? - как делать откаты версий, когда клиент решил вернуться к релизу 2.3.0 но сохранить часть релиза 2.4.7? - как быть когда команда интернациональная состоит из 5-100 чел, и у каждого своя среда разработки со своими кодформаторами - вносящими изменения в код и тем самым делающим кодревью - бесполезным? - А где стейджинг ветка со стенджинг версией сайта/бэка?

Вот никак не понимаю, зачем нужен "develop" branch

Ага, использовали. Только вся ежедневная рутинная разработка шла в ветке девелопмента с одним участником. А после завершения работы, когда было тестирование, багфиксы и апдейты по каким-то фичам, тогда только это уже делалось в доп. ветках от девелопмента, после чего делался пул реквест. А потом было код ревью, спросите вы?) Нет, потом я шёл на гитлаб и сам их мёрджил.)) Короче говоря, только голову мне забили, а до ума сами не довели.)

Вроде на бумаге на проекте в идеальном мире с розовыми единорогами оно выглядит хорошо. Но на практике бывают затыки, именно по релизам. Скажем планируется релиз, все фичи согласовали, всё клёво. Подходит время релиза и вдруг прибегает ПР и говорит что заказчиком было принято решение в этот релиз воткнуть несколько фичей, которые планировалось воткнуть в следующий релиз. Заказчика не особо волнует то, что у нас вообще-то аджайл и гитфлоу - ему срочно нужна та фича, просто потому что потому вот нужна, а он тот, кто платит вам денюжки - да и вообще, вы самые умные тут чтоли? Если всего лишь есть одна репа, то в принципе черри пиками можно повыдергивать изменения тех фичей из дев ветки, скрипя зубами пытаясь их воткнуть в изменения релизной ветки, потому что вполне вероятно новые фичи основаны на коммитах из соседних фичей того же следующего релиза - следовательно нас могут ожидать нетривиальные конфликты. А если у нас 100500 реп из-за микросервисов, а реализация фичи с высокой вероятностью распределена между многими микросервисами? Тут хоть вешайся 😁 Туда же относится та ситуация, когда готовится сразу несколько релизов параллельно, то есть в дев вливаются коммиты вперемешку - там вообще черри пик черри пиком погоняет

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

С переименованием master в main конечно ржака получилась. Надеюсь Master of Puppets не переименуют в Main of Puppets

Любопытно, но для одиночки это выглядит лютой дичью, конечно. :)

С хот фиксом не понял, его что, тестировать не надо? А если этот «хот фикс» сломает пол сайта и разработчик это не заметит? Т.е. с хот фиксом вся ответственность на разработчике?

You’re allowed and encouraged to commit and push to master branch if you have CI and CD automation with excessive auto tests coverage. Git Flow looses popularity in favor of Trunk based development.

Master, он же Dev, он же -- все остальное. Для релизов -- отдельный бранч. Все!

Ветки Release, Hotfix можно убрать. Оставить dev и prod. Так проще работать

Trunk based development is better. No need for long living branches.

ничего не понял, пришел после видео азазина

а в чем круть так все называть? работал в нескольких команадах и практически так везде делали. и считали что это естественный процеес как будто так и должно быть, а не что-то особенное.

TL;DR: never-ever use gitflow

10 лет люди не понимают, что это бред. Из-за каши в деве невозможно протестировать отдельную фичу и поднять в продакшн. А если там серьезная проблема с одной фичей? Всем ждать фикса? Все фичи стартуют только из продакшен! На этапе готовности фичи она вливается в дев и тестируется. В случае ошибки коммиты делаются в ветку самой фичи с последующим мерджем в дев. Фича оттестирована - вливается в QA. После теста ветка фичи мерджится в продакшн. В случаях хотфиксов на продакшене - делается мердж из продакшена в фичу. Процесс повторяется.

Git Flow == merge hell. No thanks.

Жаль но нечего не понял

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

..Ах да, поменьше англицизмов пжл. Что такое "юайный" и "сиайный" ? Это два друга-клоуна?)

Забыть, как страшный сон! Trunk-based гораздо проще: одна ветка для всего + релизные ветки.

Спасибо за проделанную работу.

А не лучше ли отводить фича-ветки от мастера? Просто какие то фичи могут в конечном счете не попасть в релиз, но они по тем или иным причинам могут быть в девелопе. В таком случае у нас в релиз улетит нежелательный код.