8:33 делал всё в такой же последовательности - ошибка: fatal: 'origin' does not appear to be a git repository fatal: Could not read from remote repository. я подумал, ладно давай через GitHub Desktop создам репо на удалёнке и попробую снова - добавляю другой файл делаю git add filename - git push origin feature/myfeature - та же ошибка. Да и вообще странно, что без коммита мы делаем пуш и он у вас получился ! Явно не хватает объяснений.
Выпустили версию 3.1 - она продовая Мы дальше разрабатываем, в мастре теперь есть теги типо vRC4.1 Щаказчики говорят, что в 3.1 есть баг Как вернуться к 3.1 и сделать багфикс конкретно для жтой версии? Релиз-кондидат уже содержит багфикс, но при жтом он поломал некоторые вещи из 3.1, так что заказчик… ну он из этой ветки точно не должен ничего получать
Нужно разбираться более глубоко в вашем процессе разработки и хотелках заказчика, что немаловажно, НО исходя из описанного как я понимаю ответ на данный вопрос: - Надо исправить проблему в версии на проде - создаем hotfix бранчу от релиз бранчи 3.1, вносим необходимые исправления, тестируем, мержаем обратно в master/release и деплоим изменения на prod. Получаем решение для конкретной версии. - Если потенциально в процессе разработки могут создаваться features которые могут ломать функциональность, то может быть решение разрабатывать каждую функциональность в отдельной ветке и мерджать в общую кучу только после утверждения заказчиком, либо использовать подход с отдельным сервисом "feature toggle" en.wikipedia.org/wiki/Feature_toggle которые будет определять какую функциональность активировать, а с какой подождать некоторое время и не активировать.
На больших проектах может накапливаться до тысячи и более веток за месяц - это банально неразбериха в ветках, лишние деньги на ресурсы, деградация производительности и тп Хорошей практикой считается удаление ветки после merge в master, если в ней больше нет необходимости
Надо было показывать на обычном гит, чтобы было понимание, как под капотом работает
Спасибо
8:33 делал всё в такой же последовательности - ошибка:
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
я подумал, ладно давай через GitHub Desktop создам репо на удалёнке и попробую снова -
добавляю другой файл делаю git add filename - git push origin feature/myfeature - та же ошибка.
Да и вообще странно, что без коммита мы делаем пуш и он у вас получился !
Явно не хватает объяснений.
там почему-то удаленный репозиторий называется origit а не origin. Проверьте git remote -v
thx
Выпустили версию 3.1 - она продовая
Мы дальше разрабатываем, в мастре теперь есть теги типо vRC4.1
Щаказчики говорят, что в 3.1 есть баг
Как вернуться к 3.1 и сделать багфикс конкретно для жтой версии?
Релиз-кондидат уже содержит багфикс, но при жтом он поломал некоторые вещи из 3.1, так что заказчик… ну он из этой ветки точно не должен ничего получать
Нужно разбираться более глубоко в вашем процессе разработки и хотелках заказчика, что немаловажно, НО исходя из описанного как я понимаю ответ на данный вопрос:
- Надо исправить проблему в версии на проде - создаем hotfix бранчу от релиз бранчи 3.1, вносим необходимые исправления, тестируем, мержаем обратно в master/release и деплоим изменения на prod. Получаем решение для конкретной версии.
- Если потенциально в процессе разработки могут создаваться features которые могут ломать функциональность, то может быть решение разрабатывать каждую функциональность в отдельной ветке и мерджать в общую кучу только после утверждения заказчиком, либо использовать подход с отдельным сервисом "feature toggle" en.wikipedia.org/wiki/Feature_toggle которые будет определять какую функциональность активировать, а с какой подождать некоторое время и не активировать.
Скажіть будь ласка, припустим якщо фіча була змерджена в девелоп, але знайшовся баг, то потрібно буде чикати до релізу і тоді у хотфіксі робити?
Не обязательно - можно отколоться от dev. исправить и снова merge в dev
Зачем ветки удалять ?
На больших проектах может накапливаться до тысячи и более веток за месяц - это банально неразбериха в ветках, лишние деньги на ресурсы, деградация производительности и тп Хорошей практикой считается удаление ветки после merge в master, если в ней больше нет необходимости
после мёржа ветки уже не нужны. Вся необходимая информация по изменениям содержится в коммитах.