Управление кодом в GIT - от фикса до запуска

[@i.am.rossalex]

Спасибо за то, что поделился опытом. Неплохо было бы такой же видик с git + hooks ci/cd на примере простого сайта. Безо всяких GitHub и GitLab, но с docker/k8s. Теоретически, конечно, это понятно, но всегда есть что-то новенькое, чему можно научиться.

[@Asiro-S]

Для меня прям дикостью звучит коммитить в мастер :) Спасибо за урок.

[@mflenov]

С таким до сих пор приходится сталкиваться.

[@rubyalban]

Отлично! Как раз не знал как отпачковываться.

[@ДенисК-р6я]

Сначала лайк, потом посмотрел и не пожалел, что поставил лайк и посмотрел

[@Dev-lessons]

Спасибо

[@Asiro-S]

Спасибо большое за урок, сегодня посмотреть не смогу, но заочно уверен, что урок будет очень интересный :)

[@ДанилаБагров-ъ1ы]

Михаил, спасибо большое за труд, за помощь!!!

[@IgorGallemar]

Деньгами заноси :) маленький доллар лучше большого спасибо. Реквизиты напомнить? 41001412718923 - интернет кошелек Яндекс

[@Dev-lessons]

Спасибо за отзыв, они и подталкивают меня работать над новыми видео

[@ДанилаБагров-ъ1ы]

@@IgorGallemar ты не с Ростова случайно?? :) Всё верно говоришь, благодарить нужно!!! Вызвался, значит кидай реквизиты)

[@IgorGallemar]

@@ДанилаБагров-ъ1ы нет, из Новосибирска. Z836026281913 - Z кошелек WebMoney R840783259215 - R кошелек WebMoney 41001412718923 - интернет кошелек Яндекс

[@ВикторГавриленко-б3м]

Круто спасибо!

[@emistar3780]

Михаил спасибо за интересно и полезное видео. Если рассматривать Pull request и GitHub, что скажите про данный путь? На GitHub создан репозиторий. На локальном хосте: git clone ... Далее, создаем бранч от локального мастера: git checkout -b / Производим все изменения в бранче, коммит ту же. Перед тем как сделать push, переходим в master: git switch master Смотрим, есть что то новое: git fetch И заливаем свежие/новые данные: git pull Переходим обратно в бранч git switch / Делаем merge с мастером: git merge master И теперь push: git push origin / Создаем Pull request После успешного прохождения Pull request и мерджа, на локальном хосте переходим в мастер: git switch master и заливаем данные git pull После удаляем бранч на хосте и на origin: git branch -d / git push origin --delete /

[@Dev-lessons]

А зачем в мастер переходить и забирать последнее, только для того, чтобы иметь последний мастер перед push? Это не обязательно. Я смотрю ты для обновления используешь git pull. Я вообще им не пользуюсь. Даже если тебе нужен последний мастер, зачем переключаться на него. Когда находишься на своей ветке выполняем: git fetch git merge origin/master Ты обновишь сразу же свою ветку с удаленным мастером. Я свой локальный мастер вообще никогда не обновляю. Опять же, эта операция не обязательна. Я всегда создаю pull запрос и только если есть конфликты, тогда обновляю свою ветку последним мастером

[@Hello_there_777]

Я первый раз работал с tfs также с одной веткой и это плохо. Сейчас в команде работаю с git следующим образом. Начало спринта 1 число, для каждой фичи откалывается ветка от dev, например feature123, в ней делаются изменения, далее qa раскатывает все сервисы из dev, а те в которых были изменения раскатывает из feature123 и тестирует. Когда все ок, qa пишет что изменения можно сливать. Изменения сливаются в ветку dev. Прошла неделя наступило 8 число время делать релиз. Изменения с позапрошлого спринта из ветки RC сливаются в мастер, далее изменения сделанные на прошлом спринте с 1 по 5 число из dev сливаются в RC. Далее RC тестируется бизнесом и кем угодно. На dev кстати каждую ночь запускаются автотесты. Ну как бы все релиз готов. Получается что первую неделю пишем фичи, вторую неделю они тестируются , а на начале третьей недели они уже в релизе и работают в продакшене. Я не делаю релизы могу ошибаться, но вроде всё так. Если нужен хот фикс для мастера, то создаётся ветка hotfix123 он тестируется qa на тестовом стенде и сливается во все 3 ветки dev rc master.

[@Dev-lessons]

Очень даже неплохо.

[@Hello_there_777]

@@Dev-lessons да, но я щас подумал и понял в чем преимущество иметь отдельную ветку launch20202121 она даёт возможность притормозить некоторые фичи. В моем случае получается что если фича слита в dev, то притормозить её уже не получится, ведь изменения слиты в dev, а ветка feature123 удалена. Но ещё ни разу такого небыло что от фичи полностью отказались, а за следующий спринт пока фича тестируется в rc, её можно доработать. Если руководство знает заранее что фичу нужно притормозить, то пишет об этом в задаче и изменения просто не сливаются разработчиком в dev

[@evgenasd8892]

Здорово, надежная схема для работы на первый взгляд, теперь в практику возьму. В кратце упомянули о черри-пике, и др(перемещение хедера, перенос комитов и тд) Нужны ли эти инструменты или того что вы рассказали в этом видео, хватит для полноценной работы?

[@Dev-lessons]

Нужны и они решают определенные задачи. О черипике, ребейзе планирую рассказать в следующем видео

[@borisoffdenis]

ваш подход похож на git flow

[@Dev-lessons]

git flow может быть разным. Я описал именно свой, как работал я.

[@IgorGallemar]

Первый!!!!

[@ДанилаБагров-ъ1ы]

Красава!!! Сегодня обошёл!!!

[@programisli]

Поздравления

[@IgorGallemar]

@@programisli а где лайк?

[@cmapukumope2995]

сложно, о простых вещах...

[@Dev-lessons]

Странно. Не представляю, куда проще