Продуманная структура, отлично поставленная речь - приятно смотреть и слушать! Сегодня весь день смотрю про git flow и это, пожалуй, лучшее видео по теме. Спасибо за труд!
Вообще ускорение видео позволяет лучше концентрироваться. Когда медленно начинаю отвлекаться. Мне тоже на 1.5 лучше зашло, хотя большинство видео смотрю на х2.
У нас несколько человек делают каждый свою версию, и не всегда порядок релизов может совпадать с порядком вливаний, поэтому нам важно, чтобы ничего лишнего не попало в релиз. Так что, для свой небольшой команды, мы немного поменяли Git Flow и, вместо того, чтобы мерджить фичи в develop, делаем релизную ветку из девелопа, и уже в неё вливаем фичи. Если что-то обновилось в девелопе, то разработчик мерджит в свою релизную ветку. Когда релиз протестирован и выпускается, релиз вливается в девелоп и мастер).
Очень качественно, аккуратно и понятно выполнено пояснение. Даже нет желания искать где-то ещё информацию. Почти все моменты затронуты. Спасибо большое. Я работаю (числюсь как контибьютор) в одной очень маленькой компании, в развитии которой я сам участвовал. Когда посмотрел этот видео ролик, я удивился обнаружив, что мы на самом деле работаем по Git Flow и практически точно так же как на схеме. Но мы к этому пришли не сразу. По Software Configuration Management (касательно именно этой части) у нас вообще изначально не было никакой стратегии. Но постепенно, набив пару шишек, мы сами пришли к такой схеме, которая оказалась наиболее безопасной и управляемой. Но я однажды смотрел одну конференцию, где работник из Microsoft рассказывал как они работают очень короткими итерациями. И рекомендовал делать очень частые слияния с Продом. Для избежания многих конфликтов. Правда я уже не помню его схему.
Спасибо за хороший контент и рассказ! Хорошо бы ещё дополнить примерами про тестирование (фиксы багов на этапе ручного тестирования фич - после окончания имплементации и слияния в Dev, но до попадания в релиз).
бесит когда работая по git flow через vs code делая pull request с ветки с фичой в ветку dev по путно автоматически удаляя ветку с фичой, vs code автоматически перекидывает на ветку main, как сделать чтобы перекидывал на dev?
Не упомянуто одно важное условие: в develop должен попадать только протестированный код. Иначе баги и недоделки будут неизбежно выезжать на прод. Автотестов и кодревью часто бывает недостаточно, например в случае веб-приложений - нужно чтобы прошло ручное QA-тестирование. Возникает вопрос - как организовать такое тестирование? Частая ошибка использования git-flow состоит в том, что тестирование делается на сервере в develop-ветке. А тестировать надо код ДО вмерживания в develop.
В видео довольно хорошо раскрыты достоинства Git Flow (Кстати подход с одной релизной веткой для команды называется github flow и в целом github flow мне намного больше импонирует). Жаль только поверхностно раскрыли жирные минусы Git Flow и почему от него отказываются в больших или кроссфункциональных командах. На мой взгляд, если работать по гибким методологиям, git flow подходит только для небольших команд и при росте команды рекомендовал бы смотреть в сторону TBD, Feature Flag и т.д. и т.п.
Предположим идёт разработка сайта, и там делаем несколько сразу фич, например 1,2 и 3. В релизе нам все фичи не нужны, только 1 и 3. Как нам быть, как в релиз вынести только определённые 1 и 3?
@@PurpleSchool вот собственно вопрос какой, получается мы делаем ветки фичей, вливаем их постепенно в dev, не удаляя. Потом перед релизом те ветки мы сливаем с веткой релиза для теста, но только нужные, верно? Я просто ищу более красивые способы, может вы что подскажете?
Да, это классическая схема git flow. Во многих приличных школах программирования именно такую используют для учебных проектов, ну может без релизов и хотфиксов.
Я единственный кодер в нашей маленькой компании и все равно делаю что-то похожее но попроще. Есть мастер, есть feature/фича-нейм. Всегда в истории можно найти и локализовать проблему если сломалось
Вопрос что делать если на develop ветки тестируются множество фитч, но например какие-то уже хотят зарелизить. Т.е. ситуация когда мы не все что есть на деве хотим отправить в мастер.
Так для этого и есть release ветка, где фиксируются все изменения для релиза и проводится тестирование. А в develop в это время можно можно вливать дальнейшие изменения.
@@sergeblack1777 Антон в других роликах объясняет что такое Feature Flags и как они используются. Если говорить просто: вам нужен механизм включения и отключения фич, чтобы вы могли тестировать и релизить с определённым, заранее известным набором фич. А недостаточно протестированные или недоработанные просто отключать. Кажется что без таких "рубильников" другими способами разрулить ситуацию будет сложно.
@@PurpleSchool то есть 1.0.0, 1.0.1 и т.д. И в ветке main будут такие же тэги после слияния 1.0.1 в main. Получается что релиз дублирует мэйн. Плюс со временем в истории скопится большое число веток с айди релизов. Или это нормально?
В main вливается готовый к релизу проект, а в release ветке он тестируется на staging окружении и туда могут вливаться доработки. А вот main мы уже релизим.
1. Если у нас уже на проще 1.2.0, то скорее всего надо будет делать фикс 1.2.1 2. Если ещё не выкатили, то делается бранч от 1.1.0 из мастера, выделяется в отельную релиз ветку и там ставится тег и выкатывается. Но описанный случай скорее невозможный, потому что если в местере уже есть 1.2.0 значит она уже готова и от неё можно делать фикс.
@@PurpleSchool ну почему невозможный. Может для веба он маловероятный, а вот для прикладного ПО.. Реальный кейс: в версии 1.2 выпиливается некая фича, которая есть в 1.1. Но часть устройств пока остается работать на версии 1.1, и в этой фиче надо поправить баг. По п.2 - значит тег 1.1.1 в мастер просто не попадает и ок? В общем, примерно так и сделали в результате.
А не лучше ли отводить фича-ветки от мастера? Просто какие то фичи могут в конечном счете не попасть в релиз, но они по тем или иным причинам могут быть в девелопе. В таком случае у нас в релиз улетит нежелательный код.
А чем спасёт создание веток от master? Если не хотите в этой итерации релизить фичу, можно не вливать в Develop, или в релизную ветку влить сами ветки фичей, вместо develop.
@@PurpleSchool так как фича в примере в видео отводится от девелоп, который уже может содержать некоторую нежелательную задачу, эта задача сразу и попадет в новую фичу. В целом ветки фич будут не чистыми, а содержать весь девелоп в момент своего создания. Понятно, что можно позаботиться о чистоте девелоп, но все равно проще отводить ветку от мастера, так все фичи будут изолированы друг от друга, разве нет?
“main” is also a more logical name. When I started learning Git I’ve been confused by using “master” for branch name. But after a while, one get used to “master” and becomes a professional habit. Habits are difficult to change, even if the alternative is reasonably better.
Так или иначе, все используют Git Flow, просто не все об этом не догадываются. А как вы вносите изменения в release-ветку? Как-то проскочил этот момент, а ведь он тоже важен.
Не все. Если команда очень маленькая или неопытная в обращении с VCS, обычно используют Feature Branch Workflow как наиболее интуитивно понятную ("копошусь в своей ветке, чтобы никому не мешать").
Привет! Так как я любитель Nest, я считаю что его можно использовать для всего. А под ним если хотите скорости использовать адаптер fastify. Ну а так просто тоже в его сторону можно посмотреть, если нужна скорость.
Пд каждую фичу создается отдельное окружение на кубере, да это ресурсоемко но если у вас команда 50 челов и все делают разное - этот вариант отлично подходит. Единственное что конечно вы в своем окружении поднимаете только измененные микросервисы, и ссылаетесь на другие с какого-то общего неймспейса
От него стартуются все фичи и туда же вливаются. По сути это текущее внутренние состояние проекта из которого можно уже собирать релизы. При этом весь код там прошёл ревью и автоматические тесты.
@@GintsPolis Нельзя. В бранче фичи вы можете протестировать готовность фичи, но не то как система будет работать при взаимодействии разных фич. Пока вы пилили свою фичу, кто-то параллельно пилил другую, третью, десятую. Потом они могут в произвольном порядке вливаться в develop ветку и друг с другом взаимодействовать/конфликтовать. Так что пройдя тесты фичи можно внезапно обнаружить что после вливания в основную ветку у вас вылезают какие-то неожиданные баги.
Западным коллегам даем всю документацию с гитом со словом Master, в чатах так же) не стоит идти за повесткой и переходить на Main, будьте выше этого, на скользкую дорожку переходите) П.С. А ролик хорош и понятен, спасибо за труд.
С хот фиксом не понял, его что, тестировать не надо? А если этот «хот фикс» сломает пол сайта и разработчик это не заметит? Т.е. с хот фиксом вся ответственность на разработчике?
Гит флоу это правильная работа с гитом при условии что это работа в команде или просто если хочется чтоб рабочий процесс всегда находился в порядке, а не в полном хаосе. И работаете вы по скраму, agile или собственной методике на гитфлоу не влияет. Я бы сказал что представленный в этом ролике гит флоу, это хорошие манеры и правильный тон в работе разработчика. И не важно ваш прожект менеджер сторонник покера или эджаил.
Скажу больше, в последнии разы когда я менял место работы, на собеседовании, с моей стороны первым вопросом было как организована работа программиста. И если ответ не соответствовал гит флоу, я шёл на следующее собеседование. Это своего рода маркер здорового коллектива и комфортной работы. Все эти предвыборные лозунги вроде "молодой динамично развивающийся коллектив", "у нас печеньки" скорее всего плохой знак.
Стандартный гитфлоу и затронута лишь идеальная его сторона, а вот сама тема не раскрыта: - как хотфиксы добавлять в мастер и дев? патчем? - как делать откаты версий, когда клиент решил вернуться к релизу 2.3.0 но сохранить часть релиза 2.4.7? - как быть когда команда интернациональная состоит из 5-100 чел, и у каждого своя среда разработки со своими кодформаторами - вносящими изменения в код и тем самым делающим кодревью - бесполезным? - А где стейджинг ветка со стенджинг версией сайта/бэка?
Спасибо за вопросы: - Не нужно патчим. Как только фикс делается он вливается в master и develop как обычный реквест. И мастер после этого релизится с промежуточной версией. - Если нужно собрать промежуточную версию временно. Все нужные фичи и предыдущий релиз вливается в новую ветку и делается релиз. Но это плохая практика. Лучше закрыть ненужные фичи feature флагами. - Сменить лида, который не смог обеспечить одну конфигурацию lint и prettier для всех разработчиков и договориться о стандартах кода. Это первое что нужно сделать внутри команды. - Для теста на stage как раз выкладывается релиз ветка
Ага, использовали. Только вся ежедневная рутинная разработка шла в ветке девелопмента с одним участником. А после завершения работы, когда было тестирование, багфиксы и апдейты по каким-то фичам, тогда только это уже делалось в доп. ветках от девелопмента, после чего делался пул реквест. А потом было код ревью, спросите вы?) Нет, потом я шёл на гитлаб и сам их мёрджил.)) Короче говоря, только голову мне забили, а до ума сами не довели.)
Вроде на бумаге на проекте в идеальном мире с розовыми единорогами оно выглядит хорошо. Но на практике бывают затыки, именно по релизам. Скажем планируется релиз, все фичи согласовали, всё клёво. Подходит время релиза и вдруг прибегает ПР и говорит что заказчиком было принято решение в этот релиз воткнуть несколько фичей, которые планировалось воткнуть в следующий релиз. Заказчика не особо волнует то, что у нас вообще-то аджайл и гитфлоу - ему срочно нужна та фича, просто потому что потому вот нужна, а он тот, кто платит вам денюжки - да и вообще, вы самые умные тут чтоли? Если всего лишь есть одна репа, то в принципе черри пиками можно повыдергивать изменения тех фичей из дев ветки, скрипя зубами пытаясь их воткнуть в изменения релизной ветки, потому что вполне вероятно новые фичи основаны на коммитах из соседних фичей того же следующего релиза - следовательно нас могут ожидать нетривиальные конфликты. А если у нас 100500 реп из-за микросервисов, а реализация фичи с высокой вероятностью распределена между многими микросервисами? Тут хоть вешайся 😁 Туда же относится та ситуация, когда готовится сразу несколько релизов параллельно, то есть в дев вливаются коммиты вперемешку - там вообще черри пик черри пиком погоняет
Ну, не всё, что хочет заказчик реализуемо технически - в том числе из-за техпроцесса. Условно, отдел продаж может продать пентхауз здания за большие деньги и требовать сдать его раньше остальных этажей. Но есть нюанс... )
Я тоже одиночка, сделал ветку indev(там все самые свежие изменения и багфиксы). Main(там уже более стабильные версии, но всё ещё есть баги. Release(там соответственно релизы, где практически не должно быть багов)
В том то и дело,что не один. И фичи разные могут быть в разработке одновременно. В отдельных случаях, да, бывает лучше создать отдельную ветку. Но в большинстве своем, вполне хватает и одной. Для релиза, опять же, лучше иметь отдельную ветку, а не просто тег в Мастере. И не забываем про cherry-pick. Вполне вероятно, ситуации у нас немного :) отличаются, поэтому и подходы немного разные. Я вот, например, до сих пор не знал что такое git flow, зашел поинтересоваться и оказалось, что только названия не знал, но пользовался да еще и в различных вариациях. Вот и в этом видео можно было бы рассказать чуть больше. Но все равно, материал хороший. И подача тоже. :)
@@PurpleSchool ну попробуйте почитать историю гит флоу с 5-ю параллельными ветками, а с 10-ю? Когда у вас одна ветка, можно параллельно вести хоть 100 фич, в конце у вас все равно будет легко читаемая последовательность изменений.
@@СергейШлеёнкин Это говорит о том что вы используете VCS хаотично и "интуитивно", не планируя свои действия и не зная методик. Видимо работаете в очень маленькой компании, либо в компании без нормального лида и с неквалифицированными менеджерами нижнего звена.
@@mootal2202 Уверяю вас, компания уж точно не маленькая. И действую я вполне осознанно и в рамках довольно простых правил. Давайте, может, не будем выяснять уровень квалификации наших специалистов, а вспомним о чем это видео и вернемся к теме разговора. Здесь описан один из вариантов workflow, но он не единственный и не единственно верный.
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.
а в чем круть так все называть? работал в нескольких команадах и практически так везде делали. и считали что это естественный процеес как будто так и должно быть, а не что-то особенное.
@@PurpleSchool да, мне очень повезло окзаться вэтих командах. получается то что воспринимаю как нормально, стало так только благодаря хорошо налаженным процессам и не у всех так? надеюсь после этого видео многие смогут лучше выстроить взаимодействие и будут так же воспринимать видео как описание естественного. тогда они должны быть благодарны автору за то что показывает как лучше делать взаимодействие чтобы уменьшить количество проблем. постараюсь не пропускать Ваши новые видео.
10 лет люди не понимают, что это бред. Из-за каши в деве невозможно протестировать отдельную фичу и поднять в продакшн. А если там серьезная проблема с одной фичей? Всем ждать фикса? Все фичи стартуют только из продакшен! На этапе готовности фичи она вливается в дев и тестируется. В случае ошибки коммиты делаются в ветку самой фичи с последующим мерджем в дев. Фича оттестирована - вливается в QA. После теста ветка фичи мерджится в продакшн. В случаях хотфиксов на продакшене - делается мердж из продакшена в фичу. Процесс повторяется.
@@mootal2202 Вы мой комментарий дальше слова "бред" читали? Если нет - поздравляю. Вы пополнили 90% дебилов, которые пользуются, но не понимают. И гитфлоу в таком виде использовать невозможно. Тем более, в больших проектах.
@@PurpleSchool для любых. Все, что можно с GitFlow, можно и с trunk based. Но у последнего есть преимущества в виде ранней интеграции изменений и минимизации конфликтов. Кроме того GitFlow придумал человек явно не очень знакомый с git, но проникшийся идеей веток, хотя ветка в git - всего лишь указатель на комит, как и тэг. Все эти мерджи после релиза не имеют смысла, более того, мердж - это новый комит с новыми изменениями потенциально содержащими дефект даже в случае отсутствия конфликтов. В конце концов нас интересует история изменений кода, а не процесс. А историю удобнее читать в виде линейной цепочки изменений, без мусора в виде мерджей, без попытки осознать, что было раньше и на какой из двух параллельных комитов откатываться в случае проблемы.
@@PurpleSchool я тоже проникся GitFlow когда он только появился, а я только начинал осваиваться с git. Но позже я понял, что незаконченные комиты в истории - зло и их можно объединять посредством git merge squash или git reset -soft в один с логически завершенным набором изменений, который затем можно перекинуть наверх основной ветки с помощью git rebase. Кроме того с тех пор код ревью и ci/cd стали стандартами индустрии. GitLab или GitHub умеют объединять комиты автоматически. Держать долгоживущие ветки не рекомендовали еще в то время.
Продуманная структура, отлично поставленная речь - приятно смотреть и слушать! Сегодня весь день смотрю про git flow и это, пожалуй, лучшее видео по теме. Спасибо за труд!
Пожалуйста!
Хорошо рассказал
Не доходил до этого видео до термина "гитфлоу", но, как выяснилось, уже используем его в работе :)
Успехов!
Спасибо!
Да, тож оказывается все время юзали)
Аналогично 15 лет используем, а название это услышал впервые года 2 назад
Интересная подача и очень приятно слушать) Обязательно что-то еще посмотрю из твоего канала. Спасибо за видео!)
Пожалуйста!)
Просто отличная подача материала! Спасибо!
Спасибо!
Антон, спасибо! Как всегда чётко и по существу и очень понятно.
Пожалуйста)
Да очень доходчиво все объяснил, спасибо за ценный материал!
Спасибо!
Отлично разжевал. Молодец, респект, отличная работа
Спасибо)
Классная подача материала, я правда ускорил видео на 1.5, но видео стало просто идеальным)
Спасибо 👍
Вообще ускорение видео позволяет лучше концентрироваться. Когда медленно начинаю отвлекаться. Мне тоже на 1.5 лучше зашло, хотя большинство видео смотрю на х2.
Какой шустрик
Спасибо за проделанную работу.
Спасибо!
У нас несколько человек делают каждый свою версию, и не всегда порядок релизов может совпадать с порядком вливаний, поэтому нам важно, чтобы ничего лишнего не попало в релиз.
Так что, для свой небольшой команды, мы немного поменяли Git Flow и, вместо того, чтобы мерджить фичи в develop, делаем релизную ветку из девелопа, и уже в неё вливаем фичи.
Если что-то обновилось в девелопе, то разработчик мерджит в свою релизную ветку. Когда релиз протестирован и выпускается, релиз вливается в девелоп и мастер).
Сразу видно, человек разобрался в теме.
Спасибо за разъяснение! Gitflow используется на новой работе
Супер)
Понятное и полезное объяснение, спасибо
Пожалуйста!
Дико полезное и классное видео. Презентация на высоте. Спасибо!
Спасибо!
@@PurpleSchool вам спасибо, что делитесь информацией и делаете ее доступной! С меня подписка :3
Очень качественно, аккуратно и понятно выполнено пояснение. Даже нет желания искать где-то ещё информацию. Почти все моменты затронуты. Спасибо большое.
Я работаю (числюсь как контибьютор) в одной очень маленькой компании, в развитии которой я сам участвовал. Когда посмотрел этот видео ролик, я удивился обнаружив, что мы на самом деле работаем по Git Flow и практически точно так же как на схеме. Но мы к этому пришли не сразу. По Software Configuration Management (касательно именно этой части) у нас вообще изначально не было никакой стратегии. Но постепенно, набив пару шишек, мы сами пришли к такой схеме, которая оказалась наиболее безопасной и управляемой.
Но я однажды смотрел одну конференцию, где работник из Microsoft рассказывал как они работают очень короткими итерациями. И рекомендовал делать очень частые слияния с Продом. Для избежания многих конфликтов. Правда я уже не помню его схему.
Спасибо! Возможно имелось ввиду использование trunc based: th-cam.com/video/31_IdSFvQrI/w-d-xo.html
Отличный материал, спасибо!
Пожалуйста 👍
Спасибо за хороший контент и рассказ! Хорошо бы ещё дополнить примерами про тестирование (фиксы багов на этапе ручного тестирования фич - после окончания имплементации и слияния в Dev, но до попадания в релиз).
@@LeonidAndrianov 👍
Спасибо тебе большое, Антон Ларичев!!!
Пожалуйста!
Блин, это же просто, продуманно и гениально. Убирает столько путаницы. Буду пробовать)
Обязательно)
Try trunk-based development. It’s the future. Git Flow = merge hell.
Спасибо за хорошо структурированное и доступное объясние. Лайк, подписка👍
Спасибо)
Good job :) watching this from Florida
👍
Уф, как я хорошо попал, все курсы на юдеми закончил , и тут такой подгончик на канале =)
И по микросервисам?)
@@PurpleSchool хм. значит тоже мимо прошел
Спасибо. Клёвый видос 👍. Вот бы еще что-нибудь такое про Doker.
У меня есть целый огромный курс про него) purpleschool.ru/course/docker
Просто и понятно! Спасибо за видео.
Спасибо!
Большое Вам спасибо за то что делитесь знаниями.
Спасибо!
On 7:37 hot-fix merge into develop will produce one more merge commit and will not point to merge commit feature -> dev.
Yes, it will point to current latest develop commit.
Суппер видео!
@@ЮрийСавчук-ч7т 👍
Молодец! Так держать!
👍
Отлично! Я пооонял! =)
Было бы здорово ещё рассказать про версионирование веток.
Спасибо!
семвер посмотри
@@александриванов-ъ7ч5с Ага, спасибки! Оно! Главное знать по каком у слову гуглить!
Дякую за матеріал, доступно та зрозуміло
Спасибо!
Спасибо!
@@sakenjs пожалуйста!
бесит когда работая по git flow через vs code делая pull request с ветки с фичой в ветку dev по путно автоматически удаляя ветку с фичой, vs code автоматически перекидывает на ветку main, как сделать чтобы перекидывал на dev?
TNX bro) Plugin works on after effects.
очень понятно
👍
Не упомянуто одно важное условие: в develop должен попадать только протестированный код. Иначе баги и недоделки будут неизбежно выезжать на прод. Автотестов и кодревью часто бывает недостаточно, например в случае веб-приложений - нужно чтобы прошло ручное QA-тестирование. Возникает вопрос - как организовать такое тестирование? Частая ошибка использования git-flow состоит в том, что тестирование делается на сервере в develop-ветке. А тестировать надо код ДО вмерживания в develop.
В видео довольно хорошо раскрыты достоинства Git Flow (Кстати подход с одной релизной веткой для команды называется github flow и в целом github flow мне намного больше импонирует). Жаль только поверхностно раскрыли жирные минусы Git Flow и почему от него отказываются в больших или кроссфункциональных командах. На мой взгляд, если работать по гибким методологиям, git flow подходит только для небольших команд и при росте команды рекомендовал бы смотреть в сторону TBD, Feature Flag и т.д. и т.п.
Спасибо за дополнение!
TBD works perfectly for teams of all sizes, especially for larger teams. Less merge conflicts, you’re working on the edge of changes.
просьба сделать ролик практической демонстрации!!! спасибо
Ок, подумаю над этим
Все, прям как у нас на текущем проекте! Спасибо за материал.
Спасибо!
спасибо)
@@eugene_mountainland пожалуйста
Предположим идёт разработка сайта, и там делаем несколько сразу фич, например 1,2 и 3. В релизе нам все фичи не нужны, только 1 и 3. Как нам быть, как в релиз вынести только определённые 1 и 3?
Да, если хотите релизить только часть, то после теста можно в релизную ветвь вливать не весь Develop, а точечно нужные фичи.
@@PurpleSchool вот собственно вопрос какой, получается мы делаем ветки фичей, вливаем их постепенно в dev, не удаляя. Потом перед релизом те ветки мы сливаем с веткой релиза для теста, но только нужные, верно?
Я просто ищу более красивые способы, может вы что подскажете?
Да, это классическая схема git flow. Во многих приличных школах программирования именно такую используют для учебных проектов, ну может без релизов и хотфиксов.
Совершенно верно.
Я единственный кодер в нашей маленькой компании и все равно делаю что-то похожее но попроще. Есть мастер, есть feature/фича-нейм. Всегда в истории можно найти и локализовать проблему если сломалось
Для одного разработчика подойдёт.
А можно делать feature ветку от другой feature?
Только если они зависят друг от друга.
А как делается коммит в девелопе, который объединяет сразу две ветки? хотфикс и фича???
Не очень понял вопрос, делается поочерёдно merge двух веток в develop
@@PurpleSchool тогда так и надо было показать )
Вопрос что делать если на develop ветки тестируются множество фитч, но например какие-то уже хотят зарелизить. Т.е. ситуация когда мы не все что есть на деве хотим отправить в мастер.
Так для этого и есть release ветка, где фиксируются все изменения для релиза и проводится тестирование. А в develop в это время можно можно вливать дальнейшие изменения.
@@PurpleSchool в релиз попадёт всё что есть на девелопе. Этого нам не нужно, т.к. там есть задачи которые мы не хотим релизить (по разным причинам)
@@sergeblack1777 Антон в других роликах объясняет что такое Feature Flags и как они используются. Если говорить просто: вам нужен механизм включения и отключения фич, чтобы вы могли тестировать и релизить с определённым, заранее известным набором фич. А недостаточно протестированные или недоработанные просто отключать.
Кажется что без таких "рубильников" другими способами разрулить ситуацию будет сложно.
Увидел, Вас здесь впервые
Потом на Udemy Ваш курс нашел случайно - уже купить легче. Так как подача понравилась, и Вас уже "знаю" =)
Спасибо!)
подскажите, что за известные события, в связи с которыми master стал main?👀
ru.wikipedia.org/wiki/Black_Lives_Matter
1:45 не понял что могло повлиять на названия main-master?
Black lives matters. Поэтому Господин был переименован в Главная)
Только я не понял, ветки release должны иметь номер релиза или всё-таки main? По схеме не совсем понятно
Ветка релиза называется как релиз.
@@PurpleSchool то есть 1.0.0, 1.0.1 и т.д. И в ветке main будут такие же тэги после слияния 1.0.1 в main. Получается что релиз дублирует мэйн. Плюс со временем в истории скопится большое число веток с айди релизов. Или это нормально?
Спасибо
Пожалуйста!
Спасибо) не совсем понял, чем main ветка отличается от release ветки?
В main вливается готовый к релизу проект, а в release ветке он тестируется на staging окружении и туда могут вливаться доработки. А вот main мы уже релизим.
А какие альтернативы есть если GF не подходит ?
Trunk base - тоже есть на канале
@@PurpleSchool уже смотрю +
А как быть если в мастере уже есть версия 1.2.0, а нам нужно внести фикс и сделать версию, например, 1.1.1.
1. Если у нас уже на проще 1.2.0, то скорее всего надо будет делать фикс 1.2.1
2. Если ещё не выкатили, то делается бранч от 1.1.0 из мастера, выделяется в отельную релиз ветку и там ставится тег и выкатывается.
Но описанный случай скорее невозможный, потому что если в местере уже есть 1.2.0 значит она уже готова и от неё можно делать фикс.
@@PurpleSchool ну почему невозможный. Может для веба он маловероятный, а вот для прикладного ПО.. Реальный кейс: в версии 1.2 выпиливается некая фича, которая есть в 1.1. Но часть устройств пока остается работать на версии 1.1, и в этой фиче надо поправить баг. По п.2 - значит тег 1.1.1 в мастер просто не попадает и ок? В общем, примерно так и сделали в результате.
Интересный случай)
А не лучше ли отводить фича-ветки от мастера? Просто какие то фичи могут в конечном счете не попасть в релиз, но они по тем или иным причинам могут быть в девелопе. В таком случае у нас в релиз улетит нежелательный код.
А чем спасёт создание веток от master? Если не хотите в этой итерации релизить фичу, можно не вливать в Develop, или в релизную ветку влить сами ветки фичей, вместо develop.
@@PurpleSchool так как фича в примере в видео отводится от девелоп, который уже может содержать некоторую нежелательную задачу, эта задача сразу и попадет в новую фичу. В целом ветки фич будут не чистыми, а содержать весь девелоп в момент своего создания. Понятно, что можно позаботиться о чистоте девелоп, но все равно проще отводить ветку от мастера, так все фичи будут изолированы друг от друга, разве нет?
Не надо вливать в Develop то, что не нужно к релизу. Или в релизные ветки вливать напрямую из фич
Круто! А какая есть альтернатива?
th-cam.com/video/31_IdSFvQrI/w-d-xo.html
@@PurpleSchool пасип)
Почему нельзя использовать название мастер?
Black lives и так далее… поэтому master переименовали в main
@@PurpleSchool Ничего себе, забавно! :)
“main” is also a more logical name. When I started learning Git I’ve been confused by using “master” for branch name. But after a while, one get used to “master” and becomes a professional habit. Habits are difficult to change, even if the alternative is reasonably better.
Удивительно что сам git ни во что не хотят переименовать. Видимо боятся авторитета создателя )
Вопрос
Добрый день
Вы отвечаете?
Не понял вопроса
@@PurpleSchool
Вы удалили комментарий?
Так или иначе, все используют Git Flow, просто не все об этом не догадываются. А как вы вносите изменения в release-ветку? Как-то проскочил этот момент, а ведь он тоже важен.
Фиксы напрямую в ветку обычно. Можно от неё сделать тоже ветвления, но обычно игнорируют это.
Не все. Если команда очень маленькая или неопытная в обращении с VCS, обычно используют Feature Branch Workflow как наиболее интуитивно понятную ("копошусь в своей ветке, чтобы никому не мешать").
Антон, привет. Подскажите кто сейчас лидер среди минималистичных фреймворков? (экспресс и коа вроде как устаревшие)
Привет! Так как я любитель Nest, я считаю что его можно использовать для всего. А под ним если хотите скорости использовать адаптер fastify. Ну а так просто тоже в его сторону можно посмотреть, если нужна скорость.
А что за события, что лучше главную ветку назвать main, а не master
Black lives matters. После этого переименовали дефолтную ветку
Массовое помешательство на почве целования разноцветных жоп.
Master/slave теперь main/secondary
GitFlow и GitBucket это разные вещи?
Одно методология, а второе это платформа на Scala для хранения git репозиториев
Пд каждую фичу создается отдельное окружение на кубере, да это ресурсоемко но если у вас команда 50 челов и все делают разное - этот вариант отлично подходит. Единственное что конечно вы в своем окружении поднимаете только измененные микросервисы, и ссылаетесь на другие с какого-то общего неймспейса
Вот никак не понимаю, зачем нужен "develop" branch
От него стартуются все фичи и туда же вливаются. По сути это текущее внутренние состояние проекта из которого можно уже собирать релизы. При этом весь код там прошёл ревью и автоматические тесты.
@@PurpleSchool Так чем он отличается от main?
В master вливается готовый у релизу код и там находится только такой.
@@PurpleSchool А когда код готовый? Разве все проверки на готовность нелзя зделать уже в бранче фичи?
@@GintsPolis Нельзя. В бранче фичи вы можете протестировать готовность фичи, но не то как система будет работать при взаимодействии разных фич. Пока вы пилили свою фичу, кто-то параллельно пилил другую, третью, десятую. Потом они могут в произвольном порядке вливаться в develop ветку и друг с другом взаимодействовать/конфликтовать. Так что пройдя тесты фичи можно внезапно обнаружить что после вливания в основную ветку у вас вылезают какие-то неожиданные баги.
05:00 То есть, льём всё говно из develop в release, а затем в main?
Отличный план. Надёжный, как швейцарские часы!
Всегда было интересно узнать, какова целевая аудитория данных роликов?
Это полезно и для разработчиков, и для начинающих девопсов.
Западным коллегам даем всю документацию с гитом со словом Master, в чатах так же) не стоит идти за повесткой и переходить на Main, будьте выше этого, на скользкую дорожку переходите) П.С. А ролик хорош и понятен, спасибо за труд.
Спасибо)
С хот фиксом не понял, его что, тестировать не надо? А если этот «хот фикс» сломает пол сайта и разработчик это не заметит? Т.е. с хот фиксом вся ответственность на разработчике?
Можно влить в develop, протестировать и затем в master
Гит флоу это правильная работа с гитом при условии что это работа в команде или просто если хочется чтоб рабочий процесс всегда находился в порядке, а не в полном хаосе. И работаете вы по скраму, agile или собственной методике на гитфлоу не влияет.
Я бы сказал что представленный в этом ролике гит флоу, это хорошие манеры и правильный тон в работе разработчика. И не важно ваш прожект менеджер сторонник покера или эджаил.
Скажу больше, в последнии разы когда я менял место работы, на собеседовании, с моей стороны первым вопросом было как организована работа программиста. И если ответ не соответствовал гит флоу, я шёл на следующее собеседование. Это своего рода маркер здорового коллектива и комфортной работы. Все эти предвыборные лозунги вроде "молодой динамично развивающийся коллектив", "у нас печеньки" скорее всего плохой знак.
Я поддерживаю, но есть и другие методологии работы с git, которые имеют свои плюсы и минусы.
@@sergiurosca9394а если будет github flow, то уже откажешься?
ждем Git flow vs GitLab flow
Тоже можно рассмотреть)
Стандартный гитфлоу и затронута лишь идеальная его сторона, а вот сама тема не раскрыта:
- как хотфиксы добавлять в мастер и дев? патчем?
- как делать откаты версий, когда клиент решил вернуться к релизу 2.3.0 но сохранить часть релиза 2.4.7?
- как быть когда команда интернациональная состоит из 5-100 чел, и у каждого своя среда разработки со своими кодформаторами - вносящими изменения в код и тем самым делающим кодревью - бесполезным?
- А где стейджинг ветка со стенджинг версией сайта/бэка?
Спасибо за вопросы:
- Не нужно патчим. Как только фикс делается он вливается в master и develop как обычный реквест. И мастер после этого релизится с промежуточной версией.
- Если нужно собрать промежуточную версию временно. Все нужные фичи и предыдущий релиз вливается в новую ветку и делается релиз. Но это плохая практика. Лучше закрыть ненужные фичи feature флагами.
- Сменить лида, который не смог обеспечить одну конфигурацию lint и prettier для всех разработчиков и договориться о стандартах кода. Это первое что нужно сделать внутри команды.
- Для теста на stage как раз выкладывается релиз ветка
Ага, использовали.
Только вся ежедневная рутинная разработка шла в ветке девелопмента с одним участником.
А после завершения работы, когда было тестирование, багфиксы и апдейты по каким-то фичам, тогда только это уже делалось в доп. ветках от девелопмента, после чего делался пул реквест.
А потом было код ревью, спросите вы?)
Нет, потом я шёл на гитлаб и сам их мёрджил.))
Короче говоря, только голову мне забили, а до ума сами не довели.)
Да, не совсем верная система)
Вроде на бумаге на проекте в идеальном мире с розовыми единорогами оно выглядит хорошо. Но на практике бывают затыки, именно по релизам. Скажем планируется релиз, все фичи согласовали, всё клёво. Подходит время релиза и вдруг прибегает ПР и говорит что заказчиком было принято решение в этот релиз воткнуть несколько фичей, которые планировалось воткнуть в следующий релиз. Заказчика не особо волнует то, что у нас вообще-то аджайл и гитфлоу - ему срочно нужна та фича, просто потому что потому вот нужна, а он тот, кто платит вам денюжки - да и вообще, вы самые умные тут чтоли? Если всего лишь есть одна репа, то в принципе черри пиками можно повыдергивать изменения тех фичей из дев ветки, скрипя зубами пытаясь их воткнуть в изменения релизной ветки, потому что вполне вероятно новые фичи основаны на коммитах из соседних фичей того же следующего релиза - следовательно нас могут ожидать нетривиальные конфликты. А если у нас 100500 реп из-за микросервисов, а реализация фичи с высокой вероятностью распределена между многими микросервисами? Тут хоть вешайся 😁
Туда же относится та ситуация, когда готовится сразу несколько релизов параллельно, то есть в дев вливаются коммиты вперемешку - там вообще черри пик черри пиком погоняет
Ну, не всё, что хочет заказчик реализуемо технически - в том числе из-за техпроцесса.
Условно, отдел продаж может продать пентхауз здания за большие деньги и требовать сдать его раньше остальных этажей. Но есть нюанс... )
Любопытно, но для одиночки это выглядит лютой дичью, конечно. :)
Да, только для командной работы.
Я тоже одиночка, сделал ветку indev(там все самые свежие изменения и багфиксы). Main(там уже более стабильные версии, но всё ещё есть баги. Release(там соответственно релизы, где практически не должно быть багов)
А если нужен контроль версий для одиночки? Я лучше буду использовать. Да и к тому же обучает Гиту, а это пригодится при работе в команде.
С переименованием master в main конечно ржака получилась. Надеюсь Master of Puppets не переименуют в Main of Puppets
😂
Ветки Release, Hotfix можно убрать. Оставить dev и prod. Так проще работать
Master, он же Dev, он же -- все остальное. Для релизов -- отдельный бранч. Все!
Когда ты пишешь код один - да)
В том то и дело,что не один. И фичи разные могут быть в разработке одновременно. В отдельных случаях, да, бывает лучше создать отдельную ветку. Но в большинстве своем, вполне хватает и одной. Для релиза, опять же, лучше иметь отдельную ветку, а не просто тег в Мастере. И не забываем про cherry-pick. Вполне вероятно, ситуации у нас немного :) отличаются, поэтому и подходы немного разные. Я вот, например, до сих пор не знал что такое git flow, зашел поинтересоваться и оказалось, что только названия не знал, но пользовался да еще и в различных вариациях. Вот и в этом видео можно было бы рассказать чуть больше. Но все равно, материал хороший. И подача тоже. :)
@@PurpleSchool ну попробуйте почитать историю гит флоу с 5-ю параллельными ветками, а с 10-ю? Когда у вас одна ветка, можно параллельно вести хоть 100 фич, в конце у вас все равно будет легко читаемая последовательность изменений.
@@СергейШлеёнкин Это говорит о том что вы используете VCS хаотично и "интуитивно", не планируя свои действия и не зная методик. Видимо работаете в очень маленькой компании, либо в компании без нормального лида и с неквалифицированными менеджерами нижнего звена.
@@mootal2202 Уверяю вас, компания уж точно не маленькая. И действую я вполне осознанно и в рамках довольно простых правил. Давайте, может, не будем выяснять уровень квалификации наших специалистов, а вспомним о чем это видео и вернемся к теме разговора. Здесь описан один из вариантов workflow, но он не единственный и не единственно верный.
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.
а в чем круть так все называть? работал в нескольких команадах и практически так везде делали. и считали что это естественный процеес как будто так и должно быть, а не что-то особенное.
У тебя значит были хорошие команды, а повсеместно это далеко не так.
@@PurpleSchool да, мне очень повезло окзаться вэтих командах. получается то что воспринимаю как нормально, стало так только благодаря хорошо налаженным процессам и не у всех так? надеюсь после этого видео многие смогут лучше выстроить взаимодействие и будут так же воспринимать видео как описание естественного. тогда они должны быть благодарны автору за то что показывает как лучше делать взаимодействие чтобы уменьшить количество проблем. постараюсь не пропускать Ваши новые видео.
10 лет люди не понимают, что это бред.
Из-за каши в деве невозможно протестировать отдельную фичу и поднять в продакшн.
А если там серьезная проблема с одной фичей? Всем ждать фикса?
Все фичи стартуют только из продакшен!
На этапе готовности фичи она вливается в дев и тестируется.
В случае ошибки коммиты делаются в ветку самой фичи с последующим мерджем в дев.
Фича оттестирована - вливается в QA.
После теста ветка фичи мерджится в продакшн.
В случаях хотфиксов на продакшене - делается мердж из продакшена в фичу.
Процесс повторяется.
Это не бред. GitFlow очень активно используется в больших серьёзных организациях. Он понятен, отработан и надёжен.
@@mootal2202 Вы мой комментарий дальше слова "бред" читали?
Если нет - поздравляю. Вы пополнили 90% дебилов, которые пользуются, но не понимают.
И гитфлоу в таком виде использовать невозможно. Тем более, в больших проектах.
ничего не понял, пришел после видео азазина
Trunk based development is better. No need for long living branches.
TL;DR: never-ever use gitflow
Git Flow == merge hell. No thanks.
Жаль но нечего не понял
Лучше возвращайтесь к зип-архивам с версиями проекта, а эту гейскую требуху выкиньте и забудьте. Потом скажете мне спасибо!
Какой ужасный совет…
..Ах да, поменьше англицизмов пжл. Что такое "юайный" и "сиайный" ? Это два друга-клоуна?)
Забыть, как страшный сон! Trunk-based гораздо проще: одна ветка для всего + релизные ветки.
Смотря для какие целей
@@PurpleSchool для любых. Все, что можно с GitFlow, можно и с trunk based. Но у последнего есть преимущества в виде ранней интеграции изменений и минимизации конфликтов. Кроме того GitFlow придумал человек явно не очень знакомый с git, но проникшийся идеей веток, хотя ветка в git - всего лишь указатель на комит, как и тэг. Все эти мерджи после релиза не имеют смысла, более того, мердж - это новый комит с новыми изменениями потенциально содержащими дефект даже в случае отсутствия конфликтов.
В конце концов нас интересует история изменений кода, а не процесс. А историю удобнее читать в виде линейной цепочки изменений, без мусора в виде мерджей, без попытки осознать, что было раньше и на какой из двух параллельных комитов откатываться в случае проблемы.
@@PurpleSchool я тоже проникся GitFlow когда он только появился, а я только начинал осваиваться с git. Но позже я понял, что незаконченные комиты в истории - зло и их можно объединять посредством git merge squash или git reset -soft в один с логически завершенным набором изменений, который затем можно перекинуть наверх основной ветки с помощью git rebase. Кроме того с тех пор код ревью и ci/cd стали стандартами индустрии. GitLab или GitHub умеют объединять комиты автоматически. Держать долгоживущие ветки не рекомендовали еще в то время.
Спасибо за проделанную работу.
Спасибо!