Комментарии 9
Спасибо за статью! В следующей можно написать про решение конфликтов при одновременной разработке, про git rebase, про откаты проекта к состоянию какого то комита и прочие продвинуты штуки.
Успехов!
Переехали в компании с GitFlow на GitHub Flow https://habr.com/ru/articles/346066/ .
Стало намного легче контролировать git
Стало намного легче контролировать git
Минус ветка develop, а это означает что master всегда актуализирован и стабилен
Rebase по актуальному master всегда
Выпускаем тег приложение через Release tag по ветке master в один клик в GitLab
GitHub Flow показал лучше себя с течением времени на практике на большом проекте. Думаю стоит упомянуть в статье, чтобы разработчик смог сравнить и выбрать для себя подходящий flow
Спасибо за разбор gitflow. Интересно, как его применять, если команда поддерживает старый релиз на проде, несколько ещё более старых релизов, которые стоят у заказчиков, текущий релиз, который ещё в разработке и будущий релиз, который уже начали пилить, чтобы разработчики не простаивали? Сколько веток Develop делать ?)
Отдельные релизные ветки, в статье не единственный и не самый полный вариант. Фичи сначала сливаются в develop, потом в релизную ветку и уже релизная ветка идет в main
Мы впрочем релизные ветки и без необходимости постоянно поддерживать много разных релизов используем, кода задач в релиз много идет и от разных раработчиков проще их сначала в релизной ветке собрать, ну и одновременно в разработке несколько релизов может быть. У нас, впрочем, еще отдельная ветка для препрода.
Это далеко не первая статья про gitflow и не самая подробная - вот на хабре было, а вот первоисточник на английском.
Все кто Githubflow говорят - молодцы. Но никто не говорит про trunk based development. В нем все ещё проще и он даёт ещё больше бенефитов чем гитхаб флоу.
Насчет проще - вопрос открытый. Сам не пробовал, но многие пишут (например амазон) про то, что у этой модели гораздо более высокие требования к разработчикам, системе развертывания, тестерам и управлению командой. Мне временами кажется, что ситуация схожа с микросервисами - кажется очень просто, на самом деле целая пачка скрытых проблем и очень высокие требования к разработчикам, в топовых компаниях вроде Google оно хорошо работает, а вот в типичных может только добавить проблем.
Пожалуйста, используйте картинки от реальных людей, иначе не хочется читать статью уже из-за того, что не вставляют картинки и фото от реальных людей. Не в осуждение, это, просто борьба за творчество
Git, Gitflow и ветка develop. Продолжаем разбираться в основах программирования