Спасибо за то, что поделился опытом. Неплохо было бы такой же видик с git + hooks ci/cd на примере простого сайта. Безо всяких GitHub и GitLab, но с docker/k8s. Теоретически, конечно, это понятно, но всегда есть что-то новенькое, чему можно научиться.
Михаил спасибо за интересно и полезное видео. Если рассматривать 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 /
А зачем в мастер переходить и забирать последнее, только для того, чтобы иметь последний мастер перед push? Это не обязательно. Я смотрю ты для обновления используешь git pull. Я вообще им не пользуюсь. Даже если тебе нужен последний мастер, зачем переключаться на него. Когда находишься на своей ветке выполняем: git fetch git merge origin/master Ты обновишь сразу же свою ветку с удаленным мастером. Я свой локальный мастер вообще никогда не обновляю. Опять же, эта операция не обязательна. Я всегда создаю pull запрос и только если есть конфликты, тогда обновляю свою ветку последним мастером
Я первый раз работал с 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 да, но я щас подумал и понял в чем преимущество иметь отдельную ветку launch20202121 она даёт возможность притормозить некоторые фичи. В моем случае получается что если фича слита в dev, то притормозить её уже не получится, ведь изменения слиты в dev, а ветка feature123 удалена. Но ещё ни разу такого небыло что от фичи полностью отказались, а за следующий спринт пока фича тестируется в rc, её можно доработать. Если руководство знает заранее что фичу нужно притормозить, то пишет об этом в задаче и изменения просто не сливаются разработчиком в dev
Здорово, надежная схема для работы на первый взгляд, теперь в практику возьму. В кратце упомянули о черри-пике, и др(перемещение хедера, перенос комитов и тд) Нужны ли эти инструменты или того что вы рассказали в этом видео, хватит для полноценной работы?
Спасибо за то, что поделился опытом. Неплохо было бы такой же видик с git + hooks ci/cd на примере простого сайта. Безо всяких GitHub и GitLab, но с docker/k8s. Теоретически, конечно, это понятно, но всегда есть что-то новенькое, чему можно научиться.
Для меня прям дикостью звучит коммитить в мастер :)
Спасибо за урок.
С таким до сих пор приходится сталкиваться.
Сначала лайк, потом посмотрел и не пожалел, что поставил лайк и посмотрел
Спасибо
Отлично! Как раз не знал как отпачковываться.
Спасибо большое за урок, сегодня посмотреть не смогу, но заочно уверен, что урок будет очень интересный :)
Михаил, спасибо большое за труд, за помощь!!!
Деньгами заноси :) маленький доллар лучше большого спасибо. Реквизиты напомнить? 41001412718923 - интернет кошелек Яндекс
Спасибо за отзыв, они и подталкивают меня работать над новыми видео
@@IgorGallemar ты не с Ростова случайно?? :) Всё верно говоришь, благодарить нужно!!! Вызвался, значит кидай реквизиты)
@@user-uu7cg8mp7l нет, из Новосибирска. Z836026281913 - Z кошелек WebMoney
R840783259215 - R кошелек WebMoney
41001412718923 - интернет кошелек Яндекс
Михаил спасибо за интересно и полезное видео.
Если рассматривать 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 /
А зачем в мастер переходить и забирать последнее, только для того, чтобы иметь последний мастер перед push? Это не обязательно.
Я смотрю ты для обновления используешь git pull. Я вообще им не пользуюсь. Даже если тебе нужен последний мастер, зачем переключаться на него. Когда находишься на своей ветке выполняем:
git fetch
git merge origin/master
Ты обновишь сразу же свою ветку с удаленным мастером. Я свой локальный мастер вообще никогда не обновляю. Опять же, эта операция не обязательна. Я всегда создаю pull запрос и только если есть конфликты, тогда обновляю свою ветку последним мастером
Я первый раз работал с 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 да, но я щас подумал и понял в чем преимущество иметь отдельную ветку launch20202121 она даёт возможность притормозить некоторые фичи.
В моем случае получается что если фича слита в dev, то притормозить её уже не получится, ведь изменения слиты в dev, а ветка feature123 удалена.
Но ещё ни разу такого небыло что от фичи полностью отказались, а за следующий спринт пока фича тестируется в rc, её можно доработать.
Если руководство знает заранее что фичу нужно притормозить, то пишет об этом в задаче и изменения просто не сливаются разработчиком в dev
Круто спасибо!
ваш подход похож на git flow
git flow может быть разным. Я описал именно свой, как работал я.
Здорово, надежная схема для работы на первый взгляд, теперь в практику возьму. В кратце упомянули о черри-пике, и др(перемещение хедера, перенос комитов и тд) Нужны ли эти инструменты или того что вы рассказали в этом видео, хватит для полноценной работы?
Нужны и они решают определенные задачи. О черипике, ребейзе планирую рассказать в следующем видео
Первый!!!!
Красава!!! Сегодня обошёл!!!
Поздравления
@@programisli а где лайк?
сложно, о простых вещах...
Странно. Не представляю, куда проще