Спасибо за комментарий! Действительно часть советов и рекомендаций ошибочно попала в блок тезисов конвенции Conventional Commits. Внес корректировки. Благодарю за внимательное прочтение статьи. Ни в коем случае не хотел ввести кого-то в заблуждение. Сам люблю порядок и ценю точность формулировок.
1. Change Log не ведем, есть Release Notes. Перед каждым Pull Request-ом разработчик заполняет в файле ReleaseNotes.md следующие пункты:
— New (Что нового? (фичи, новая функциональность));
— Improvements (Какие улучшения мы добавили в существующие фичи);
— Fixes (Список исправленных багов);
— Operations (Eslint, обновление библиотек и т.д.).
На основе этого файла формируются Release Notes каждой версии. Этот документ смотрят QA специалисты. После публикации версии содержимое файла ReleaseNotes.md обнуляется.
2. Выбрали классический git-flow (хотя сам я сторонник другого ветвления). Это правильно по многим причинам, но для меня главная — открытость к ротациям в команде. Отраслевые стандарты позволяют свести начальный инструктаж к минимуму.
3. Не задумывался линейна или не линейная история. Использую в работе удобный GitKraken, всё наглядно. За ссылки благодарю, изучу внимательно этот вопрос.
Спасибо за комментарий. Скриншот в начале статьи немного приукрашивает действительность, но спешка и отсутствие договоренностей действительно приводят к подобному результату. Правила и автоматизация помогают избегать подобного.
К сожалению уже не смешно. Неприятно удивил тот факт, что в нескольких последних подборках авторов этого дайджеста Vue.js был выше чем остальные фрейморвки (что видимо означает большую важность Vue.js прямо сейчас?). В такие моменты начинаешь чувствовать себя не совсем уютно с «устаревшими» технологиями :)
В таком случае +1 к тем, кто заинтересованных в ваших обзорах. Здорово что у вас не просто «хит парад» этой недели, но и обоснование места, с подробным описанием плюсов и минусов.
1. Change Log не ведем, есть Release Notes. Перед каждым Pull Request-ом разработчик заполняет в файле ReleaseNotes.md следующие пункты:
— New (Что нового? (фичи, новая функциональность));
— Improvements (Какие улучшения мы добавили в существующие фичи);
— Fixes (Список исправленных багов);
— Operations (Eslint, обновление библиотек и т.д.).
На основе этого файла формируются Release Notes каждой версии. Этот документ смотрят QA специалисты. После публикации версии содержимое файла ReleaseNotes.md обнуляется.
2. Выбрали классический git-flow (хотя сам я сторонник другого ветвления). Это правильно по многим причинам, но для меня главная — открытость к ротациям в команде. Отраслевые стандарты позволяют свести начальный инструктаж к минимуму.
3. Не задумывался линейна или не линейная история. Использую в работе удобный GitKraken, всё наглядно. За ссылки благодарю, изучу внимательно этот вопрос.
«Возраста» коммент. Забавно читать это предложение, особенно когда уже перешагнул рубеж в 30 лет.
P.S.: Не согласен с первым местом :)